Domain 5 — Protection of Information Assets (26% · ~39 questions)

Weight: 26% of the exam — the joint-largest domain, alongside Domain 4. Together they are 52% of your marks.

It splits into two halves:

• A. Information Asset Security and Control — the controls that protect assets: frameworks, physical, identity, network, crypto, PKI, cloud, mobile and IoT
• B. Security Event Management — awareness, attacks, testing, monitoring, incident response and forensics

The unifying test across both halves: for any risk, can you name the preventive, the detective and the corrective control — and do you know precisely what each control does and does not provide? That framing is how ISACA writes the question.

A. Information Asset Security and Control

What this section is really testing. Domain 5 is 26% of the exam (roughly 39 of 150 questions) and is joint-largest with Domain 1, and this section — information asset security, its policies, physical protection, identity and access, network/endpoint controls, DLP, encryption, PKI, cloud/virtualisation and mobile/IoT — is the bulk of it. ISACA is not testing whether you can configure a firewall; it is testing whether you can reason like an IS auditor: who owns risk (management, never the auditor or IT alone), which control is preventive vs detective vs corrective, what is the BEST answer when several are technically true (the one that is preventive, addresses root cause, is cost-justified, and is sustainable/automated, not the most technically exotic), and what evidence would actually let you conclude a control is working rather than merely documented. Expect the word BEST, MOST important, GREATEST risk, FIRST step and PRIMARY constantly — the discriminator is almost always ownership, control type and evidence, not product knowledge.

How the exam asks it

• "What is the BEST/MOST effective control?" — prefer preventive → detective → corrective. A control that stops the event beats one that finds it afterwards. Also prefer controls that scale (RBAC, centralised policy, automation) over manual heroics.
• "FIRST step / MOST important action" — the first step is nearly always risk assessment, classification of the asset, or obtaining management direction/approval — not buying a tool or writing a script.
• "Who should...?" — data/asset owner (business) classifies and authorises access; custodian/IT implements; user complies; auditor only evaluates. Recertification of access = business/system owner, not IT alone and never the auditor. Risk acceptance = senior management.
• "GREATEST risk / MOST concerning finding" — unscoped/unknown assets, standing privileged access, ex-employee accounts still active, default credentials on internet-facing/IoT devices, unpatched critical systems, "any-any" firewall rules, unencrypted backups/media leaving site.
• "The auditor should..." — inspect, observe, test, re-perform, interview, and verify independently (e.g., reconcile the account list to HR leavers). Auditors do not implement controls; they may recommend.
• Control-type classification is asked directly: firewall = preventive; IDS/CCTV/log review = detective; IPS, account lockout, AV quarantine = preventive (they act); backup restore, incident cleanup = corrective; awareness training, job rotation = often preventive/compensating detective.
• Scenario–technology matching: "user needs access to one resource on a shared server, needs are unpredictable" → RBAC/ABAC; "high-security government system with formal labels" → MAC; "small environment, owner decides" → DAC.
• Auditor's evidence trick questions: policy signed by IT manager (weak — needs highest level approval), HR email saying access was removed (weak — needs log/account evidence), provider's SOC 2 report (useful but read the period, scope and complementary user entity controls).

Mnemonic C-A-P for any control question: Classify/assess first, Assign accountability (owner, not IT), Pick the preventive control that addresses root cause.

Information asset security policies, frameworks, standards and guidelines

• Information security policy — the top-level document expressing management's direction and intent. Must be approved at the highest level (board/senior management), be aligned to business objectives and legal/regulatory obligations, be communicated, and be enforced and monitored — an unenforced policy is a document, not a control. It should be reviewed at planned intervals and on significant change.
• Hierarchy of documents:
  • Policy — what and why (mandatory, high level, management-approved, changes slowly).
  • Standard — specific mandatory requirements (e.g., AES-256, minimum password length, TLS 1.2+). Mandatory.
  • Procedure — step-by-step how a task is performed (mandatory, operational).
  • Guideline — recommended/advisory practice; not mandatory.
  • Baseline — a minimum hardened configuration for a platform (e.g., CIS Benchmark).
• CIA triad plus the extended set:

• Defence in depth / layered defence — multiple independent, overlapping controls (physical, network, host, application, data, people) so failure of one layer is not catastrophic. Host-based and network controls are complementary, not alternatives — a classic exam point.
• Least privilege — grant the minimum access, for the minimum time, needed for the task. Need-to-know — access only to information required for the role, even if technically capable of more. Separation of duties (SoD) — split a transaction so no single person can initiate, authorise and record it; the classic compensating control when SoD cannot be achieved is monitoring/supervisory review, not "no control".
• Governance roles:
  • CISO/security manager — owns the security programme, reports to senior management; advises and enables, does not accept business risk alone.
  • Security steering committee — cross-functional (business + IT + legal + risk), sets direction, prioritises, resolves conflicts, monitors the programme.
  • Data/asset owner — business manager accountable for classification and authorising access. Custodian — implements the owner's decisions. User — complies. Auditor — independent assurance.
• Why policies must be enforced and monitored — without monitoring you cannot demonstrate operating effectiveness; ISACA expects inspection of logs, exception reporting, and consequences for violation.
• Standards/frameworks to know:

• NIST SP 800-53 Rev.5 — 20 control families (two-letter identifiers): AC Access Control, AT Awareness and Training, AU Audit and Accountability, CA Assessment/Authorization/Monitoring, CM Configuration Management, CP Contingency Planning, IA Identification and Authentication, IR Incident Response, MA Maintenance, MP Media Protection, PE Physical and Environmental Protection, PL Planning, PM Program Management, PS Personnel Security, PT PII Processing and Transparency, RA Risk Assessment, SA System and Services Acquisition, SC System and Communications Protection, SI System and Information Integrity, SR Supply Chain Risk Management.
• Security architecture concepts:
  • Zero trust — "never trust, always verify"; no implicit trust from network location; authenticate and authorise every request; assume breach; micro-segmentation; least-privilege per-session access; continuous verification of device and identity posture.
  • Defence in depth, choke points (concentrate controls where traffic/people must pass), fail-safe defaults (deny by default), weakest-link thinking, simplicity (complex controls are misconfigured and bypassed).

Physical and environmental controls

• Site selection/construction — avoid flood plains, flight paths, seismic/fault zones, chemical plants, obvious landmarks; consider local crime rate, emergency services access, utilities diversity, and camouflage/low-profile signage. Building: load-bearing walls, reinforced floors, no windows on the data-centre perimeter, single controlled entry point, fire-rated construction.
• CPTED (Crime Prevention Through Environmental Design) — design the environment to reduce crime: natural surveillance (sightlines, lighting), natural access control (one entry, clear wayfinding), territorial reinforcement (fences, signage, landscaping), maintenance (a well-kept site signals care and deters intrusion).
• Perimeter and layered physical security (outside → inside): site perimeter → building perimeter → floor → data-centre/secure room → cabinet/rack → device → media.
• Controls:

• Biometrics — factors "something you are/do". FAR (false acceptance rate): unauthorised person accepted (a security failure). FRR (false rejection rate): authorised person rejected (a usability failure). Tightening the threshold lowers FAR and raises FRR. CER/EER (crossover error rate) is where FAR = FRR and is the standard comparison metric: the lower the CER, the more accurate/better the device. Consider intrusiveness, user acceptance, cost, and the failure mode: for high-security areas, failure to enrol/reject is safer than false acceptance, but heavy FRR causes users to defeat the system.
• Tailgating — following an authorised person through a door; countered by mantraps, turnstiles, awareness, guards, and one-credential-one-entry designs.
• Clean desk / clear screen — no sensitive documents or media left unattended; screen lock with short inactivity timeout; secure bins/shredding; this is a physical confidentiality control that supports the paper side of DLP.
• Secure disposal — documents cross-cut shredded or incinerated; media sanitised per NIST SP 800-88 (Clear, Purge, Destroy); certificates of destruction obtained and reviewed; never sell/donate media without sanitisation.
• Environmental — HVAC and air:
  • Temperature ~21°C / 70°F and relative humidity ~45–55% are the classic exam targets. Too dry → static discharge damages components; too damp → condensation and corrosion.
  • Positive air pressure in the computer room keeps dust/contaminants out; filtered, recirculated cooling; separate zones for people and equipment.
  • Water detection sensors under the raised floor and near AHUs/plumbing; shut-off valves; never place a data centre below water tanks, toilets or on the lowest floor.
• Fire detection and suppression:

• Suppression agents:

• Fire classes — A ordinary combustibles (wood, paper — water); B flammable liquids (foam/CO₂/clean agent); C energised electrical equipment (CO₂/clean agent — never water); D combustible metals (special dry powder); K/F cooking oils and fats (wet chemical). Mnemonic: Ash, Barrel, Current, Dynamite, Kitchen.
• Also required: fire-rated walls/doors, early warning + suppression + detection + training + evacuation plan + suppression system servicing, and handheld extinguishers of the correct class.
• Power:
  • UPS — batteries + inverter; covers short outages/sags/spikes/brownouts and provides power conditioning; bridging time is typically minutes, sized to ride through brief interruptions or until the generator starts. A UPS is not a generator (classic trap): it cannot sustain an extended outage.
  • Generator — diesel/gas, for extended outages; needs fuel contracts, regular load testing under load, automatic transfer switch, and a separate/secure location.
  • Dual power feeds from independent substations plus dual-corded equipment; PDU distributes and can monitor per-outlet power; grounding/earthing for safety and noise reduction; surge suppression.
  • Not all equipment belongs on the UPS — prioritise by criticality and monitor UPS/generator alarms.
• EMI shielding — Faraday-cage construction, shielded twisted-pair or fibre (fibre is immune to EMI and hard to tap), separation of power and data cabling, shielding of transformers/UPS, and TEMPEST-level controls for classified environments.
• Physical security from the auditor's perspective:
  • Review physical access logs (who entered, when, exceptions, after-hours entries) and confirm they are monitored, not just collected.
  • Verify terminated staff and contractor badges/cards were revoked — test the active card list against HR leaver reports and try to reconcile exceptions. HR notification is not evidence; the access system record is.
  • Test that physical access matches authorisation records (walk the site, compare the badge list to the authorisation list, test that a restricted area rejects a non-authorised badge).
  • Check visitor logs for escorting, CCTV retention/monitoring, fire-suppression inspection certificates, UPS/generator test records, and environmental alarm history.
  • Look for evidence of social-engineering pressure points: propped doors, unescorted contractors, shared badges, tailgating hotspots.

Identity and access control

• The AAA chain: Identification (claiming an identity — user ID) → Authentication (proving it) → Authorisation (what that identity may do) → Accountability (attributing actions via unique IDs and audit trails). Unique IDs are the foundation of accountability — shared accounts destroy it and are a classic finding.
• Authentication factors: something you know (password, PIN), have (token, smart card, phone), are (biometric), do (signature/keystroke dynamics). MFA requires two or more factors of different categories — password + PIN is single-factor (both "know"); password + OTP token is genuine MFA.
• MFA: mitigates password guessing, credential stuffing and password reuse; vulnerabilities are real-time phishing proxies (attacker-in-the-middle), MFA fatigue/push bombing, SIM swapping, and weak recovery flows. Stronger forms: FIDO2/WebAuthn passkeys and hardware security keys (phishing-resistant, origin-bound), number matching, certificate-based auth.
• SSO (single sign-on) — one authentication grants access to many systems. Benefits: fewer passwords, less password fatigue/reuse, centralised policy and de-provisioning, single audit point, better user experience. Risks: compromise of the one credential compromises everything — so SSO demands strong authentication (MFA), short session timeouts, centralised logging, tight session control, and rapid account disablement. The exam answer to "greatest risk of SSO" is usually compromise of a single credential giving broad access.
• Federated identity / third-party IdP:
  • SAML 2.0 — XML-based assertions for authentication/SSO across security domains (identity provider ↔ service provider).
  • OAuth 2.0 — an authorisation/delegation framework (access tokens, scopes); it is not an authentication protocol (common trap).
  • OpenID Connect (OIDC) — an authentication/identity layer on top of OAuth 2.0 (ID token as a JWT).
  • Risks: trust in the external IdP, token theft, misconfigured scopes/redirect URIs, and loss of visibility; controls are contract, assurance reports, conditional access and logging.
• Kerberos — a ticket-based, symmetric-key SSO protocol (default port 88). The KDC (Key Distribution Center) contains the Authentication Service (AS) and the Ticket Granting Service (TGS). The client authenticates once to the AS → receives a TGT (Ticket Granting Ticket) → presents the TGT to the TGS for a service ticket per resource. Requires time synchronisation (tickets are time-stamped) and protects credentials from traversing the network. Risks: pass-the-hash/pass-the-ticket, Kerberoasting, weak service-account passwords, and the KRBTGT key (its compromise forges any ticket — "golden ticket").
• Password policy (know the trade-offs):
  • Length beats complexity — modern guidance (NIST SP 800-63B) favours long passphrases, screening against breached/common password lists, no arbitrary forced rotation without evidence of compromise, and no composition rules that drive predictable patterns like Password1!.
  • History — prevents immediate reuse; minimum age prevents cycling back to a favourite in one sitting.
  • Lockout — after N failed attempts, lock or throttle. Trade-off: lockout is a denial-of-service vector (an attacker can lock out every user). Alternatives: exponential backoff/throttling, CAPTCHA, risk-based step-up, and alerting.
  • Also: no shared accounts, no plaintext storage (salted, stretched hashes), secure reset/helpdesk identity proofing, no password hints, session timeouts, screen locks.
• Access control models:

• Related: role explosion (too many roles), RBAC + least privilege in practice uses "role mining" and periodic reviews.

• Principles: least privilege, need-to-know, separation of duties, and — as compensating/detective controls where SoD or least privilege cannot be fully applied — mandatory vacation and job rotation (they surface fraud/errors that the incumbent was hiding). Note: mandatory vacation and rotation are detective controls, not preventive.
• Identity lifecycle (joiner–mover–leaver):
  • Joiner — approved request, least-privilege provisioning from a role template, unique ID, no shared/duplicate accounts, acceptance of policy.
  • Mover/transfer — permissions must be re-evaluated and removed as well as added. Un-removed legacy rights create privilege creep — a top finding.
  • Leaver — timely de-provisioning: disable/delete accounts, revoke VPN/remote, revoke tokens/certificates, recover assets, remove from groups/distribution lists, revoke physical badges, recover keys, transfer data ownership. Uncleaned ex-employee accounts are a classic high-severity finding — and reliance on HR notification without an audit/reconciliation of the account population is weak evidence (HR may be late, contracts may end abruptly, contractors may not go through HR at all).
  • Auditor test: obtain the active account list from the system, compare to the HR active-employee list, and investigate orphan/mismatched accounts. Also test contractor and vendor accounts and service accounts.
• User access reviews / recertification:
  • Performed periodically (and after job changes) by the business/system owner who understands the data — not by IT alone (IT cannot judge business need) and never by the auditor (the auditor reviews the process and tests the results).
  • Should cover all accounts: standard users, privileged accounts, service accounts, remote access, shared/technical accounts, third parties.
  • Evidence required: who reviewed, what was decided, when it took effect, and proof the removals actually happened (compare before/after entitlements).
• Privileged access management (PAM):
  • Vaulting of privileged credentials; credential rotation/check-out-check-in; session recording and monitoring; just-in-time (JIT) elevation with time-bound approval; least privilege for admin tasks; no shared/generic admin accounts; break-glass/emergency accounts held in the vault with heavy logging and post-use review; service accounts with non-interactive, scoped, rotated credentials and no domain-wide rights.
  • Also: separation of duties between who requests, who approves and who can use privilege; privileged activity alerting; and monitoring of admin rights on endpoints (local admin is a major attack enabler).
• Remote access:
  • VPN — encrypted tunnel (see network section). Risks: split tunnelling (personal/compromised traffic bypasses corporate inspection), credential/token theft, VPN appliances as internet-facing targets, and the false comfort that "the VPN makes it safe".
  • ZTNA (zero trust network access) — per-application, identity- and posture-based access instead of blanket network access; reduces lateral movement.
  • Jump hosts/bastion — concentrated, hardened, logged administrative entry point; combined with session recording.
• Authentication attacks and the controls:

Network and endpoint security

• OSI ↔ TCP/IP mapping:

• Devices and layers:

• Control classification (memorise): firewall = preventive; IDS = detective; IPS = preventive; WAF = preventive; NAC = preventive; honeypot = detective.
• Firewall rule types: packet filtering (stateless, header only: src/dst IP, port, protocol), stateful inspection (tracks connection state in a table — rejects unsolicited inbound), application-layer/proxy (inspects payload, breaks client-server directly, slower), NGFW.
• Default deny / implicit deny — the rule base must end with deny all; anything not explicitly permitted is blocked. Rules are processed top-down, first match wins.
• Rule hygiene — stale, duplicated, overly broad ("any-any") and unused rules are a finding; so are shadowed rules, rules with no documented business owner, and rules changed without change control. Auditor tests: review the rule base against the policy, identify any-any rules and request justification, verify periodic rule recertification and that changes went through change management.
• Segmentation: DMZ/screened subnet for internet-facing services (dual-homed or three-legged firewall); VLANs to separate functional/trust zones; micro-segmentation (per-workload policy, foundation of zero trust); air gaps for the most sensitive systems (and note they are bypassed by removable media and vendor laptops — Stuxnet).
• Addressing and translation: RFC 1918 private ranges — 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16; link-local/APIPA 169.254.0.0/16; NAT (many-to-one address translation) and PAT/overloading (port-level). NAT is not a security control — it is an addressing convenience.
• DNS security:
  • DNS spoofing/cache poisoning — forged records redirect users; controls: DNSSEC (cryptographic integrity/authenticity of records — not confidentiality), response-rate limiting, restricting zone transfers (AXFR) to authorised secondaries, split-horizon DNS, and DNS over HTTPS/TLS for privacy.
  • DNS tunnelling — encoding data in DNS queries/responses; a major exfiltration and C2 channel that slips past many controls because DNS is usually allowed outbound. Control: monitor for high-volume/odd-length/high-entropy queries and restrict DNS to approved resolvers.
• LAN attacks: ARP spoofing/poisoning → man-in-the-middle (control: dynamic ARP inspection, static ARP for critical hosts, port security); DHCP starvation and rogue DHCP servers (control: DHCP snooping, port security); VLAN hopping via switch spoofing (DTP) or double tagging (control: disable auto-trunking on access ports, change the native VLAN, prune VLANs, physically secure ports).
• Wireless security:

• Wireless risks: rogue access points, evil twin/captive-portal phishing, war driving, ad hoc/peer-to-peer networks, misconfigured guest access. SSID hiding is not security (the SSID is still discoverable), and MAC filtering is trivially bypassed — both are at best deterrents.
• 802.1X/EAP — port-based network access control: supplicant, authenticator (AP/switch), authentication server (RADIUS). EAP-TLS (certificates both sides) is the strongest; PEAP/MSCHAPv2 is common but vulnerable to credential relay/phishing without server-certificate validation.
• Guest networks must be isolated from the corporate network (separate VLAN/SSID, internet-only, throttled, no lateral access).
• VPN:

• Endpoint security:
  • Traditional signature antivirus — effective only against known files; defeated by polymorphic/novel malware.
  • EDR — continuous endpoint telemetry, behavioural detection, response actions (isolate host, kill process); EPP = prevention-focused platform; XDR extends correlation across email/endpoint/network/cloud.
  • Application allowlisting (permit only approved binaries) — strong against unknown malware but operationally demanding.
  • Others: host firewall, full-disk encryption, patch/vulnerability management (critical patches within defined SLAs; the auditor checks the process, coverage and exceptions), USB/removable-media control, DLP agent, hardening baselines (CIS Benchmarks, vendor STIGs), secure configuration/no default accounts, host-based logging to a central SIEM, MDM for mobile.
  • Endpoint and network controls are complementary: DLP on the endpoint sees USB/print/clipboard that the network cannot; network DLP sees email/web/cloud traffic the endpoint cannot.
• Email security (all three are DNS-based, and the point is alignment):

• Plus: secure email gateway (filtering, sandboxing, attachment/link rewriting), TLS for transport, user reporting, and awareness of business email compromise (no payload — social engineering).

• IDS/IPS detection methods: signature (known patterns; accurate for known, blind to novel), anomaly/statistical (baseline deviation; catches novel behaviour, noisy), heuristic/behavioural (rules on behaviour). Placement: at the internet perimeter (before and after the firewall), on the DMZ, on internal segments, and on critical hosts.
• False positive vs false negative: a false positive is an alert on benign activity → alert fatigue, wasted effort, and eventually ignored alerts; a false negative is missing real malicious activity → undetected compromise. Detection tuning trades them off: tightening reduces false negatives and increases false positives. For detection systems ISACA usually treats a false negative as the greater risk (you are blind), while for automated blocking/IPS a false positive can break production — so decide by context and say so in the answer.
• Honeypot/honeynet — deliberately exposed, instrumented decoy systems to detect, delay, distract and study attackers and to generate high-quality (low false-positive) alerts. Detective, not preventive; must be isolated so it cannot be used as a pivot; legal/ethical care (enticement is generally acceptable, entrapment is not).
• NAC (network access control) — authenticate and posture-check devices before granting network access (patch level, AV, encryption, managed device), placing failures in a quarantine/remediation VLAN. Supports 802.1X, and helps with unmanaged/IoT asset visibility.
• Secure configuration/hardening — remove unnecessary services and default accounts, change default passwords, disable unused ports/protocols, least-privilege service accounts, centralised configuration baselines with drift detection, and configuration management feeding change control.

Data loss prevention

• Purpose — prevent unauthorised exfiltration of sensitive data, and detect it when prevention fails. DLP is a data-centric control that complements network and endpoint controls.
• Three states of data (memorise):

• Discovery and classification are the prerequisite. DLP without data classification produces noise — you must know what is sensitive (and who owns it) before you can police it. Classification is the data owner's decision, driven by policy.
• Content-matching techniques: exact data matching (EDM) (match against a structured record set, e.g., customer IDs), document fingerprinting (template of a sensitive document), regex/pattern (credit-card numbers, HKID, national IDs), keyword/dictionary, ML/statistical and OCR (unstructured content, images). Strengths and false-positive rates differ; production DLP layers several.
• Actions (escalating): monitor/audit (log only) → warn/educate the user (prompt with justification) → block/quarantine → encrypt or apply rights. Deploy in monitor mode first, tune, then enforce.
• Placement: endpoint DLP (USB, print, clipboard, local files), network DLP (email/web/cloud egress), cloud DLP/CASB (API-based inspection of SaaS/cloud storage and shadow-IT discovery).
• Why DLP is hard — very high false-positive rates from legitimate business flows; requires tuning, exception handling, an owner for each policy, and a culture that supports it (users who feel policed will route around it, e.g., personal cloud/GenAI). DLP is not a substitute for access control or encryption.
• Insider threat programme and UEBA — risk-based monitoring of behaviour (mass download, unusual access times, data hoarding, privilege changes, pre-resignation activity, access to data outside the role) using user and entity behaviour analytics. Controls: least privilege, SoD, monitoring with privacy/legal guardrails, HR/legal involvement, and defined response.
• Water-marking and document rights management (IRM/DRM) — embed user/context identifiers (visible or invisible) so leaked copies are attributable; DRM enforces permissions (no copy/print/forward) and can revoke. Supports attribution and deterrence; not a firewall.
• Data remanence and secure disposal — residual data recoverable after deletion/formatting. Methods: overwriting (multiple passes), degaussing (magnetic media only — does not work on SSDs/flash), physical destruction/shredding/incineration (most reliable), and crypto-erasure (destroy the key so ciphertext is unrecoverable — the practical approach for encrypted mobile/SSD media). Follow NIST SP 800-88 with certificates of destruction and third-party supervision.
• Exfiltration vectors to consider (a favourite scenario question): email and webmail, web uploads/file-sharing, USB/removable media, cloud sync (personal Dropbox/OneDrive), printing and photocopying, screenshots/photos of screens, instant messaging, DNS/encrypted covert channels, backup media leaving site, third-party/vendor access, and GenAI/LLM prompt leakage (staff pasting source code, contracts or personal data into a public model) — controls: acceptable-use policy, blocking or enterprise-only AI tools with data-retention terms, DLP inspection of prompts, and awareness.

Data encryption

• Symmetric — one shared secret key for encrypt and decrypt; fast, efficient for bulk data; problem is secure key distribution and n(n-1)/2 key pairs scaling. Provides confidentiality (and, in authenticated modes, integrity).

• Asymmetric — key pair: public key to encrypt/verify, private key to decrypt/sign; mathematically related but not derivable; slow, so used for key exchange, digital signatures and non-repudiation, not bulk data.

• Hybrid encryption (how TLS really works) — asymmetric cryptography exchanges/agrees a symmetric session key, then symmetric crypto protects the bulk of the traffic. Explains why "TLS is both" is the right answer.
• Hashing — one-way, fixed-length digest; provides integrity, not confidentiality; cannot be reversed.
  • MD5 (128-bit) and SHA-1 (160-bit) are broken for collision resistance — unsuitable for signatures/integrity where collisions matter.
  • Current: SHA-256/384/512 (SHA-2) and SHA-3.
  • Salt — unique random value per password stored with the hash; defeats precomputed rainbow tables and hides identical passwords. Pepper = secret value not stored with the hash.
  • Key stretching / password hashing — deliberately slow algorithms: PBKDF2, bcrypt, scrypt, Argon2 (Argon2/bcrypt preferred today). Fast hashes (MD5/SHA-1/SHA-256 alone) are wrong for password storage.
• MAC/HMAC — a keyed hash over a message using a shared secret: provides integrity and authenticity between the two parties; because the key is shared, it does NOT provide non-repudiation (only digital signatures do).
• Digital signatures — the signer hashes the message and encrypts the hash (or signs it) with their private key; anyone verifies with the public key. Provides integrity, authenticity and non-repudiation — and NOT confidentiality (anyone with the public key can read the message). This is one of the most repeated traps on the exam. Combined with encryption when both are needed.
• Encryption in transit vs at rest:

• Key management — generation (FIPS 140-2/140-3 validated RNG, HSM), distribution (out-of-band, key wrapping), storage (HSM/KMS; never store keys with the data they protect), rotation/cryptoperiod (shorter for high-value/more-used keys), escrow/recovery (business continuity for lost keys — but escrow is a risk and needs SoD and strict access control), destruction (crypto-erasure). Encryption is only as strong as its key management — an encrypted database with the key in a config file beside it is theatre.
• Steganography vs encryption — steganography hides the existence of the message (embedded in images/audio); encryption hides the content but not the fact that a message exists. Steganography is a covert-channel/exfiltration concern; detection (steganalysis) is difficult.
• Quantum and post-quantum (awareness level) — Shor's algorithm would break RSA/ECC/DH (public-key) once large-scale quantum computers exist; Grover's algorithm roughly halves effective symmetric strength (so prefer AES-256). "Harvest now, decrypt later" means long-lived confidential data is already at risk. Mitigations: crypto-agility (inventory and be able to swap algorithms), longer keys, and migration to NIST post-quantum standards (FIPS 203 ML-KEM/Kyber, FIPS 204 ML-DSA/Dilithium, FIPS 205 SLH-DSA/SPHINCS+, finalised 2024). Hybrid PQC+classical key exchange during transition.
• Auditor's perspective on encryption — verify that the control is actually operating, not merely licensed: encryption enabled and applied to the right data (test on real systems/files), keys protected, access-restricted and rotated, algorithms and protocol versions current, certificates valid (not expired, correct name, trusted chain), no plaintext copies/backups/exports bypassing the control, and key recovery tested so a lost key does not become an availability incident.

Public key infrastructure

• Purpose — bind a public key to an identity with a trusted, verifiable assertion.
• Components:

• X.509 digital certificate (v3) key fields — version, serial number, signature algorithm, issuer, validity period (notBefore/notAfter), subject, subject public key info, extensions (key usage, extended key usage, SAN, basic constraints CA:TRUE/FALSE, CRL distribution point, authority information access, certificate policies), and the CA's signature.
• Chain of trust — Root CA → intermediate/subordinate CA → leaf (end-user/server) certificate. The root CA private key must be kept offline/air-gapped in an HSM with strict physical and SoD controls — it is the single point of catastrophic failure. Intermediates allow day-to-day issuance without exposing the root, and can be revoked independently.
• Certificate lifecycle — enrolment/registration (identity proofing by RA per the CPS) → issuance/signing → distribution (repository, keystore, browser trust store) → use → renewal/expiry → suspension (temporary hold, e.g., suspected compromise) → revocation (permanent, e.g., key compromise, employee departure, CA compromise) → key destruction/archival.
• Revocation checking:

• Short-lived certificates and automated issuance (ACME) are the modern answer to the revocation/freshness problem.

• Related items: certificate pinning (client trusts only a specific certificate/key, defeating rogue CAs but brittle on rotation); self-signed certificates are fine for internal/testing but unsuitable for public trust (no third-party assurance; users trained to click through warnings, enabling MITM); code signing (integrity/provenance of software); wildcard (*.example.com, convenient but a single key compromise affects all subdomains, cannot span multiple levels) vs SAN certificates (explicit multiple names); certificate expiry is a common, entirely preventable outage cause — inventory, alerting, and automation; Certificate Transparency logs expose misissued certificates.
• Trust models: hierarchical (single root — most common, simple, clear trust anchor, root compromise is catastrophic), mesh/distributed (web of trust, PGP) (no central authority; peer signatures; harder to manage), bridge CA (cross-certification hub joining separate hierarchies, common in federated/government PKI).
• Why a compromised CA is catastrophic — it can issue rogue certificates for any domain or identity, enabling undetectable impersonation, code signing and MITM for as long as the certificates are trusted (see DigiNotar 2011, which led to browser distrust and the CA's collapse). Controls: offline roots, HSMs, SoD, audits (WebTrust), CT monitoring, and rapid revocation/distrust procedures.

Cloud and virtualized environments

• Service models (NIST SP 800-145):

• Essential characteristics — on-demand self-service, broad network access, resource pooling (multi-tenancy), rapid elasticity, measured service (pay-per-use). Deployment models: public, private, hybrid, community.
• Shared responsibility — the split moves with the service model. The auditor's first question is always: what is the provider responsible for, and what remains ours? And the responsibility for data classification, access authorisation and compliance with law stays with the customer in every model.

• Cloud-specific risks: multi-tenancy and isolation failure (one tenant reaching another), data residency/sovereignty, loss of governance and visibility (no access to provider logs/hypervisor), vendor lock-in and portability/exit, insecure APIs/keys, insider risk at the provider, jurisdiction and lawful access (e.g., cross-border subpoenas), provider viability (what happens to your data if they fail), supply chain and fourth parties (the provider's own subprocessors), and shadow cloud/IT (business units buying SaaS outside IT — controls: discovery via CASB/cloud access logs, policy, approved-catalogue with fast procurement, expense/CASB monitoring).
• Assurance and controls:
  • SOC 2 Type 1 — opinion at a point in time (design). SOC 2 Type 2 — opinion over a period (usually 6–12 months) on operating effectiveness. Read the period covered (a stale report says nothing about today), the scope (which systems/locations/processes), the Trust Services Criteria in scope (Security is mandatory/common criteria, plus Availability, Processing Integrity, Confidentiality, Privacy), subservice organisations (carve-out vs inclusive method), exceptions/qualified opinions, and — critically — the complementary user entity controls (CUECs): the things you must do for the provider's controls to be effective. A SOC 2 report does not transfer or remove the customer's responsibilities.
  • ISO/IEC 27017/27018 certification, CSA STAR (Level 1 self-assessment, Level 2 third-party audit, continuous monitoring), right to audit — often contractually limited to accepting the provider's reports rather than on-site audit; understand and document the practical limits and rely on compensating assurance.
  • Technical controls: CASB (discovery and policy for cloud/SaaS; API-mode vs proxy-mode), CSPM (misconfiguration/benchmark monitoring), CWPP/workload protection, cloud access logging to a central SIEM, customer-managed keys (CMEK/BYOK/HYOK) with an external key manager, IAM least privilege and no long-lived keys, immutable/versioned backups.
• Cloud backup — verify the contract: providers replicate for availability/resilience, which is not the same as backup/restore of your data (SaaS deletion, ransomware, accidental mass edit, retention limits). Ask: who backs up, how often, retention, RPO/RTO, encryption and key control, restoration testing, tenant-level restore, and exit data return/format. "The provider backs it up" must be verified against the contract and tested, not assumed.
• Virtualization:
  • Hypervisor types — Type 1 (bare metal): ESXi, Hyper-V, KVM/Xen — runs directly on hardware, smaller attack surface, data-centre standard. Type 2 (hosted): VirtualBox, VMware Workstation — runs on a host OS, weaker isolation, for desktops/testing.
  • The hypervisor is a high-value target: compromise or VM escape breaks all tenant/guest isolation at once. Controls: minimal hypervisor footprint, patches, hardened management plane (not exposed to the internet), admin MFA and PAM, strict SoD, logging, and API security.
  • VM sprawl — uncontrolled VM creation → unmanaged, unpatched, unmonitored systems. Snapshot and image/template sprawl — old snapshots and golden images retain data, credentials and configs; they leak secrets and are rarely patched. Controls: inventory, lifecycle/expiry, image hardening pipelines, secrets scanning, approval workflows.
  • VM mobility/live migration (vMotion) — moves running VMs between hosts; requires a trusted, encrypted migration network and correct trust-zone mapping; the VM may cross a security boundary, taking its traffic and data with it. Also snapshot/backup files are portable copies of the whole server — protect and encrypt them.
  • Resource contention / noisy neighbours — one VM consuming shared CPU/memory/storage/network degrades others; capacity management, resource limits/reservations, and monitoring are availability controls in multi-tenant environments.
  • Virtual networking — virtual switches, SDN, distributed firewalls, security groups; virtual controls can be misconfigured as easily as physical ones, and traffic that never touches physical hardware can escape physical inspection — plan monitoring points deliberately.
  • Containers — share the host OS kernel, so isolation is weaker than a VM; risks include vulnerable base images, poisoned registries, over-privileged containers, secrets in images/env vars, and orchestration (Kubernetes) misconfiguration. Controls: trusted registries with image scanning/signing, minimal base images, non-root, resource limits, Kubernetes RBAC and network policies, admission control, immutable infrastructure, external secrets management, and runtime monitoring.
  • Serverless/FaaS — no server to patch (the provider handles the runtime), but risks remain: event/data injection, over-permissive function execution roles, dependency/supply-chain risk, cold starts, and reduced visibility/logging. Controls: least-privilege function roles, scoped secrets, dependency scanning, API gateway controls, and full logging.

Mobile, wireless and IoT devices

• Ownership models:

• Policy must define: eligible devices/OS versions, enrolment requirement, what is monitored, what can be wiped, personal-data privacy, acceptable use, reimbursement, exit/wipe procedures, and consequences of non-compliance.

• Mobile risks — lost/stolen device, jailbreaking/rooting (removes OS sandbox and update guarantees), unmanaged/shadow apps, sideloading and third-party app stores with malware, excessive app permissions, data leakage and blending of personal/corporate data, unpatched OS, insecure Wi-Fi (evil twin), smishing/phishing, insecure backups to personal cloud, device sharing, and the extended perimeter — the network boundary is now wherever the device is.
• MDM / EMM / MAM:
  • MDM — device-level enrolment and control: policy enforcement, configuration profiles, encryption enforcement, passcode rules, jailbreak/root detection, patch compliance, remote lock, remote wipe.
  • EMM — the broader umbrella (MDM + MAM + identity + content).
  • MAM — application-level control without full device management: app wrapping, per-app VPN, DLP restrictions (copy/paste/save-as blocked), conditional access, and selective/corporate wipe.
  • Remote wipe distinction (exam favourite) — corporate/selective wipe removes only corporate data and apps (appropriate for BYOD); full device wipe returns the device to factory state and destroys personal data (appropriate for corporate-owned devices, and normally requires prior consent/agreement on BYOD). Containerisation/work profile (e.g., Android Work Profile, iOS managed apps/Open-In restrictions) keeps corporate data encrypted and separated so the corporate wipe is surgical.
  • Also: enforce encryption, device compliance gating to email/SaaS, geofencing, and monitoring of enrolled-device inventory against the HR roster.
• Mobile applications — vet apps and permissions, use enterprise app stores/MAM catalogues, block sideloading and unknown sources, review SDK/third-party data sharing, and perform mobile app security testing for in-house apps.
• Mobile payments/NFC — tokenisation (card number replaced by a device token), secure element/hardware-backed keystores, biometric/PIN gating, and HCE considerations; risks are lost-device misuse, malicious apps with NFC access, and relay attacks.
• IoT/OT — why normal controls break:
  • Constraints: limited CPU/memory/storage, no patch capability or no vendor updates, long lifecycles (10–20 years), default or hardcoded credentials, insecure/plaintext protocols, no encryption or weak crypto, physical exposure, and no logging/agent support.
  • Default and hardcoded credentials are a recurring exam theme and a real-world cause of major breaches — e.g., the Mirai botnet (2016) built from default-credential IoT devices, and the Target breach (2013) entered via HVAC contractor credentials. Controls: force credential change at onboarding, unique per-device credentials, certificate-based identity, disable remote/default access, and monitor for default-credential logins.
  • Segmentation/isolation — put IoT and OT on separate network segments/VLANs with deny-by-default firewall policy to the corporate network; restrict outbound to required destinations; never expose management interfaces to the internet; use a dedicated IoT gateway/broker.
  • OT/ICS distinctions — safety and availability come before confidentiality (CIA inverted to AIC): an outage or an unsafe command can cost lives, so patching requires planned outages and can be impossible. Know the vocabulary: PLC, RTU, HMI, SCADA, DCS, historian, engineering workstation, and the Purdue model layers — L0 physical process, L1 controllers, L2 supervisory (SCADA/HMI), L3 operations/site management, L3.5 industrial DMZ, L4 enterprise IT, L5 enterprise/cloud — with conduits and a DMZ between IT and OT, and no direct L4→L1 traffic.
  • Secure onboarding — asset inventory and registration first, unique credentials/certificates, hardening against a baseline, network placement decision, monitoring enabled, and documented ownership.
  • Asset discovery for unmanaged devices — you cannot secure what you have not inventoried: passive network monitoring, NAC, network scans (carefully — active scanning can crash fragile OT devices), DHCP/ARP/switch-table analysis, and procurement/change-process hooks so new connected devices surface automatically.
  • Vendor/supply-chain risk — device makers with poor security practices, unpatched third-party components, cloud back-ends of unknown jurisdiction, remote vendor support paths, and end-of-support hardware still in production. Controls: vendor security requirements in contracts, firmware update commitments, SBOM awareness, review before purchase, and compensating segmentation for devices that cannot be fixed.

TRAPS

• Digital signatures give integrity, authenticity and non-repudiation — NOT confidentiality. Encryption (or a hybrid) is needed for confidentiality.
• MAC/HMAC gives integrity and authenticity but NOT non-repudiation (shared secret, so the receiver could have produced it).
• A firewall prevents; an IDS detects; an IPS prevents. Do not mix them up; a WAF and NAC are preventive, a honeypot is detective.
• CCTV is detective, not preventive. Deterrence is a hoped-for side effect; its control value is the recorded evidence and monitored review.
• A UPS is not a generator. UPS = short outages and power conditioning (minutes); generator = extended outages. Data-centre fire suppression = clean agent/gas (FM-200, Novec 1230, INERGEN), not water.
• The cloud provider's SOC 2 report does not remove the customer's responsibilities — check the period, scope, exceptions, and the complementary user entity controls (CUECs).
• Revoked access must be verified by the auditor against the system records — an HR email or a ticket saying "access removed" is not evidence.
• User access recertification is performed by the business/system owner, not IT alone and never the auditor.
• The data/asset owner classifies data and authorises access — IT does not decide classification or risk acceptance.
• Least privilege, need-to-know and SoD are preventive; mandatory vacation and job rotation are detective (they detect what the incumbent hid).
• MFA needs two factors of different types — password + PIN is single-factor.
• SSO's greatest risk is that one compromised credential grants broad access — so it demands MFA, session controls and centralised logging.
• RBAC is usually the "BEST" answer for enterprise scalability; MAC is strongest but least flexible; DAC is owner-controlled and weakest; RuBAC is for firewalls/rules.
• Encryption at rest does not protect against a compromised application account or a privileged user — the app decrypts for them. It protects against media theft and disposal.
• SSLv3/TLS 1.0/1.1 are deprecated; MD5 and SHA-1 are broken for collisions; DES is broken; WEP is broken; WPS should be disabled; SSID hiding is not a security control.
• DNSSEC provides integrity/authenticity of DNS data, not confidentiality; DNS tunnelling is an exfiltration path.
• A VPN does not secure a compromised endpoint and split tunnelling weakens inspection.
• Hiding behind NAT is not security; private addressing is convenience.
• DLP produces high false positives and needs classification first — "deploy DLP" is rarely the best answer without discovery/classification/tuning.
• You cannot secure what you have not inventoried — asset discovery precedes IoT/OT controls.
• Air gaps are not absolute — removable media, vendor laptops and wireless bridges cross them.
• In OT, availability and safety outrank confidentiality — do not apply IT patching/scanning assumptions blindly.
• "Encrypted" is a claim, not evidence — the auditor must verify encryption is enabled, applied to the right data, keys protected/rotated, algorithms current, and certificates valid.
• Default credentials on IoT/internet-facing devices are the classic "GREATEST risk" answer — change them at onboarding.

60-second recall

• InfoSec policy = management's direction, approved at the highest level; standards mandatory, procedures how-to, guidelines advisory.
• CIA + Authenticity, Non-repudiation, Accountability, Privacy.
• ISO/IEC 27001:2022 Annex A = 93 controls: Organisational 37, People 8, Physical 14, Technological 34 (replaces the 2013's 14 domains); 27001 = ISMS requirements with PDCA; 27002 = how-to guidance; 27701 = privacy; 27017 = cloud; 27018 = PII in public clouds.
• NIST CSF 2.0 = Govern, Identify, Protect, Detect, Respond, Recover.
• NIST SP 800-53 = 20 control families with two-letter IDs (AC, AT, AU, CA, CM, CP, IA, IR, MA, MP, PE, PL, PM, PS, PT, RA, SA, SC, SI, SR).
• Zero trust = never trust, always verify + assume breach + micro-segmentation.
• Defence in depth; least privilege; need-to-know; SoD (compensate with monitoring).
• Physical layers: perimeter → building → floor → room → rack → device → media. Guards can prevent and detect; CCTV detects; mantraps stop tailgating.
• Biometrics: FAR = unauthorised accepted, FRR = authorised rejected; lower CER = better device.
• HVAC ~21°C / 45–55% RH; positive pressure; water detection under the floor.
• Fire classes A (ordinary), B (liquids), C (electrical), D (metals), K (kitchen); clean agents for data centres; Halon banned.
• UPS = short outages + conditioning; generator = extended outages; dual feeds; PDU; grounding.
• Auditor: review physical access logs, verify terminated badges revoked, test access vs authorisation.
• AAA = identification, authentication, authorisation, accountability (unique IDs + audit trail).
• MFA = two or more different factor types; FIDO2/WebAuthn is phishing-resistant.
• SSO: convenience and central control vs single-credential compromise risk.
• SAML = federated SSO; OAuth 2.0 = delegated authorisation, not authentication; OIDC = authentication on top of OAuth.
• Kerberos: KDC (AS + TGS), TGT, service tickets, symmetric keys, time sync.
• Access models: DAC (owner, weakest), MAC (labels, strongest, inflexible), RBAC (roles, enterprise best), ABAC (attributes), RuBAC (rules/firewalls).
• Mover = remove old rights; leaver = immediate de-provisioning; uncleaned ex-employee accounts = high-severity finding.
• Recertification by the business/system owner; PAM = vault, rotate, record, JIT, break-glass, no shared accounts.
• Attacks: brute force, credential stuffing, spraying, pass-the-hash, session hijack, replay, AiTM phishing of MFA.
• Layer map: hub L1, switch L2, router L3, firewall L3–4, WAF/proxy L7, load balancer L4/L7.
• Firewall rule base: default deny, first match, review for any-any and stale rules.
• RFC 1918: 10/8, 172.16/12, 192.168/16; NAT/PAT is not security.
• DNS: DNSSEC = integrity, not confidentiality; DNS tunnelling = exfiltration; restrict zone transfers.
• Wireless: WEP broken, WPA2 = AES-CCMP, WPA3 = SAE, WPS off, 802.1X/EAP-TLS strongest, guest isolated.
• IPsec: AH = auth only, ESP = encryption + auth; transport = payload, tunnel = whole packet.
• IDS detects, IPS prevents; signature vs anomaly vs heuristic; false negative = missed attack.
• Email: SPF + DKIM + DMARC and alignment with the From domain.
• DLP states: at rest, in motion, in use; discovery and classification first; monitor → warn → block → encrypt.
• Symmetric = AES (128/192/256), fast, bulk; asymmetric = RSA 2048+/ECC, slow, key exchange and signatures; hybrid = asymmetric exchange + symmetric bulk (TLS).
• Hashes: MD5/SHA-1 broken; SHA-256/SHA-3 current; salt defeats rainbow tables; bcrypt/scrypt/Argon2/PBKDF2 for passwords.
• Digital signature = hash + sender's private key → integrity, authenticity, non-repudiation, NOT confidentiality.
• Key management: generate, distribute, store (HSM, never with the data), rotate, escrow, destroy — the key is the weakest link.
• PKI: CA, RA, repository, validation authority, CP/CPS; X.509 v3; root offline; CRL (stale) vs OCSP (real-time) vs stapling; expiry causes outages; a compromised CA is catastrophic.
• Cloud: IaaS/PaaS/SaaS responsibility split moves; five essential characteristics; public/private/hybrid/community; SOC 2 Type 2 = period + scope + CUECs; ISO 27017/27018; CSA STAR; BYOK/CMEK; CASB/CSPM; verify "the provider backs it up".
• Virtualisation: Type 1 bare metal (ESXi/Hyper-V/KVM) vs Type 2 hosted; VM escape breaks all isolation; VM/snapshot/image sprawl leaks data; containers share the host kernel and need image scanning, RBAC and secrets management.
• Mobile: BYOD/COPE/CYOD; MDM vs MAM; corporate (selective) wipe vs full wipe; containerisation; jailbreak detection; encryption and patch enforcement.
• IoT/OT: default credentials (Mirai), no patching, long lifecycles, insecure protocols; segment and isolate; OT prioritises availability and safety; Purdue model with an industrial DMZ; inventory first.

B. Security Event Management

What this section is really testing: Section B is the dynamic half of Domain 5. Section A is about building the walls (policies, access control, encryption, network defence); Section B is about the adversary, the detection machinery and the response. ISACA tests whether you can (1) name the attack and the control that stops it, (2) distinguish a preventive, detective and corrective control for the same risk, (3) understand monitoring and logging as detective controls whose failure is a finding, (4) sequence the incident response lifecycle correctly, and (5) treat evidence with forensic discipline — preserve and escalate, never contaminate. The single most examinable theme: you cannot respond to what you did not detect, and you cannot prove what you did not preserve. Expect "FIRST", "BEST", "MOST important", "GREATEST risk" framing.

How the exam asks it

• Ordering questions on the IR lifecycle — "During which phase is the system restored to production?" (recovery). "At what point is the root cause determined?" (post-incident activity / lessons learned, after containment and eradication).
• Attack-to-control matching — "Which control BEST mitigates spear phishing?" (user awareness training + MFA; not an antivirus signature update).
• Preventive vs detective vs corrective — "Which is a detective control?" (log review, IDS, UEBA). "Which is corrective?" (restore from backup, patch after exploit, rebuild host).
• Auditor role questions — the correct answer usually preserves independence: review, evaluate, verify, observe. The wrong answers have the auditor performing penetration tests, conducting the forensic investigation, or tuning the SIEM personally.
• Point-in-time assurance — "Management states the penetration test found no issues, therefore..." → the best answer says it is only point-in-time assurance for the tested scope.
• Missing-control findings — "Logs are collected but never reviewed." "Alerts exceed SLA." "No documented lessons-learned." These are near-guaranteed finding scenarios.
• FIRST/BEST on evidence — the answer is almost always: do not touch the original; preserve; escalate to legal/forensics.

Security awareness training and programmes

Why awareness is a control in its own right: people are the most-targeted attack surface. Technical controls can be bypassed by a single user who clicks, approves an MFA prompt, or pays an invoice. Awareness is a preventive control (reduces likelihood), with detective value (users report suspicious mail), and it is the only control that scales across phishing, social engineering, insider error and physical tailgating.

Programme components

Measuring effectiveness — never completion rates

• Phishing click rate trend (should fall) and report rate trend (should rise) — the report rate is the more mature metric.
• Quiz/assessment pass rates and re-test rates, not attendance.
• Helpdesk social-engineering test results (e.g., pretext calls requesting a password reset).
• Behaviour change evidence: incidents attributable to user error over time, simulated-payment test outcomes, clean-desk / tailgating test results.
• "We sent an email" is not a programme. A mail-out with no measurement, no targeting and no reinforcement fails as a control.

Regulatory drivers

Social engineering awareness specifically: teach verification discipline (callback to a known number), authority-resistance ("the CEO asked" is not authorisation), urgency as a red flag, and a no-blame reporting culture so staff report mistakes fast. Fast reporting reduces dwell time more than prevention alone.

Auditor's tests

• Review the programme (content, frequency, coverage, ownership, budget).
• Sample training records — verify attendance/completion and dates.
• Verify new joiners and contractors are covered, including third parties with access.
• Verify privileged users receive additional, role-specific training.
• Confirm metrics are reported to management with trends and corrective actions.
• Test that policy acknowledgement is captured and that comprehension is assessed.

HR security lifecycle interface

Termination is the classic exam scenario: the FIRST action is to revoke logical and physical access; asset return and knowledge transfer follow.

Information system attack methods and techniques

For each category: learn the primary preventive, detective and corrective/recovery control. This is the ISACA framing.

Reconnaissance

Social engineering

Corrective/recovery for social engineering: credential reset, transaction recall with the bank, fraud notification, post-incident training.

Malware

Why signature-based detection fails: new variants, polymorphic/metamorphic code, packed or encrypted payloads, fileless techniques and legitimate-tool abuse produce no known signature → drives behavioural detection, EDR, anomaly detection and application allow-listing.

• Preventive: patching, application allow-listing, email/web filtering, endpoint hardening, disabling macros, least privilege.
• Detective: EDR/AV behavioural alerts, sandbox detonation, egress/C2 traffic monitoring, file-integrity monitoring.
• Corrective: isolate host, kill process, reimage from known-good build, restore data from offline/immutable backup, credential reset.

Network attacks

• Preventive (network layer): segmentation, firewalls with least privilege, encryption in transit, hardened devices, patching, 802.1X.
• Detective: IDS/IPS, NetFlow analysis, honeypots, WIPS, anomaly baselines.
• Corrective: block the source, re-route/scrub traffic, isolate the segment, patch, restore.

Web and application attacks

• SQL injection — unvalidated input concatenated into queries. Control: parameterised queries / prepared statements, input validation, least-privilege DB accounts, WAF.
• XSS — stored (persistent) — script saved server-side and served to other users (highest impact). XSS — reflected — script echoed in the immediate response, needs a crafted link.
• CSRF — forces a logged-in user's browser to send an unwanted request. Control: anti-CSRF tokens, SameSite cookies, re-authentication for sensitive actions.
• Command injection — OS commands via unsanitised input. Control: avoid shell invocation, allow-list inputs, sandboxing.
• Directory traversal — ../ sequences escape the web root. Control: canonicalise and validate paths, run with least privilege.
• Insecure direct object reference (IDOR) — object identifiers exposed and not access-checked. Control: server-side authorisation on every object access.
• File upload flaws — unrestricted type/executable upload. Control: type/size allow-list, store outside web root, scan content.
• Broken authentication and session management — weak passwords, session fixation, tokens in URLs. Control: MFA, secure token handling, timeouts, rotation.
• API attacks — broken object-level authorisation, excessive data exposure, lack of rate limiting, weak keys. Control: API gateway, schema validation, authorisation per endpoint, throttling.
• Insecure deserialisation — attacker-controlled serialised data leads to remote code execution. Control: avoid native deserialisation of untrusted data, integrity checks, type allow-lists.

OWASP Top 10 — its purpose is a widely recognised awareness/reference list of the most critical web application security risks, used to prioritise secure coding training and testing. Know a few categories: broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable/outdated components, identification and authentication failures, software and data integrity failures, logging and monitoring failures, SSRF.

• Preventive: secure SDLC, threat modelling, secure coding training, code review, SAST/DAST, WAF, patching components.
• Detective: WAF/IDS alerts, application logging, anomaly detection, bug bounty reports.
• Corrective: patch, block the vector, rotate secrets, invalidate sessions, restore data.

Identity and credential attacks

• Privilege escalation — vertical: lower-privilege user gains higher privilege (e.g., user → admin). Horizontal: user accesses another user's resources at the same level. Controls: least privilege, patching, separation of duties, privileged access management.
• Preventive: MFA, least privilege, PAM, strong hashing/salting, lockout policy.
• Detective: failed-login analytics, UEBA, impossible travel, privilege-change alerting.
• Corrective: force credential reset, revoke sessions/tokens, disable account, reset service account secrets, re-baseline privileged access.

Advanced and emerging

• Advanced persistent threat (APT): long dwell time, stealth, a specific target, well resourced (nation-state or organised crime), multi-stage. Defence: defence in depth, segmentation, EDR, hunting, network traffic analytics, out-of-band patching, threat intelligence.
• Zero-day: vulnerability with no available patch. Defence: virtual patching (WAF/IPS signatures), least privilege, application allow-listing, segmentation, EDR behaviour blocking.
• Supply chain compromise: trusted vendor/software/update channel weaponised (e.g., SolarWinds-style trojanised update; MOVEit-style mass exploitation). Defence: vendor assurance, software bill of materials, integrity verification, vendor access controls, monitoring third-party access.
• Insider threat — malicious / negligent / compromised: malicious = deliberate theft or sabotage; negligent = careless mistakes, shadow IT; compromised = credentials or device taken over by an external actor. Defence: least privilege, monitoring, separation of duties, DLP (Section A), behavioural analytics, exit controls. Corrective: revoke access, preserve evidence, HR/legal involvement.
• AI-enabled attacks:
  • Deepfake voice/video used for authorisation fraud → controls: callback verification on a known number, code words, dual approval, never authorise payment from a single channel.
  • LLM-assisted phishing with flawless grammar at scale → controls: awareness tuned to remove the "bad grammar" heuristic, DMARC, link isolation.
  • Prompt injection against LLM applications → controls: treat model output as untrusted, sandbox tool/agent permissions, human confirmation for actions, input/output filtering.
  • Model data poisoning → controls: data provenance and integrity checks, controlled training pipelines, evaluation/testing.
  • Sensitive data leaking into third-party AI tools → controls: AI acceptable-use policy, block or broker public AI endpoints, DLP on prompts, enterprise tenants with no-training terms.

Cross-category control summary

Security testing tools and techniques

Vulnerability assessment vs penetration test — the key distinction

• Authenticated (credentialed) scanning sees inside the host (host-based view), finds missing patches and misconfigurations, and produces far fewer false positives. Unauthenticated mimics an external attacker and shows the external attack surface. Best practice: both.
• Internal vs external testing: external = internet-facing perimeter; internal = assumes a foothold behind the firewall, tests segmentation and insider risk.
• Black box (no prior knowledge) vs white box (full knowledge/documentation — most efficient, less realistic) vs grey box (partial knowledge — common, balanced).
• Blind (tester has no knowledge; target IT staff are unaware) vs double-blind (neither tester nor defenders know — tests detection and response, not just vulnerabilities).
• Targeted (specific systems/applications) vs full-scope (all agreed assets).

Methodologies: PTES (Penetration Testing Execution Standard), OSSTMM (Open Source Security Testing Methodology Manual), NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment), OWASP Testing Guide (web application focus).

Rules of engagement — non-negotiable

• Written authorisation / "get-out-of-jail" letter signed by an executive with authority over the systems, defining scope, IP ranges, time windows, prohibited techniques (e.g., DoS, social engineering unless explicitly included), escalation contacts and emergency stop procedure.
• Testing without written authorisation is unacceptable — it may be illegal (unauthorised access offences), a contractual breach and an availability risk. In Hong Kong this intersects with the crimes ordinance provisions on access to computer with criminal or dishonest intent.
• Timing: schedule to avoid critical business periods; notify the relevant operations/security staff (except in a blind test) and agree the stop mechanism.

Auditor's role

• Review the scope, methodology, tester independence and qualifications/certifications, the rules of engagement, and the remediation tracking to closure.
• The auditor does NOT perform the penetration test — independence is compromised, and the auditor must never exploit systems.
• A clean penetration test does not prove the absence of vulnerabilities — it is point-in-time assurance over a defined scope, limited by tester skill, time, method and the changing environment.
• Red team = offensive/adversary simulation (goal-based). Blue team = defence, monitoring, response. Purple team = collaborative, shares findings in real time to improve detection and defence. Red teaming is broader than a pen test (may include social engineering, physical, persistence objectives).

Other tests

• Social engineering tests — phishing simulations, pretext calls; measure click and report rates; require authorisation and HR/legal awareness.
• Physical penetration tests — tailgating, locks, badge cloning; coordinate with facilities and security.
• War dialling — scanning for unauthorised modems; war driving — locating rogue/weak wireless.
• Continuous automated scanning in a DevSecOps pipeline — SAST in the IDE/commit, SCA for dependencies, DAST in staging, IaC scanning, container image scanning; fail the build on defined thresholds. This shifts testing left and complements (does not replace) periodic pen tests.

Third-party testers: certify the vendor (competence, independence, certifications, references), require an NDA, define deliverables, and require that findings are reported to management and remediation is tracked to closure — a report no one actions has no control value.

Security monitoring, logs, tools and techniques

Monitoring is a detective control. Its classic failure modes are the two most-quoted findings: "logs are collected but never reviewed" and "alerts are not triaged within SLA".

Log sources that matter most

SIEM — central platform that aggregates, normalises, correlates, alerts, dashboards, and retains logs. Value comes from use cases and tuning, not ingestion volume. A SIEM with no tuning produces alert fatigue and then the review stops happening — a control failure disguised as a control. SOAR adds orchestration, playbooks and automation (enrich, ticket, contain) to cut response time and analyst toil.

SOC coverage: Tier 1 triage → Tier 2 investigation → Tier 3 hunting/advanced. Considerations: 24x7 coverage needs follow-the-sun shifts or an MSSP; an MSSP requires clear SLAs, escalation paths, defined log sources and periodic assurance that alerts are genuinely worked. UEBA baselines normal behaviour and flags deviations (impossible travel, mass download, off-hours privileged activity).

Threat intelligence and IoCs — feed context (IPs, domains, hashes, TTPs) into detection; must be relevant, timely and actionable, and consumed with a defined process, not just subscribed to.

Continuous monitoring vs periodic review — continuous/automated correlation catches events in near real time; periodic review (daily/weekly log review, monthly access recertification) catches slow drift. Both are needed; assert coverage against a log source inventory to expose monitoring coverage gaps (a finding).

Log integrity and evidence quality

• An attacker with root/administrator can alter or delete local logs → logs must be shipped off-host in near real time, and ideally hashed or written to WORM/immutable storage.
• Chain of custody applies to logs used as evidence: who collected, when, from where, integrity hash, and every transfer.
• NTP clock synchronisation across all sources — without it, correlation is unreliable and timelines in an investigation are unusable.
• Retention driven by regulation, litigation hold, and contract; retention must exceed the typical dwell time or you cannot reconstruct an APT.

Auditor's key test — not "are logs collected?" but: is anyone actually reviewing the alerts, and is there documented evidence of review and follow-up action? Test alert-to-ticket-to-resolution trails, SLA compliance, tuning records, escalation of false negatives, and management reporting of monitoring effectiveness.

Security incident response management

Lifecycle per NIST SP 800-61

Mnemonic — IR lifecycle: "Please Don't Create Recurring Problems" → Preparation, Detection & analysis, Containment/eradication/recovery, Post-incident activity.

IR plan contents: roles and responsibilities (incident response manager/lead, technical leads, communications, legal, HR, management liaison); classification and severity levels with examples; escalation paths and on-call rota; communication plan (internal and external, including when to notify regulators and customers); evidence handling procedures; and contact lists including external parties (law enforcement, forensics firm, legal counsel, insurer, PR).

IR team (CSIRT/CERT) vs SOC: the SOC is the always-on monitoring and triage function; the CSIRT is the response capability invoked for confirmed incidents. A CSIRT typically draws on IT, security, legal, HR, communications and business owners, and may engage external forensics.

Containment strategy ladder

Declaration authority: the plan must name who can invoke it (typically CISO/incident response manager with defined deputies) and how out-of-hours declaration works. Ambiguity here delays containment — itself a finding.

Coordination with BCP/DRP and crisis management: IR handles the attack; BCP/DRP handles continuity of business functions; crisis management handles reputation, stakeholder and executive communications. They must be linked — a ransomware event can trigger all three simultaneously.

Notification obligations and timeframes

Law enforcement notification is a business decision — weigh investigative benefit (asset recovery, attribution, prosecution) against disclosure risk (publicity, loss of control of the timeline, operational disruption). Involve legal counsel. In some jurisdictions and sectors, reporting is mandatory or effectively expected.

Why a breach can be known and not contained: detection is not eradication. The organisation may know it is compromised yet be unable to remove the attacker quickly (no clean backups, no tested rebuild, widespread credentials, unpatchable legacy systems, third-party dependency). Exam answer: containment and eradication capability must be designed and tested before the incident.

Post-incident

• Root cause analysis — not just "the user clicked"; why the click succeeded as a control failure.
• Lessons-learned meeting with all parties, documented.
• Corrective actions tracked to closure with owners and due dates.
• Update the plan, controls and training based on findings.
• Report to management and the board — risk, cost, corrective status, residual exposure.

Supporting arrangements and metrics

• IR retainer with a forensics firm — pre-negotiated, so help arrives in hours not weeks.
• Cyber insurance — check coverage, notification conditions and the approved-vendor panel.
• Tabletop exercises — discussion/decision rehearsal for incidents (distinct from BCP tests, which rehearse continuity of business processes and alternate-site/DR cutover). Both are needed; do not confuse them on the exam.
• Metrics: MTTD (mean time to detect), MTTR (mean time to respond/contain), number of incidents by severity, and percentage of incidents detected internally vs by a third party — the last is a very common exam angle, because external detection indicates monitoring failure.

Auditor's test: review the plan and past incident records end-to-end — validate that classification, escalation, containment, communication, evidence handling and post-incident actions were actually followed, not merely documented.

Evidence collection and forensics

Digital evidence characteristics — for evidence to carry weight it must be:

Plus relevance (it must bear on the matter) and the "best evidence" principle — produce the original or a provably accurate copy, which is why hashed forensic images of originals are used.

Order of volatility (RFC 3227) — capture most volatile first

Mnemonic — order of volatility: "Really Careful Teams Never Damage Archived Paper" → Registers/cache, Cache-routing-process-memory, Temp file systems, Network/remote logs & disk, Device/physical configuration, Archival media, Paper.

Why most volatile first: it disappears on power-down or within seconds (e.g., encryption keys and C2 connections exist only in memory). Capture it before it is gone.

Chain of custody

• Records: who collected, what was collected, when, where it was found, why it matters, and every transfer/access thereafter (seal numbers, signatures, dates, times).
• An unbroken chain is required to show the evidence has not been altered or substituted.
• Use evidence bags and tamper-evident seals, unique identifiers/labels, dedicated evidence storage.
• Hash the image (MD5/SHA-256) at capture and re-verify — proves no alteration. SHA-256 is preferred today; MD5 may still appear in older procedures.
• Never analyse the original. Work on a forensic copy/image. Use write blockers for hardware acquisition and hardware forensic duplication for speed and integrity.

Live vs dead-box forensics

Discipline types: memory forensics (processes, injected code, keys), disk forensics (file system, deleted files, slack space, artefacts), network forensics (packet captures, NetFlow, firewall/VPN logs), mobile forensics (isolation from networks to prevent remote wipe; full-device extraction where lawful), and cloud forensics.

Cloud forensics — specific challenges: data may reside in another jurisdiction (legal process and privacy conflicts); no physical access to hardware; dependence on provider cooperation and on logs the customer cannot obtain; short log retention by default; multi-tenancy complicating attribution and isolation; and volatile data the customer cannot snapshot without provider APIs. Mitigation: contractual rights to logs and forensics support agreed before an incident, and early legal engagement.

Anti-forensics techniques the attacker may use

• Log wiping / selective deletion — defeats reconstruction; countered by off-host near-real-time log shipping and WORM storage.
• Timestomping — altering MAC (modified/accessed/created) times to defeat the timeline; countered by artefact cross-correlation and file-system journal analysis.
• Encryption / packing — hides content; countered by memory capture for keys and by lawful key recovery.
• Steganography — data hidden inside legitimate media.
• Data hiding in slack space or unallocated space.

Why early containment and imaging matter: the longer the delay, the more volatile evidence and remote logs are lost, and the more opportunity the attacker has to clean up.

Forensic readiness — prepare in advance

• Enable and retain the right logs, with sufficient retention and time sync.
• Documented legal hold procedure so data is not purged or overwritten.
• Pre-approved forensic vendor and internal trained responders.
• Evidence collection kits (write blockers, imaging tools, labels, seals, documentation forms).
• Documented procedures and training/drills.

Legal considerations

• Involving law enforcement is a business/legal decision made with counsel; consider mandatory reporting rules.
• Privacy and works-council constraints on monitoring employee devices — monitoring must be lawful, proportionate, disclosed in policy, and often subject to consultation.
• An investigation (fact-finding about a specific alleged event, potentially leading to disciplinary or legal action) is not an audit (independent assessment of the control environment). Different objectives, evidence standards and reporting lines.
• The auditor may need to hand off to a forensic specialist rather than proceed — this is a very common correct answer.

The auditor's specific responsibilities

1. Preserve — do not disturb the scene; do not open, run, or power-cycle suspect systems without forensic guidance.
2. Do not contaminate — no analysis on originals; no casual copying that changes metadata.
3. Document — record observations, times, people present and actions taken.
4. If fraud or a crime is suspected, escalate, involve legal counsel and specialists rather than investigating personally.
5. Understand that IT audit's role is to assess the control environment and the investigation process, not to conduct the criminal investigation.

TRAPS

• Containment comes before eradication, and both come before recovery. Restoring a system that still has the attacker's persistence re-infects you.
• The auditor reviews the penetration test; the auditor does not run it. Any answer where the auditor exploits, attacks or tunes tools is wrong — independence.
• Capture the most volatile evidence first (registers/memory before disk before backups before paper).
• A clean penetration test is point-in-time assurance, not proof of security and not a statement that no vulnerabilities exist.
• MTTD matters more than MTTR — you cannot respond to what you did not detect. Also: incidents first detected by a third party signal a monitoring failure.
• Do not investigate fraud yourself — escalate and preserve. Involve legal counsel and forensic specialists; audit assesses the process.
• Never analyse the original. Image it, hash it, work on the copy.
• Policy acknowledgement ≠ comprehension. Completion rates are not effectiveness metrics.
• A SIEM without tuning produces alert fatigue and becomes a non-control. Test whether alerts are actually triaged to SLA.
• Logs on a host an attacker controls are not evidence until shipped off-host and integrity-protected.
• No NTP, no correlation. Unsynchronised clocks make timelines unusable.
• Vulnerability assessment ≠ penetration test. Assessment identifies; pen test exploits.
• Testing without written authorisation is unacceptable (and may be illegal) regardless of good intent.
• PCI DSS requires annual awareness training; GDPR uses a 72-hour regulator clock "where feasible" and data-subject notice "without undue delay" for high risk.
• Tabletop incident exercises ≠ BCP tests. Incidents vs business continuity.
• Ransomware: paying does not guarantee recovery and may breach sanctions/legal obligations — the exam answer favours offline/immutable backups and tested recovery.
• Double extortion = encryption + exfiltration; assume data theft even if backups restore cleanly, which changes notification obligations.
• MFA defeats credential stuffing and most password spraying, but not MFA-fatigue/consent-phishing — then the control is number-matching/conditional access.
• Least privilege and callback verification beat detection for BEC: the payment verification call to a known number is the control, not the email warning banner.
• Privileged users need additional training, and contractors/new joiners must be covered before access is granted.
• Termination: revoke access first, then assets, then knowledge transfer.

60-second recall

• Human is the most-targeted surface → awareness is a preventive control; measure click rate down, report rate up, not completion.
• Vulnerability assessment finds; penetration test exploits — pen test usually follows assessment.
• Written authorisation / get-out-of-jail letter is mandatory; scope, timing, prohibited techniques, stop procedure.
• Auditor: review scope, methodology, tester independence, remediation tracking. Never exploit.
• Clean pen test = point-in-time assurance, not proof of security.
• IR lifecycle: Preparation → Detection & analysis → Containment/Eradication/Recovery → Post-incident. "Please Don't Create Recurring Problems."
• Containment before eradication before recovery, with validation before returning to production.
• Order of volatility: registers/cache → memory/routing/process → temp FS → disk & remote logs → physical config → archival media → paper. "Really Careful Teams Never Damage Archived Paper."
• Chain of custody: who, what, when, where, why + every transfer, seals, unique IDs, hash the image, never analyse the original, use write blockers.
• GDPR: 72 hours to the supervisory authority where feasible; data subjects without undue delay if high risk.
• MTTD > MTTR; incidents detected by third parties = monitoring failure.
• Logs off-host in near real time + NTP + WORM/hashing + retention beyond dwell time.
• SIEM = aggregate, normalise, correlate, alert, retain; untuned SIEM → alert fatigue → classic finding "logs collected but never reviewed".
• Malware: worm self-propagates without a host; ransomware = double/triple extortion; signature detection fails on new variants → EDR/behavioural.
• BEC control = independent callback verification to a known number + dual authorisation + DMARC + MFA.
• Credential attacks: MFA, salting, lockout, PAM; vertical vs horizontal privilege escalation.
• APT = long dwell time, stealth, specific target; zero-day → virtual patching + least privilege + allow-listing.
• Deepfakes → out-of-band verification and dual approval; prompt injection → treat model output as untrusted, sandbox tool permissions.
• Chain of custody failure = evidence inadmissible; forensic readiness (logging, retention, legal hold, vendor retainer, kits, training) decided before the incident.
• Suspected fraud → preserve, document, escalate to legal and specialists; audit assesses the process, it does not investigate.