| Day | Domains | Exam Weight | Focus Areas |
|---|---|---|---|
| Monday | D1 + D2 | 26% | Risk, Governance, Compliance, Legal, BCP, Data Classification, Privacy |
| Tuesday | D3 | 13% | Security Models, Cryptography, PKI, System Architecture, Cloud |
| Wednesday | D4 | 13% | OSI/TCP-IP, Protocols, Firewalls, VPN, Wireless, Network Attacks |
| Thursday | D5 | 13% | Authentication, Biometrics, SSO, Kerberos, SAML/OAuth, Authorization |
| Friday | D6 + D8 | 22% | Pen Testing, Audits, SOC Reports, SDLC, Secure Coding, OWASP |
| Saturday | D7 | 13% | Incident Response, Forensics, SIEM, DRP, Backup, Physical Security |
| Sunday | Cross-Review | 100% | Formulas, Mnemonics, Exam Traps, Weak Areas, Brain Dump Practice |
| # | Canon | Obligation | Key Point |
|---|---|---|---|
| 1 | Protect Society | Common good, public trust, infrastructure | Overrides ALL other canons — report even if employer objects |
| 2 | Act Honourably | Honestly, justly, responsibly, legally | Towards principals, clients, employers |
| 3 | Provide Diligent Service | Competent service to principals | Don't practice outside your competence |
| 4 | Advance the Profession | Personal development, professional integrity | Self-interest is ALWAYS last |
| Property | Goal | Attacks (DAD) | Controls |
|---|---|---|---|
| Confidentiality | Prevent unauthorised disclosure | Disclosure | Encryption, access controls, classification |
| Integrity | Prevent unauthorised modification | Alteration | Hashing, digital signatures, change mgmt |
| Availability | Ensure timely access | Destruction/DoS | Redundancy, backups, DR plans |
| Concept | Meaning |
|---|---|
| Non-repudiation | Cannot deny action (digital signatures) |
| Authenticity | Verified identity of sender/data |
| Accountability | Actions traceable to individual (audit logs) |
| Defense in Depth | Multiple layered controls |
| Level | Who | Does What | Artefacts |
|---|---|---|---|
| Governance | Board / Senior Mgmt | Direction, oversight, risk appetite | Policies, charters |
| Management | CISO / Directors | Planning, resource allocation, controls | Standards, procedures |
| Operations | IT / Security Teams | Execution, monitoring, response | Logs, tickets, configs |
| Role | Responsibility | Key Distinction |
|---|---|---|
| Data Owner | Classifies data, approves access, sets policy | Business executive — NOT IT |
| Data Custodian | Implements controls, backups, maintenance | IT/sysadmin — follows Owner's decisions |
| Data Steward | Data quality, metadata, compliance | Day-to-day governance |
| Data Processor | Processes data on behalf of controller | GDPR term — think cloud provider |
| Data Controller | Determines purpose of processing | GDPR term — think your organisation |
| Process | Security Impact |
|---|---|
| Acquisitions | Due diligence on target's security posture; inherited risk/compliance debt; data integration classification |
| Divestitures | Data separation; access revocation; IP protection; contractual security obligations to buyer |
| Governance Committees | Board-level risk committee; security steering committee; cross-functional oversight of security strategy |
| Framework | Focus | Key Feature |
|---|---|---|
| NIST CSF 2.0 | Cybersecurity risk | 6 Functions: Govern→Identify→Protect→Detect→Respond→Recover |
| ISO 27001 | ISMS | Certifiable; 10 clauses + Annex A (93 controls) |
| ISO 27002 | Control guidance | NOT certifiable — guidance for Annex A |
| COBIT | IT governance | ISACA; aligns IT with business goals |
| NIST RMF | Risk management | 7 Steps: Prepare→Categorise→Select→Implement→Assess→Authorise→Monitor |
| NIST SP 800-53 | Security & privacy controls | Comprehensive control catalog (20 families); used by RMF control selection step |
| NIST SP 800-171 | CUI protection | Non-federal orgs handling Controlled Unclassified Information; 110 controls |
| TOGAF / SABSA | EA / Security architecture | Enterprise architecture frameworks |
| FedRAMP | Cloud for US govt | Standardised cloud security assessment; based on NIST 800-53; Authorise → Monitor |
| Regulation | Scope | Key Requirements | Penalties / Notes |
|---|---|---|---|
| GDPR | EU personal data | 7 principles; 72-hr breach notification; DPO required for large-scale processing | Up to 4% global revenue or €20M |
| HIPAA | US healthcare (PHI) | Privacy Rule + Security Rule + Breach Notification | 60-day breach notification to HHS |
| SOX | US public companies | Sec 302/404: internal controls over financial reporting | CEO/CFO personal criminal liability |
| PCI-DSS | Payment card data | 6 goals, 12 requirements | Contractual (not law); fines via card brands |
| GLBA | US financial services | Privacy + Safeguards + Pretexting Rules | Financial institution security plans |
| FERPA | US student records | Parental consent for disclosure | Loss of federal funding |
| FISMA | US federal agencies | NIST RMF mandatory | Annual security reports |
| CCPA/CPRA | California consumers | Right to Know/Delete/Opt-Out/Correct | $7,500/intentional violation |
| PIPL | China personal information | Consent-based; data localisation; cross-border transfer restrictions | Up to 5% annual revenue; personal liability for DPOs |
| POPIA | South Africa personal info | 8 conditions for lawful processing; Information Regulator oversight | Fines up to ZAR 10M or imprisonment |
| Regulation | Notify | Timeframe |
|---|---|---|
| GDPR | Supervisory authority | 72 hours |
| HIPAA | HHS (+ individuals if >500) | 60 days |
| PCI-DSS | Card brands + acquirer | ASAP (contractual) |
| System | Basis | Where |
|---|---|---|
| Common Law | Precedent + judicial interpretation | UK, US, Australia |
| Civil/Code Law | Comprehensive written legal codes | Continental Europe, Latin America |
| Religious Law | Faith-based (Sharia, Canon) | Some Middle Eastern / Vatican |
| Customary Law | Tradition-based | Parts of Africa, Asia |
| Type | Who Initiates | Burden of Proof | Outcome |
|---|---|---|---|
| Criminal | Government (prosecutor) | Beyond reasonable doubt | Imprisonment, fines |
| Civil (Tort) | Victim (plaintiff) | Preponderance of evidence (51%+) | Money damages |
| Administrative | Regulatory agency | Substantial evidence | Licence revocation, fines |
All four must be proven. If any element is missing, no negligence claim.
| Type | Protects | Duration | Key Distinction |
|---|---|---|---|
| Copyright | Creative expression (code, books, art) | Life + 70 years (individual); Work-for-hire: 95 yrs from pub / 120 yrs from creation | Automatic; protects expression NOT ideas |
| Trademark | Brand identity (logos, names) | Unlimited (if maintained) | ™ = claimed; ® = registered |
| Patent | Novel inventions | 20 yrs (utility) / 15 yrs (design) | Requires public disclosure |
| Trade Secret | Confidential business info | Unlimited (if actively protected) | No registration — lost if disclosed |
| Licence | Copyleft? | Commercial Risk |
|---|---|---|
| GPL | Strong (viral) | HIGH — derivative works must be GPL |
| LGPL | Weak (library only) | MEDIUM — library changes shared |
| MIT / Apache / BSD | None (permissive) | LOW — free for commercial use |
Evidence must be: Relevant + Reliable + Legally Obtained
Business Records Exception: System logs kept in the ordinary course of business are admissible despite the hearsay rule.
CFAA (Computer Fraud and Abuse Act): Criminalises unauthorised access to protected computers; both civil & criminal remedies.
| Regulation | Scope | Key Point |
|---|---|---|
| EAR (Export Administration Regulations) | Dual-use items (commercial + military potential) | Administered by Bureau of Industry & Security (BIS); includes encryption software |
| ITAR (International Traffic in Arms Regulations) | Defence articles & services | Administered by State Dept (DDTC); strict controls on military tech exports |
| Wassenaar Arrangement | 42 countries; conventional arms + dual-use tech | Voluntary; limits export of surveillance/intrusion tools |
| Type | Purpose | Standard of Proof | Who Conducts |
|---|---|---|---|
| Administrative | Internal policy violation | Preponderance | Internal HR / Security |
| Criminal | Law enforcement prosecution | Beyond reasonable doubt | Law enforcement (FBI, police) |
| Civil | Disputes / damages | Preponderance (51%+) | Attorneys / courts |
| Regulatory | Compliance violations | Substantial evidence | Regulatory bodies (SEC, GDPR DPA) |
| Industry Standards | PCI-DSS violations | Contractual terms | QSA (Qualified Security Assessor) |
| Document | Level | Nature | Changes | Example |
|---|---|---|---|---|
| Policy | Strategic (WHY) | Mandatory; signed by mgmt | Rare | "All data must be encrypted at rest" |
| Standard | Tactical (WHAT) | Mandatory; measurable | Moderate | "Use AES-256 for encryption" |
| Procedure | Operational (HOW) | Mandatory; step-by-step | Frequent | "Click Settings → Enable encryption..." |
| Baseline | Minimum config | Mandatory minimum | Per platform | CIS Benchmarks, DISA STIGs |
| Guideline | Advisory (SHOULD) | Optional; recommended | Flexible | "Consider using password managers" |
| Term | Definition |
|---|---|
| Asset | Anything of value |
| Threat | Potential harmful event |
| Vulnerability | Exploitable weakness |
| Risk | Threat × Vulnerability × Impact |
| Exploit | Method to leverage a vulnerability |
| Control | Safeguard/countermeasure to reduce risk |
| Term | Definition |
|---|---|
| Risk Appetite | Risk the org will accept (board sets) |
| Risk Tolerance | Acceptable variation within appetite |
| Risk Capacity | Max risk the org can absorb before failure |
| Residual Risk | Risk remaining after controls |
| Inherent Risk | Risk before any controls |
| Total Risk | Threat × Vuln × Asset Value |
| Response | Action | Residual Risk | Example |
|---|---|---|---|
| Mitigate | Reduce via controls | Reduced (still > 0) | Install firewall, deploy MFA |
| Accept | Documented decision to bear risk | Unchanged | Low-impact risk below appetite |
| Transfer | Shift financial burden to third party | Financial impact shifted | Cyber insurance, outsourcing |
| Avoid | Eliminate the risky activity | Zero (only response = 0) | Discontinue CC storage |
| Function ↓ / Category → | Administrative | Technical | Physical |
|---|---|---|---|
| Preventive | Policies, screening | Firewalls, encryption | Locks, fences |
| Detective | Audits, reviews | IDS, SIEM, logs | CCTV, motion sensors |
| Corrective | Incident response plan | Patching, AV quarantine | Fire suppression |
| Deterrent | Warnings, AUP | Login banners | Warning signs, guards |
| Recovery | DRP, BCP | Backups, failover | Alternate site |
| Compensating | Supervision | Monitoring when MFA unavailable | Escort when badge fails |
| Threat | Violates | Control |
|---|---|---|
| Spoofing | Authentication | MFA, certificates |
| Tampering | Integrity | Hashing, digital signatures |
| Repudiation | Non-repudiation | Audit logs, digital signatures |
| Information Disclosure | Confidentiality | Encryption, access controls |
| Denial of Service | Availability | Rate limiting, redundancy |
| Elevation of Privilege | Authorisation | Least privilege, sandboxing |
| Method | Focus | Key Feature |
|---|---|---|
| PASTA | Risk-centric, 7 stages | Business impact alignment; attack simulation |
| DREAD | Scoring (legacy) | Damage · Reproducibility · Exploitability · Affected Users · Discoverability |
| Attack Trees | Attacker goal decomposition | Root = goal, branches = paths; AND/OR nodes |
| MITRE ATT&CK | Real-world TTPs | Tactic (why) → Technique (how) → Procedure (specific); for detection/hunting |
| LINDDUN | Privacy threats | Like STRIDE but for data privacy |
| # | Mechanism | Strength | Key Point |
|---|---|---|---|
| 1 | SOC 2 Type II | Strongest | 6–12 months operational effectiveness |
| 2 | Right-to-Audit Clause | High | Direct assurance but expensive |
| 3 | SOC 2 Type I | Medium | Point-in-time snapshot only |
| 4 | ISO 27001 Certification | Medium | Annual surveillance audits |
| 5 | Penetration Test Results | Low-Med | Technical only, no process assurance |
| 6 | Security Questionnaire | Weakest | Self-reported, no verification |
| Mechanism | Description |
|---|---|
| Silicon Root of Trust | Hardware-anchored secure boot chain; cryptographic verification starts in immutable chip firmware — prevents firmware-level tampering |
| Physically Unclonable Function (PUF) | Unique hardware fingerprint from manufacturing variations; used for device authentication and anti-counterfeiting |
Uptime % · Incident Response Time · Breach Notification · Data Handling & Residency · Audit Rights · Subcontractor Requirements · Penalties
| Aspect | BCP | DRP |
|---|---|---|
| Scope | Entire business (people, processes, facilities, tech) | IT systems only |
| Goal | Keep operating during disruption | Restore systems after disruption |
| Relationship | Parent plan | Subset of BCP |
| Metric | Meaning | Who Sets It | Key Relationship |
|---|---|---|---|
| MTD | Maximum Tolerable Downtime | Business (management) | Deadline — business fails after this |
| RTO | Recovery Time Objective | IT + Business | Time to restore system function |
| RPO | Recovery Point Objective | Business | Max acceptable data loss (time) |
| WRT | Work Recovery Time | IT | Time to verify & resume after restore |
| RPO | Backup Strategy | Cost |
|---|---|---|
| 24 hours | Daily backup | Low |
| 4 hours | Every 4 hours | Medium |
| Near-zero | Real-time replication | Highest |
| Site | Activation | Cost | Best RTO | Includes |
|---|---|---|---|---|
| Hot | Minutes–hours | Highest | < 4 hrs | Full equipment + real-time data |
| Warm | Hours–days | Medium | 4–72 hrs | Partial equipment + recent backups |
| Cold | Days–weeks | Lowest | > 72 hrs | Empty facility, power/cooling only |
| Cloud | Minutes–hours | Pay-per-use | Flexible | Virtual infrastructure on demand |
| Mobile | Hours | Medium | Variable | Portable pre-configured container |
| Reciprocal | Variable | Low | Variable | Peer agreement — unreliable |
| Test Type | Disruption | Description |
|---|---|---|
| 1. Checklist Review | None | Review plan document |
| 2. Tabletop Exercise | None | Scenario walkthrough, discussion-based |
| 3. Simulation | Low-Med | Simulated disaster, practice response |
| 4. Parallel Test | Medium | Activate recovery site while primary runs |
| 5. Full Interruption | High | Shut down primary, switch to backup (most realistic) |
| Phase | Key Actions | Key Controls |
|---|---|---|
| Hire | Background checks, credential verification, credit history | Pre-employment screening |
| Employment Agreements | NDA, NCA, AUP, IP Assignment signed | Legal bindings established |
| Access Provisioning | Least privilege + need to know + SoD | Role-based access |
| Practice | Job rotation, mandatory vacation | Fraud detection + knowledge resilience |
| Separation | Exit interview, equipment return | REVOKE ACCESS FIRST |
| Control | Purpose | Type | Key Distinction |
|---|---|---|---|
| Separation of Duties (SoD) | Prevent single-person fraud | Preventive | TWO people needed simultaneously |
| Job Rotation | Detect fraud + build resilience | Detective | Periodic REPLACEMENT of role |
| Mandatory Vacation | Expose fraud requiring presence | Detective | Temporary REMOVAL (1-2 weeks) |
| Least Privilege | Minimum permissions for duties | Preventive | WHAT YOU DO (permissions) |
| Need to Know | Information limited to necessity | Preventive | WHAT YOU SEE (information) |
| Agreement | Purpose | Duration |
|---|---|---|
| NDA | Confidentiality prohibition | Survives termination |
| NCA | Non-compete restriction | Time & geo-limited (enforceability varies) |
| AUP | IT resource usage rules; monitoring basis | During employment; must sign before access |
| IP Assignment | Work product ownership | During employment scope |
| Tier | Audience | Depth | Examples |
|---|---|---|---|
| Awareness | ALL staff | Shallow — recognition | Phishing posters, email tips, videos |
| Training | Role-specific groups | Skills-based — measurable | Secure coding for devs, BEC for finance |
| Education | Security professionals | Deep — conceptual | CISSP, university programmes, SANS |
| Vector | Method | Defence |
|---|---|---|
| Phishing | Mass deceptive email | Awareness + email filter + MFA |
| Spear Phishing | Targeted individual | Role training for high-value targets |
| Whaling | C-suite targeting | Executive awareness + financial verification |
| Vishing | Voice call impersonation | Identity verification; callback protocol |
| Smishing | SMS phishing | Mobile policy awareness |
| Pretexting | False scenario extraction | Need-to-know; verification protocols |
| Tailgating | Physical follow-through | Badge-only entry; anti-tailgating awareness |
| Baiting | Infected USB drop | Port controls; autorun blocking |
| Technique | Description |
|---|---|
| Security Champions | Embedded advocates within dev/business teams; bridge between security team and staff; peer influence |
| Gamification | Points, leaderboards, badges for security behaviours; increases engagement over traditional CBT |
| Topic | Mnemonic | Expands To |
|---|---|---|
| Ethics Canons | SAPA | Society → Act honourably → Provide service → Advance profession |
| Policy Hierarchy | "Please Stop Playing Basketball, Gary" | Policy → Standard → Procedure → Baseline → Guideline |
| Risk Response | MATA | Mitigate → Accept → Transfer → Avoid |
| BIA Metrics | "The Four Clocks" | MTD → RTO → RPO → WRT |
| NIST CSF 2.0 | GI-PD-RR | Govern → Identify → Protect → Detect → Respond → Recover |
| NIST RMF | "Please Can Sally Implement All Authorised Monitoring" | Prepare → Categorise → Select → Implement → Assess → Authorise → Monitor |
| STRIDE | S-T-R-I-D-E | Spoofing · Tampering · Repudiation · Information Disclosure · DoS · Elevation |
| BCP Testing | "Can This Walk? Simulate Parallel Full!" | Checklist → Tabletop → Walkthrough → Simulation → Parallel → Full Interruption |
| Recovery Sites | HOT→WARM→COLD | Ready → Soon → Later (temp = urgency = cost) |
| Employment Lifecycle | HEAPS | Hire → Employ (agreements) → Access → Practice → Separation |
| Awareness Tiers | ATE | Awareness → Training → Education (wider = shallower) |
| Due Care vs Diligence | Care=Act, Diligence=Check | Due Care = doing right; Due Diligence = verifying |
| GDPR Principles | LPDA-SIA | Lawfulness · Purpose · Data min · Accuracy · Storage · Integrity · Accountability |
| Negligence | D-B-C-D | Duty → Breach → Causation → Damages |
| OECD Privacy | 8 principles | Collection · Quality · Purpose · Use · Security · Openness · Participation · Accountability |
| # | Trap | Correct Answer |
|---|---|---|
| 1 | Data Owner is IT / sysadmin | Data Owner = business executive; Custodian = IT |
| 2 | ISO 27002 is certifiable | Only ISO 27001 is certifiable; 27002 is guidance |
| 3 | "Ignore" as risk response | Not valid. Use "Accept" (documented decision) |
| 4 | Transfer eliminates accountability | Transfers financial burden only, NOT legal liability |
| 5 | Compliance = security | Compliance is the floor, not the ceiling |
| 6 | Copyright protects ideas | Copyright protects expression not ideas |
| 7 | Trade secrets auto-protected | Require active protection or they are lost |
| 8 | GPL is safe for commercial | GPL is viral/copyleft — derivative works must be GPL |
| 9 | EF is a percentage number (50) | EF is a decimal (0.50) |
| 10 | Ransomware primarily hits confidentiality | Primary target = Availability (to extort payment) |
| 11 | Hot site is always the right answer | Choose cheapest option meeting MTD/RTO/RPO |
| 12 | First action in disaster = restore systems | First action = personnel safety |
| 13 | First action on termination = exit interview | First action = revoke access immediately |
| 14 | SoD prevents collusion | SoD prevents fraud, NOT collusion |
| 15 | RTO = total recovery time | RTO + WRT ≤ MTD; WRT is verification time after restore |
| 16 | Mandatory vacation is preventive | Mandatory vacation = detective (exposes fraud) |
| 17 | Training completion = effectiveness | Behavioural metrics (click/report rate) > activity metrics |
| 18 | Canon 3 (employer) over Canon 1 (society) | Society always first — whistle-blowing justified |
| 19 | Reciprocal agreements are reliable | Unreliable — both orgs may face same disaster |
| 20 | Least Privilege = Need to Know | LP = permissions (what you do); NtK = information (what you see) |
| 21 | Due care = due diligence | Due care = doing the right thing (actions/implementation); due diligence = verifying it was done correctly |
| 22 | CISO is ultimately responsible for security | Senior management is ultimately responsible; CISO advises |
| 23 | Risk appetite = risk tolerance | Risk appetite is strategic/broad; risk tolerance is tactical/specific |
| 24 | Delphi technique = group brainstorming | Delphi = anonymous expert consensus (reduces groupthink) |
| 25 | BIA and Risk Assessment do the same thing | BIA = impact; Risk Assessment = likelihood (both required) |
| 26 | Criminal and administrative law are the same | Criminal/civil/administrative have different standards and penalties |
| 27 | MTD is set by IT based on technical capability | MTD is set by the business; IT aligns RTO/RPO to meet it |
| 28 | Prudent person rule doesn't apply to cybersecurity | Prudent Person Rule is used to assess due care in cybersecurity decisions |
| Government | Commercial |
|---|---|
| Top Secret | Confidential / Restricted |
| Secret | Private |
| Confidential | Sensitive |
| Sensitive But Unclassified (SBU) | Public |
| Unclassified | — |
| Role | Responsibility | Key Point |
|---|---|---|
| Data Owner | Senior management; determines classification, access rules, protection requirements | ULTIMATELY accountable; usually C-suite / VP |
| Data Custodian | Implements & maintains technical controls (backups, encryption, access controls) | Usually IT; follows Owner's directives |
| Data Steward | Ensures data quality, metadata management, compliance with policies | Day-to-day data accuracy & integrity |
| System Owner | Owns the system processing the data; responsible for system security | Different from Data Owner |
| Data Controller (GDPR) | Determines WHY and HOW personal data is processed | Primary GDPR liability |
| Data Processor (GDPR) | Processes data on behalf of the controller | If exceeds instructions → BECOMES controller |
| Stage | Key Controls |
|---|---|
| 1. Create | Classify at creation, assign owner, apply labels/tags |
| 2. Store | Encryption at rest, access controls, backup strategy, geographic constraints |
| 3. Use | DRM/IRM enforcement, monitoring, DLP endpoint agents, TEE for sensitive ops |
| 4. Share | Encryption in transit (TLS), DLP gateway, watermarking, access verification |
| 5. Archive | Long-term compliant storage, retention schedules, encryption key preservation |
| 6. Destroy | NIST 800-88 sanitisation (Clear/Purge/Destroy), Certificate of Destruction |
| Classification | Handling Requirements |
|---|---|
| Top Secret / Confidential | Encrypted storage & transit, strict need-to-know, clean desk, secure destruction, audit logging |
| Secret / Private | Encrypted where practical, role-based access, controlled distribution |
| Sensitive / Internal | Basic access controls, labelling |
| Public | Integrity protection (prevent unauthorised modification) |
| Technique | Description | Reversible? |
|---|---|---|
| Anonymisation | Irreversibly removes all PII; cannot re-identify | ❌ No |
| Pseudonymisation | Replaces identifiers with tokens/aliases; can re-identify with mapping key | ✅ Yes |
| Tokenisation | Substitutes sensitive value with non-sensitive token; token vault stores mapping | ✅ Yes (with vault) |
| Data Masking | Hides portions of data (e.g., XXX-XX-1234); static or dynamic | Depends on type |
| Generalisation | Reduces precision (exact age → age range) | ❌ No |
| Regulation | Retention |
|---|---|
| SOX (Financial) | 7 years |
| HIPAA (Health) | 6 years |
| PCI-DSS (Payment) | 1 year |
| GDPR | As long as necessary (minimisation) |
| Level | Method | Robustness | Media Reusable? |
|---|---|---|---|
| Clear | Logical overwrite (patterns) | Defeats standard recovery | Yes |
| Purge | Degaussing, ATA Secure Erase, crypto-erase | Defeats forensic lab | Usually |
| Destroy | Shredding, incineration, disintegration | Media non-functional | No |
| Term | Meaning | Action Required |
|---|---|---|
| EOL | Vendor stops selling/manufacturing | Plan migration; no new deployments |
| EOS | Vendor stops patches & support | Replace or isolate; no security updates → critical risk |
| State | Where | Protection |
|---|---|---|
| At Rest | Disk, DB, tape, SAN | AES-256, FDE, TDE, file-level encryption |
| In Transit | Network, Internet, VPN | TLS 1.3, IPSec, SSH, HTTPS |
| In Use | CPU, RAM, registers | TEE (SGX, TrustZone), homomorphic encryption |
| Technology | Purpose |
|---|---|
| DRM/IRM | Persistent content protection; controls copy, print, forward, screenshot |
| CASB | Cloud security broker: Visibility, Compliance, Data Security, Threat Protection |
| DLP | Content-based detection & blocking of unauthorised data flows |
| TPM | Hardware crypto processor on motherboard; stores keys, integrity measurements |
| HSM | Dedicated hardware for key management; FIPS 140-2/3 Level 3+; tamper-resistant |
| DLP Type | Location | Data State | Key Threat |
|---|---|---|---|
| Network DLP | Gateway / proxy | In transit | Email/web exfiltration |
| Endpoint DLP | Agent on device | At rest + in use | USB copy, print, off-network |
| Cloud DLP / CASB | API to cloud | At rest in cloud | Shadow IT, SaaS exposure |
| Topic | Rule |
|---|---|
| Max Fine | €20M or 4% global annual turnover (whichever higher) |
| Breach → Supervisory Auth | Within 72 hours of controller awareness |
| Breach → Data Subjects | Without undue delay IF high risk |
| DPO Required When | Public body, large-scale monitoring, special category data |
| Right to Erasure | NOT absolute — 6 exceptions (legal claims, legal obligation, public health, archiving, freedom of expression, public interest) |
| Mechanism | Description |
|---|---|
| Adequacy Decision | EC determines country has adequate protection |
| SCCs | Pre-approved contractual clauses (most widely used post-Schrems II) |
| BCRs | Intra-group rules for multinationals (complex, expensive) |
| EU-US DPF | July 2023 adequacy decision (replacing Privacy Shield) |
| # | Mnemonic | Helps Remember |
|---|---|---|
| 1 | "Cats Sleep Under Soft Autumn Duvets" | Data Lifecycle: Create, Store, Use, Share, Archive, Destroy |
| 2 | "CPD — Can Parrots Dance?" | Sanitisation: Clear → Purge → Destroy |
| 3 | "RAT" | Data states: Rest, Air/transit, Thinking/use |
| 4 | "NEC" | DLP types: Network, Endpoint, Cloud/CASB |
| 5 | "MAB" | DLP sequence: Monitor, Alert, Block |
| 6 | "SSD = Sad, Stubborn Data" | Overwriting doesn't work, degaussing worthless; use crypto-erase |
| 7 | "Cloud Key = Cloud Bye" | Destroy encryption key = destroy all cloud copies |
| 8 | "I ACCESS DP" | GDPR data subject rights |
| 9 | "L-P-D-A-S-I-A" | GDPR 7 principles |
| 10 | "72 → SA; High Risk → Subject" | GDPR breach notification timeline |
| # | Trap |
|---|---|
| 1 | "Confidential" is LOWEST govt classified but HIGHEST commercial level |
| 2 | Data Owner = senior management (NOT IT staff); Custodian = IT |
| 3 | Degaussing SSDs = ZERO effect (data fully intact) |
| 4 | DoD 5220.22-M overwrite UNRELIABLE for SSDs (wear-leveling bypasses it) |
| 5 | Crypto-erase = preferred for SSDs AND cloud |
| 6 | Degaussed HDD becomes permanently inoperable (servo tracks destroyed) |
| 7 | Litigation hold OVERRIDES all retention schedules |
| 8 | Anonymised data = GDPR no longer applies; Pseudonymised = GDPR still applies |
| 9 | Processor exceeding instructions BECOMES a controller (full liability) |
| 10 | Right to Erasure is NOT absolute (6 major exceptions) |
| 11 | DPO cannot hold CISO/CTO/CEO roles simultaneously (conflict of interest) |
| 12 | 72-hour GDPR clock starts at controller awareness, not incident discovery |
| 13 | Network DLP requires SSL inspection to see HTTPS content |
| 14 | Data in use is HARDEST to protect (requires hardware TEE) |
| 15 | FDE useless on powered-on, logged-in devices |
| 16 | FALSE: Data steward = data owner. CORRECT: Data steward manages data quality, metadata, and day-to-day governance. Data owner (senior management) determines classification and access policy — they are ultimately accountable for the data. |
| 17 | FALSE: Scoping = tailoring. CORRECT: Scoping = selecting which baseline controls apply to a specific system (include/exclude). Tailoring = customising the parameters of chosen controls to fit the organisation. Scope first, then tailor. |
| 18 | FALSE: Marking and labelling are the same. CORRECT: Marking = making classification visible on document content (headers, footers, banner pages, metadata tags). Labelling = physical indicator on media or hardware (adhesive label, barcode tag). Marking is for documents; labelling is for physical assets. |
| 19 | FALSE: All sanitisation methods are equivalent. CORRECT: NIST SP 800-88 defines three escalating levels — Clear (logical overwrite; media reusable; defeats standard recovery tools) → Purge (degauss / crypto-erase / secure-erase; defeats forensic tools; media often reusable) → Destroy (shred/incinerate; no reuse; highest assurance). Match level to data sensitivity and media reuse requirement. |
| Principle | Meaning |
|---|---|
| Least Privilege | Minimum access needed to perform function |
| Economy of Mechanism | Keep security simple; complex = more bugs |
| Separation of Privilege | Require multiple conditions/people (dual control) |
| Separation of Duties | No single person controls entire critical process |
| Complete Mediation | Check EVERY access, not just first (no caching authz) |
| Open Design | Security not dependent on secrecy of design (Kerckhoffs') |
| Psychological Acceptability | Security must not make system unusable |
| Fail-Safe Defaults | Default = deny access; explicitly grant |
| Model | Purpose | Key Feature |
|---|---|---|
| Brewer-Nash (Chinese Wall) | Conflict of interest | Access rules change dynamically based on access history |
| Graham-Denning | Object management | 8 basic operations (create/delete subject/object, read/grant/delete/transfer access) |
| HRU | Access control decidability | Safety problem is UNDECIDABLE in general case |
| Take-Grant | Access rights transfer | 4 operations: take, grant, create, remove |
| Lipner | Combined model | Uses BLP + Biba together for both C & I |
| Framework | Focus | Key Feature |
|---|---|---|
| Zachman | Enterprise architecture | 6×6 taxonomy matrix (What/How/Where/Who/When/Why × perspectives) |
| TOGAF | Enterprise architecture | Architecture Development Method (ADM) — iterative cycle |
| SABSA | Security-specific architecture | 6 layers aligned to business risk; security-focused (unlike Zachman/TOGAF) |
| Standard | Origin | Levels | Status |
|---|---|---|---|
| TCSEC (Orange Book) | US DoD | D → C1 → C2 → B1 → B2 → B3 → A1 | Historical / Legacy |
| ITSEC | Europe | E0 → E6 (+ F ratings for functionality) | Historical / Legacy |
| Common Criteria (CC) | International (ISO 15408) | EAL 1–7 | ✅ CURRENT standard |
| EAL | Name | Key Point |
|---|---|---|
| 1 | Functionally Tested | Lowest assurance |
| 2 | Structurally Tested | Basic analysis |
| 3 | Methodically Tested | Engineering discipline |
| 4 | Methodically Designed, Tested, Reviewed | Highest commercially practical |
| 5 | Semi-formally Designed & Tested | Significant expense |
| 6 | Semi-formally Verified | Highly specialised |
| 7 | Formally Verified | Formal proof; highest assurance |
| Ring | Level | What Runs Here |
|---|---|---|
| Ring -1 | Hypervisor | Type 1 hypervisor (VMM) below kernel |
| Ring 0 | Kernel | OS kernel — full hardware access |
| Ring 1–2 | Drivers / Services | Device drivers, OS services |
| Ring 3 | User | Applications — most restricted |
| Control | Purpose |
|---|---|
| ASLR | Randomises memory layout; defeats predictable exploits |
| DEP/NX | Marks memory pages non-executable; prevents code injection from running |
| Stack Canary | Sentinel value detects buffer overflow before return |
| Type | Description | Example |
|---|---|---|
| Type 1 (Bare-Metal) | Runs directly on hardware | VMware ESXi, Hyper-V, Xen |
| Type 2 (Hosted) | Runs on top of host OS | VirtualBox, VMware Workstation |
| Aspect | VM | Container |
|---|---|---|
| Isolation | Full (own OS kernel) | Shared kernel (weaker) |
| Overhead | High (full OS per VM) | Light (shared OS) |
| Boot time | Minutes | Seconds |
| Security | Stronger isolation | Kernel compromise = all containers |
| Model | Customer Controls | Provider Controls |
|---|---|---|
| IaaS | OS, apps, data, middleware, runtime | Hardware, network, virtualisation |
| PaaS | Apps, data | + OS, middleware, runtime |
| SaaS | Data, some config | Everything else |
| Component | Role |
|---|---|
| SCADA | Supervisory control; wide-area monitoring |
| PLC | Programmable Logic Controller; controls physical processes |
| RTU | Remote Terminal Unit; field data collection |
| HMI | Human-Machine Interface; operator dashboard |
| DCS | Distributed Control System; local plant automation |
| Architecture | Security Concern |
|---|---|
| Serverless (FaaS) | No OS to manage; provider controls runtime; risks = function injection, excessive permissions, insecure dependencies, cold start timing attacks |
| Edge Computing | Processing at network edge (near data source); limited physical security; constrained resources for encryption; supply chain risk for edge devices |
| High-Performance Computing (HPC) | Massive parallel processing; risk = shared memory/interconnects; data classification challenges; multi-tenant GPU clusters |
| Microservices / API | Decomposed applications; each service = attack surface; requires API gateway, mutual TLS, and rate limiting between services |
| Strategy | Description | Example |
|---|---|---|
| Natural Surveillance | Design that maximises visibility | Low hedges, open sight lines, windows facing parking |
| Natural Access Control | Guide movement through design | Single entry point, pathways, landscaping barriers |
| Territorial Reinforcement | Mark ownership boundaries | Signage, fences, lighting, maintained landscaping |
| Height | Purpose |
|---|---|
| 3–4 ft (1 m) | Deters casual trespass; defines boundary |
| 6–7 ft (2 m) | Too high to climb easily; deters most intruders |
| 8 ft + barbed/razor wire | Deters determined intruders; critical areas |
| Area | Security Requirements |
|---|---|
| Wiring Closets / IDF | Locked; restricted access; no storage of personal items; environmental monitoring |
| Server Rooms / Data Centres | Multi-factor entry; CCTV; HVAC; fire suppression; visitor logs; raised floors |
| Media Storage Facilities | Fireproof, climate-controlled; access restricted to custodians; inventory tracking |
| Evidence Storage | Tamper-evident; strict chain of custody; limited access; environmental controls |
| Event | Description | Protection |
|---|---|---|
| Blackout | Total power loss | UPS (short-term) + Generator (long-term) |
| Brownout | Prolonged low voltage | UPS with voltage regulation |
| Surge/Spike | Excess voltage (spike = instant, surge = sustained) | Surge protector / UPS |
| Sag | Momentary low voltage | UPS / line conditioner |
| Noise | EMI/RFI interference | Line conditioners, shielded cabling |
| Inrush | Initial surge when power restored | UPS / managed power-on sequence |
| Factor | Ideal Range | Risk |
|---|---|---|
| Temperature | 64–75°F / 18–24°C | Overheating → component failure |
| Humidity | 40–60% RH | Too low → ESD; too high → condensation/corrosion |
| Concept | Definition |
|---|---|
| Confusion | Complex relationship between key → ciphertext (substitution) |
| Diffusion | Spreading plaintext across ciphertext (transposition/permutation) |
| Work Factor | Effort/time to break a cipher (key space = 2^n) |
| Algorithm | Block | Key Size | Rounds | Structure | Status |
|---|---|---|---|---|---|
| DES | 64 | 56 | 16 | Feistel | ❌ Broken |
| 3DES | 64 | 112/168 | 48 | Feistel×3 | ⚠️ Deprecated |
| AES | 128 | 128/192/256 | 10/12/14 | SPN | ✅ Standard |
| Blowfish | 64 | 32-448 | 16 | Feistel | Legacy |
| Twofish | 128 | 128-256 | 16 | Feistel var | Secure (not standardised) |
| Mode | IV? | Secure? | Auth (AEAD)? | Parallelisable? |
|---|---|---|---|---|
| ECB | No | ❌ INSECURE | ❌ | Both |
| CBC | Yes | ✅ | ❌ | Decrypt only |
| CTR | Nonce | ✅ | ❌ | Both (stream-like) |
| GCM | Nonce | ✅ | ✅ | Both |
| Algorithm | Hard Problem | Encrypt | Sign | Key Exch | Min Key |
|---|---|---|---|---|---|
| RSA | Integer factorisation | ✅ | ✅ | ✅ | 2048 |
| DH | Discrete log | ❌ | ❌ | ✅ | 2048 |
| DSA | Discrete log | ❌ | ✅ | ❌ | 2048 |
| ElGamal | Discrete log | ✅ | ✅ | — | 2048 |
| ECC | EC discrete log | ✅ | ✅ | ✅ | 256 |
| Algorithm | Output | Status |
|---|---|---|
| MD5 | 128-bit | ❌ Broken (2004) |
| SHA-1 | 160-bit | ❌ Broken (SHAttered, 2017) |
| SHA-256 | 256-bit | ✅ Standard (Merkle-Damgård) |
| SHA-3 (Keccak) | 224-512 | ✅ Standard (Sponge construction) |
| Mechanism | Non-Repudiation? | Why |
|---|---|---|
| Encryption | ❌ | No proof of origin |
| Hashing | ❌ | No key = no identity |
| HMAC | ❌ | Shared key — both could generate |
| Digital Signature | ✅ | Private key is unique to signer |
| Component | Role |
|---|---|
| CA | Issues & signs certificates |
| RA | Verifies identity (does NOT sign) |
| CRL | Periodic list of revoked cert serial numbers |
| OCSP | Real-time cert status: good/revoked/unknown |
| Feature | CRL | OCSP |
|---|---|---|
| Mechanism | Download list | Real-time query |
| Freshness | Hours/days (stale) | Current |
| Privacy | No concern | Responder sees queries |
| Fix | Delta CRLs | OCSP Stapling |
| Model | Authority | Use Case |
|---|---|---|
| Hierarchical | Root CA → Sub-CAs | TLS/HTTPS, enterprise PKI |
| Web of Trust | Decentralised peer-signed | PGP/GPG email |
| Bridge CA | Neutral connector | Federal PKI |
| Mesh | CAs cross-certify | M&A / partnerships |
| Attack | Attacker Has | Example |
|---|---|---|
| Ciphertext-Only (COA) | Only ciphertext | Frequency analysis |
| Known-Plaintext (KPA) | Some plaintext-ciphertext pairs | Known file headers |
| Chosen-Plaintext (CPA) | Can encrypt arbitrary plaintexts | BEAST attack |
| Chosen-Ciphertext (CCA) | Can decrypt arbitrary ciphertexts | Most powerful |
| Attack | Exploits | Countermeasure |
|---|---|---|
| Timing | Execution time varies | Constant-time operations |
| Power Analysis | Power consumption | Power filtering, HSM |
| EM Analysis | Electromagnetic emissions | Shielding, Faraday cage |
| Fault Injection | Induced errors | Fault detection |
| Attack | Description | Countermeasure |
|---|---|---|
| Pass the Hash | Attacker captures password hash and replays it to authenticate without cracking | Credential Guard, privileged access workstations, Kerberos AES |
| Kerberos Exploitation | Golden Ticket (forged TGT), Silver Ticket (forged service ticket), Kerberoasting (offline cracking) | Protect KRBTGT, use AES, short ticket lifetimes, PAM |
| Frequency Analysis | Analyse ciphertext letter frequencies to break substitution ciphers | Use modern ciphers with diffusion (not simple substitution) |
| Brute Force | Try all possible keys exhaustively | Longer keys, account lockout, rate limiting |
| MITM (Crypto) | Intercept key exchange; present own keys to both parties | Certificate pinning, mutual authentication, PKI |
| Algorithm | Best For |
|---|---|
| PBKDF2 | NIST recommended; CPU-intensive iterations |
| bcrypt | Blowfish-based; configurable cost factor |
| scrypt | CPU + memory intensive; resists GPU/ASIC |
| Argon2 | Current best practice; configurable time/memory/parallelism |
| Phase | Security Activity |
|---|---|
| Stakeholder Needs | Define security requirements alongside business requirements |
| Requirements Analysis | Security classification, threat modelling, compliance requirements |
| Architectural Design | Secure architecture patterns, defence in depth, trust boundaries |
| Development / Implementation | Secure coding, code review, SAST |
| Integration | Interface testing, system integration testing, DAST |
| Verification & Validation | Security testing, certification evaluation, acceptance testing |
| Transition / Deployment | Hardening, configuration baseline, change management |
| Operations & Maintenance | Continuous monitoring, patching, incident response |
| Retirement / Disposal | Data sanitisation (NIST 800-88), media destruction, licence decommission |
| Mode | Clearance Required | Need-to-Know | Access | Description |
|---|---|---|---|---|
| Dedicated | ALL users cleared to HIGHEST level | ALL users have NtK for ALL data | All data | Single-classification processing; everyone cleared for everything |
| System High | ALL users cleared to HIGHEST level | NOT all users have NtK for all data | Based on NtK | All cleared, but access restricted by need-to-know |
| Compartmented | ALL users cleared to HIGHEST level | NtK + formal approval for compartments | Compartment-based | Adds compartment approval beyond clearance + NtK |
| Multilevel | NOT all users cleared to highest | NtK required | Label-based (MAC) | Users at different clearance levels; BLP/Biba enforced by system; MOST complex |
| Type | Mechanism | Example | Detection |
|---|---|---|---|
| Covert Storage Channel | One process writes, another reads shared storage | Modifying file attributes, disk space, shared memory flags | Audit logs, resource monitoring |
| Covert Timing Channel | Signal via timing of system operations | CPU utilisation patterns, packet timing, lock contention | Harder to detect; noise injection, traffic normalisation |
| Mechanism | Description |
|---|---|
| Process Isolation | OS prevents one process from accessing another's memory space; fundamental to multi-user security |
| Hardware Segmentation | Memory segments enforced by MMU; stronger than software isolation alone |
| Virtual Address Space | Each process sees its own virtual memory; OS maps to physical addresses; prevents cross-process access |
| Sandboxing | Restricts process to limited resource set; used for untrusted code (browser JS, mobile apps) |
| TEE (Trusted Execution Environment) | Hardware-isolated enclave for sensitive operations (Intel SGX, ARM TrustZone); code + data protected even from OS |
| Type | Category | Volatile? | Key Characteristic |
|---|---|---|---|
| SRAM | RAM | Yes | Fast (L1/L2 cache); expensive; no refresh needed |
| DRAM | RAM | Yes | Main memory; cheaper; needs constant refresh |
| ROM | Firmware | No | Read-Only; burned at factory; cannot be changed |
| PROM | Firmware | No | Programmable ROM; write-once (fuse-based) |
| EPROM | Firmware | No | Erasable PROM; UV light erases; rewritable |
| EEPROM | Firmware | No | Electrically erasable; byte-level rewrite; slower |
| Flash | Firmware/Storage | No | Type of EEPROM; block-level erase; SSDs, USB drives, firmware |
| Model | Operated By | For Whom | Key Concern |
|---|---|---|---|
| Public | Cloud provider | General public / any tenant | Multi-tenancy; shared infrastructure; data residency |
| Private | Organisation or third party | Single organisation only | Higher control; higher cost; still need security config |
| Hybrid | Mix of public + private | Organisation | Data classification drives placement; policy consistency across environments |
| Community | Shared by orgs with common interests | Members of community (govt, healthcare) | Shared compliance requirements; FedRAMP community cloud |
| Multi-Cloud | Multiple public providers | Organisation | Avoid vendor lock-in; complexity of managing security across providers |
| # | Mnemonic | Helps Remember |
|---|---|---|
| 1 | "LESS COPS" | Saltzer & Schroeder 8 principles |
| 2 | "WURD" (Write Up Read Down) | What BLP allows (opposite = what it blocks) |
| 3 | "PP = People Profile; ST = Seller Target; TOE = Thing Evaluated" | Common Criteria components |
| 4 | "GCM = Gets Confidentiality & Message auth" | Only AEAD mode on the exam |
| 5 | "DES = 56-64-16" | DES key-block-rounds |
| 6 | "AES block = 128 ALWAYS" | Key varies (128/192/256) but block never changes |
| 7 | "RSA Does It All (E/D/K)" | Encrypt, Digital sign, Key exchange |
| 8 | "ECC Punches Above Its Weight" | ECC-256 ≈ RSA-3072 |
| 9 | "Sym = n(n−1)/2; Asym = 2n" | Key count formulas |
| 10 | "MD5 & SHA-1 are DEAD; SHA-2 = standard; SHA-3 = spare" | Hash algorithm status |
| 11 | "Salt Pepper Stretch" | Password hashing best practices |
| 12 | "Never escrow signatures" | Key escrow rule |
| 13 | "CPTED = See Naturally" | Natural Surveillance, Natural Access, Territorial Reinforcement |
| 14 | "Blackout = Both (UPS + Gen)" | Total loss needs short-term + long-term power |
| 15 | "Does She Cook Meals?" | Security modes: Dedicated → System High → Compartmented → Multilevel |
| 16 | "Storage = Stuff; Timing = Tempo" | Covert channel types |
| 17 | "ROM → PROM → EPROM → EEPROM → Flash" | Memory permanence evolution (fixed → reprogrammable) |
| # | Trap |
|---|---|
| 1 | BLP = confidentiality (no read up/write down); Biba = integrity (no read down/write up) — OPPOSITES |
| 2 | Clark-Wilson enforces well-formed transactions via TPs on CDIs (commercial integrity) |
| 3 | Brewer-Nash = dynamic rules based on access HISTORY (not static) |
| 4 | SABSA = security framework; Zachman/TOGAF = enterprise architecture (not security-specific) |
| 5 | EAL 4 = highest practically achievable; EAL 7 = formal verification (extremely rare) |
| 6 | Reference Monitor = concept; Security Kernel = implementation |
| 7 | VM Escape is the most critical virtualisation attack |
| 8 | SCADA priority = Safety first, NOT confidentiality (SAIC not CIA) |
| 9 | AES block size ALWAYS 128 bits — key size varies |
| 10 | ECB mode INSECURE — patterns leak in ciphertext |
| 11 | DH = key exchange ONLY; DSA = signatures ONLY; RSA = everything |
| 12 | HMAC cannot provide non-repudiation (shared secret key) |
| 13 | Digital signatures = only way to get non-repudiation |
| 14 | Birthday attack = 2^(n/2); 128-bit hash gives only 64-bit collision resistance |
| 15 | RA verifies identity but does NOT sign certificates |
| 16 | Root CA must be OFFLINE (air-gapped) |
| 17 | NEVER escrow signing keys (destroys non-repudiation) |
| 18 | Side-channel attacks exploit implementation, NOT algorithm math |
| 19 | TLS 1.3 mandates PFS (only DHE/ECDHE allowed) |
| 20 | Container isolation WEAKER than VM (shared kernel) |
| 21 | Dedicated mode = simplest; Multilevel = most complex (different clearances coexist; needs MAC) |
| 22 | Covert timing channels are HARDER to detect than storage channels |
| 23 | Cold boot attack extracts keys from RAM shortly after power-off (freeze chips) |
| 24 | Private cloud ≠ on-premises; private cloud can be hosted off-site (key = exclusive use) |
| 25 | TCSEC B2 requires covert storage channel ANALYSIS; B3 adds covert timing channel analysis & MITIGATION |
| 26 | Security depends on keeping algorithm secret (instead of key secrecy) |
| 27 | Quantum computing breaks ALL encryption equally |
| 28 | One-time pad is always unbreakable in practice |
| 29 | Zero-knowledge proofs require revealing the secret |
| 30 | Stream ciphers and block ciphers are interchangeable |
| 31 | Confusion and diffusion are the same thing |
| OSI # | Layer | TCP/IP | Protocols / Devices | PDU |
|---|---|---|---|---|
| 7 | Application | Application | HTTP, HTTPS, FTP, SMTP, DNS, SNMP, LDAP | Data |
| 6 | Presentation | SSL/TLS encryption, JPEG, MPEG, ASCII, compression | Data | |
| 5 | Session | RPC, NetBIOS, PPTP, SIP, NFS | Data | |
| 4 | Transport | Transport | TCP (reliable), UDP (fast), TLS | Segment |
| 3 | Network | Internet | IP, ICMP, IPSec, routers, L3 switches | Packet |
| 2 | Data Link | Network Access | Ethernet, ARP, switches, bridges, MAC addresses | Frame |
| 1 | Physical | Cables, hubs, repeaters, connectors, electrical signals | Bits |
| Protocol | Description | Security Concern |
|---|---|---|
| VoIP (Voice over IP) | Voice traffic over data networks | Eavesdropping (SRTP for encryption), vishing, toll fraud, QoS dependency |
| iSCSI | SCSI storage commands over TCP/IP | Storage traffic on shared network; requires CHAP auth + IPSec or VLAN isolation |
| FCoE (Fibre Channel over Ethernet) | Storage + network on same fabric | Shared infrastructure risk; requires dedicated VLANs |
| InfiniBand | High-speed interconnect (HPC, data centres) | Low-latency but limited built-in security; physical access control critical |
| Compute Express Link (CXL) | High-speed CPU-to-device interconnect (memory, accelerators) | Emerging; shared memory pools between hosts; data leakage between tenants; isolation enforcement critical |
| Metric | Definition |
|---|---|
| Bandwidth | Maximum data transfer rate (capacity of the link) |
| Latency | Time for packet to travel source → destination |
| Jitter | Variation in latency (critical for VoIP/video) |
| Throughput | Actual data successfully transferred per unit time |
| SNR (Signal-to-Noise) | Signal strength vs interference; higher = cleaner signal |
| Concept | Description | Security Note |
|---|---|---|
| Data Plane | Forwards actual user traffic (packets/frames) | Where DDoS and MitM occur |
| Control Plane | Makes routing/switching decisions (routing tables, ARP) | Target of BGP hijacking, ARP poisoning; SDN centralises this |
| Management Plane | Configures & monitors devices (SSH, SNMP, APIs) | Most sensitive — out-of-band management preferred; restrict to jump server; MFA required |
| Cut-Through Switching | Forwards frame after reading destination MAC (low latency) | No error checking — corrupted/malicious frames pass through |
| Store-and-Forward | Receives entire frame, checks CRC, then forwards | Higher latency but catches errors; preferred for security |
| Media | Type | Security Characteristic |
|---|---|---|
| UTP/STP | Copper | UTP susceptible to EMI/eavesdropping; STP = shielded |
| Coaxial | Copper | More resistant to EMI than UTP; legacy |
| Fibre Optic | Light | Immune to EMI; extremely difficult to tap; preferred for secure links |
| Device | Layer | Function |
|---|---|---|
| Hub | L1 | Broadcasts all traffic to all ports (INSECURE) |
| Switch | L2 | Forwards by MAC address; creates collision domains |
| Router | L3 | Routes by IP; creates broadcast domains; ACLs |
| Firewall | L3-L7 | Filters traffic by rules (stateless/stateful/application) |
| WAF | L7 | Web Application Firewall; protects against XSS, SQLi, OWASP Top 10 |
| IDS/IPS | L3-L7 | Detect (IDS) / Prevent (IPS) intrusions |
| Proxy | L7 | Forward proxy (client), Reverse proxy (server) |
| Type | Layer | How It Works |
|---|---|---|
| Packet Filter (Stateless) | L3 | Examines IP/port per packet; no connection tracking |
| Stateful Inspection | L3-L4 | Tracks connection state (SYN/ACK); allows return traffic |
| Application Proxy | L7 | Terminates & rebuilds connections; deep inspection |
| NGFW (Next-Gen) | L3-L7 | Stateful + DPI + application awareness + IPS + threat intel |
| Concept | Purpose |
|---|---|
| VLAN | Logical L2 segmentation; isolates broadcast domains |
| DMZ | Buffer zone between internet & internal network; hosts public-facing servers |
| Air Gap | Physical isolation; no network connection (highest security) |
| Microsegmentation | Fine-grained, workload-level segmentation (SDN/Zero Trust) |
| Jump Server / Bastion Host | Hardened access point for admin; single entry to secure zone |
| Feature | IPv4 | IPv6 |
|---|---|---|
| Address Size | 32-bit (4.3B addresses) | 128-bit (3.4×10³⁸ addresses) |
| Format | Dotted decimal (192.168.1.1) | Hex colon (2001:db8::1) |
| IPSec | Optional | Built-in (mandatory support) |
| NAT | Required (address scarcity) | Not needed |
| Broadcast | Yes | No (uses multicast/anycast) |
| Protocol | Type | Algorithm | Scope |
|---|---|---|---|
| RIP | Distance vector | Hop count (max 15) | Small networks |
| OSPF | Link state | Dijkstra (cost) | Enterprise (IGP) |
| BGP | Path vector | Policy-based | Internet backbone (EGP) |
| Insecure | Secure Replacement | What Changed |
|---|---|---|
| HTTP (80) | HTTPS (443) | TLS encryption |
| Telnet (23) | SSH (22) | Encrypted remote shell |
| FTP (21) | SFTP (22) / FTPS (990) | SSH tunnel / TLS |
| SNMP v1/v2 (161) | SNMPv3 | Authentication + encryption |
| DNS (53) | DNSSEC | Digital signatures on DNS records (integrity, NOT confidentiality) |
| LDAP (389) | LDAPS (636) | TLS encryption |
| POP3 (110) / IMAP (143) | POP3S/IMAPS (995/993) | TLS encryption |
| Component | Function |
|---|---|
| AH (Auth Header) | Integrity + Authentication (NO encryption) |
| ESP (Encapsulating Security Payload) | Confidentiality + Integrity + Authentication |
| IKE | Key exchange & SA negotiation (UDP 500) |
| Mode | Protects | Use Case |
|---|---|---|
| Transport | Payload only (original IP header visible) | Host-to-host |
| Tunnel | Entire packet (new IP header added) | Gateway-to-gateway (site VPN) |
| Protocol | Layer | Key Feature |
|---|---|---|
| SSL/TLS VPN | L4-L7 | Browser-based; no client needed; HTTPS (443) |
| L2TP | L2 | No native encryption; pair with IPSec |
| WireGuard | L3 | Modern, fast, minimal codebase |
| Standard | Encryption | Auth | Status |
|---|---|---|---|
| WEP | RC4 (24-bit IV) | Open / Shared Key | ❌ Broken (cracked in seconds) |
| WPA | TKIP (RC4 wrapper) | PSK / 802.1X | ⚠️ Deprecated |
| WPA2 | AES-CCMP | PSK / 802.1X (EAP) | ✅ Standard |
| WPA3 | AES-GCMP / SAE | SAE (Dragonfly) / 802.1X | ✅ Current best |
| Attack | Description |
|---|---|
| Evil Twin | Rogue AP mimics legitimate SSID; MitM |
| Deauthentication | Forces clients off network; capture WPA handshake |
| War Driving | Scanning for open/weak wireless networks |
| Bluejacking/Bluesnarfing | Bluetooth: unsolicited messages / data theft |
| KRACK | Key Reinstallation Attack on WPA2 (patched) |
| Attack | Layer | Description | Mitigation |
|---|---|---|---|
| ARP Poisoning | L2 | Fake ARP replies → MitM | DAI, static ARP |
| MAC Flooding | L2 | Overflow switch CAM table → hub mode | Port security |
| VLAN Hopping | L2 | Double tagging / switch spoofing | Disable DTP, prune unused VLANs |
| DNS Poisoning | L7 | False DNS records in cache | DNSSEC |
| BGP Hijacking | L3 | Announce false routes | RPKI, route filtering |
| SYN Flood | L4 | Exhaust connection table (half-open) | SYN cookies, rate limiting |
| Smurf Attack | L3 | ICMP echo to broadcast with spoofed source | Disable directed broadcast |
| MitM/MitB | Various | Intercept/alter communications | Mutual TLS, certificate pinning |
| Protocol | Purpose |
|---|---|
| SPF | DNS record listing authorised mail servers for domain (IP-based) |
| DKIM | Cryptographic signature on email headers/body (integrity + authenticity) |
| DMARC | Policy layer atop SPF + DKIM; tells receivers what to do on failure (none/quarantine/reject) |
| S/MIME | PKI-based email encryption + signing (requires certificates) |
| PGP/GPG | Web-of-trust email encryption (no PKI hierarchy needed) |
| Concept | Description |
|---|---|
| SDN | Software-Defined Networking: separates control plane from data plane; centralised management |
| SD-WAN | Software-Defined WAN; optimises WAN connections; centralised policy |
| SASE | Secure Access Service Edge: SD-WAN + security (CASB, FWaaS, ZTNA, SWG) as cloud service |
| Zero Trust | "Never trust, always verify." No implicit trust based on network location. Microsegmentation + continuous auth. |
| CDN | Content Delivery Network: distributes content geographically; DDoS mitigation |
| VPC (Virtual Private Cloud) | Logically isolated network within public cloud; own subnets, route tables, ACLs; equivalent of a private data centre in the cloud |
| Generation | Security Note |
|---|---|
| 4G/LTE | IPSec between towers; mutual auth; but IMSI catchers (Stingray) can intercept |
| 5G | Enhanced encryption (256-bit), SUPI/SUCI privacy, network slicing (isolates virtual networks); expanded IoT attack surface |
| Channel | Security Requirement |
|---|---|
| Voice / Video / Collaboration | End-to-end encryption (SRTP for voice, TLS for signalling); meeting access controls; recording consent; screen-share DLP |
| Remote Access | VPN or ZTNA; MFA required; session timeout; administrative access via jump server/bastion host |
| Backhaul / Satellite | High latency; encryption mandatory (vulnerable to interception); consider link encryption for classified data |
| Third-Party Connectivity | Dedicated links or VPN; SLA with security terms; monitoring of partner traffic; NAC enforcement |
| # | Mnemonic | Helps Remember |
|---|---|---|
| 1 | "Please Do Not Throw Sausage Pizza Away" | OSI layers L1→L7 |
| 2 | "Tunnel Buries the Body" | IPSec Tunnel = entire packet; Transport = payload |
| 3 | "AH = no confidentiality; ESP = everything" | IPSec protocols |
| 4 | "WEP = Wrecked Encryption Protocol" | WEP is broken |
| 5 | "SYN cookies solve SYN floods" | DoS mitigation |
| 6 | "SPF = who can Send, DKIM = Digital Key, DMARC = Decision Maker" | Email security stack |
| # | Trap |
|---|---|
| 1 | IPv6 has mandatory IPSec SUPPORT, not mandatory USE |
| 2 | DNSSEC = integrity/authentication only, NOT confidentiality (use DoH/DoT for that) |
| 3 | AH provides NO encryption; broken by NAT (NAT modifies IP header, invalidating AH integrity check) |
| 4 | TLS 1.3 = 1-RTT, mandates PFS, removed RSA key exchange |
| 5 | WEP IV is only 24 bits → exhausted quickly → trivially cracked |
| 6 | WPA3-SAE resists offline dictionary attacks (unlike WPA2-PSK) |
| 7 | 802.1X uses RADIUS (not TACACS+) for wireless enterprise auth |
| 8 | Switches can still be compromised (MAC flooding, VLAN hopping) |
| 9 | SSL VPN works through firewalls (port 443) — advantage over IPSec |
| 10 | SDN separates control plane from data plane (centralised management) |
| 11 | Zero Trust = "never trust, always verify" not "block everything" |
| 12 | Smurf attack uses ICMP + broadcast + spoofed source (amplification) |
| 13 | Management plane = most sensitive; must isolate via out-of-band management (separate VLAN/console) |
| 14 | Cut-through switching is faster but passes corrupted frames; store-and-forward checks CRC (more secure) |
| 15 | Data sovereignty = governed by country where data is STORED, not where company is headquartered |
| 16 | Bluetooth attacks are all the same |
| 17 | FTPS and SFTP are the same protocol |
| 18 | L2TP provides encryption on its own |
| 19 | SYN flood is hard to mitigate |
| 20 | S/MIME and PGP use the same trust model |
| 21 | Fraggle and Smurf are identical attacks |
| 22 | DNS poisoning only impacts one target machine |
| Concept | Definition |
|---|---|
| Subject | Active entity requesting access (user, process, device) |
| Object | Passive entity being accessed (file, database, service) |
| Principal | Subject after successful authentication |
| Factor | Type | Examples |
|---|---|---|
| Type 1: Something You Know | Knowledge | Password, PIN, passphrase, security question |
| Type 2: Something You Have | Possession | Smart card, token (TOTP/HOTP), phone, key fob |
| Type 3: Something You Are | Biometric | Fingerprint, iris, retina, voice, face |
| Type 4: Somewhere You Are | Location | GPS, IP geolocation, building access |
| Type 5: Something You Do | Behavioral | Keystroke dynamics, gait, signature |
| Control | Purpose | Key Point |
|---|---|---|
| Session Timeout (Idle) | Expire session after inactivity period | Prevents abandoned session hijacking; varies by sensitivity (15 min high-sec, 30 min normal) |
| Absolute Timeout | Expire session after max duration regardless of activity | Forces re-authentication; limits token validity window |
| Session ID Management | Unique, random, unpredictable session tokens | Never in URL (bookmarkable/logged); use secure cookies with HttpOnly + Secure + SameSite flags |
| Session Fixation Prevention | Generate NEW session ID after authentication | Attacker can’t pre-set a session ID and wait for victim to authenticate with it |
| Concurrent Session Control | Limit number of simultaneous sessions per user | Detects credential sharing / compromise |
| Biometric | Scans | Key Fact |
|---|---|---|
| Retina | Blood vessel pattern (back of eye) | Most accurate; most invasive; reveals health conditions |
| Iris | Coloured ring pattern | Very accurate; less invasive; can use photo from distance |
| Technology | Protocol | Key Feature |
|---|---|---|
| Kerberos | Ticket-based | KDC (AS + TGS); uses symmetric crypto (PKINIT extension adds PKI for smart card/PIV authentication); TGT lasts ~10h; time-sensitive (5-min clock skew) |
| SAML | XML assertions | Web SSO; IdP + SP; browser redirects; enterprise SSO |
| OAuth 2.0 | Authorisation | Delegated authorisation (NOT authentication); access tokens; "Login with Google" |
| OpenID Connect (OIDC) | Authentication | Identity layer ON TOP of OAuth 2.0; ID tokens (JWT) |
| RADIUS | AAA | Encrypts password only; UDP 1812/1813; wireless, VPN, dial-up |
| TACACS+ | AAA | Encrypts entire payload; TCP 49; granular command-level authz; Cisco |
| Feature | RADIUS | TACACS+ |
|---|---|---|
| Transport | UDP | TCP |
| Encryption | Password only | Entire payload |
| AAA | Combined A&A | Separate A/A/A |
| Best For | Network access (wireless, VPN) | Device admin (routers, switches) |
| Model | Decision By | Description |
|---|---|---|
| DAC | Data OWNER | Owner sets permissions (ACLs); flexible; most common in desktops; risk = too permissive |
| MAC | SYSTEM / labels | System enforces based on classification labels; rigid; military/government; BLP/Biba models |
| RBAC | ROLE | Access based on job role; groups/roles; enterprise standard; eases admin |
| ABAC | ATTRIBUTES | Policies evaluate subject + object + environment attributes; most flexible; XACML |
| Risk-Based | RISK SCORE | Dynamic; adjusts access based on real-time risk assessment (user behaviour, location, device, threat intel); used in adaptive/step-up authentication |
| Rule-Based | RULES | IF-THEN rules (firewalls, router ACLs); not same as RBAC |
| Control | Purpose |
|---|---|
| Just-In-Time (JIT) | Elevated privileges granted only when needed, automatically revoked |
| Password Vaulting | Privileged passwords checked out, auto-rotated, audited |
| Session Recording | Record all admin sessions for audit & forensics |
| Least Privilege | Minimum access for job function; no standing admin rights |
| Service Accounts | Non-interactive; use managed identities; no interactive login |
| Best Practice | Rationale |
|---|---|
| No interactive login | Service accounts should NEVER be used by humans to log in |
| Managed identities | Cloud-native identity (Azure MI, AWS IAM Roles) — no stored credentials to steal |
| Automated password rotation | Rotate credentials frequently via PAM vault; avoid hardcoded passwords |
| Least privilege scoping | Grant only specific API permissions needed; never domain admin |
| Inventory & ownership | Every service account must have a documented human owner; orphan service accounts = major risk |
| Monitoring & alerting | Alert on interactive login attempts, unusual hours, privilege escalation from service accounts |
| Type | Description | Example |
|---|---|---|
| Vertical | Lower-privilege user gains higher-privilege access (user → admin) | Kernel exploit, sudo bypass |
| Horizontal | Same-level user accesses another user's resources | IDOR — accessing another user's account data via URL manipulation |
Adaptive authentication dynamically adjusts authentication requirements based on risk score. Factors include: user location, device, time, behaviour pattern, network. Higher risk → stronger authentication (step-up MFA).
| Concept | Definition |
|---|---|
| Privilege Creep | Accumulation of unnecessary access over time (role changes without revocation) |
| Need-to-Know | Even with clearance, access only if job-function requires it |
| Separation of Duties | No single person controls entire critical process; prevents fraud |
| Dual Control | Two+ people must act together (nuclear launch = two keys) |
| # | Mnemonic | Helps Remember |
|---|---|---|
| 1 | "I Am, I Prove, I Can" | Identification → Authentication → Authorisation |
| 2 | "Know Have Are" | Authentication factor types 1-2-3 |
| 3 | "FAR is worse than FRR" (letting intruder IN) | False Acceptance more dangerous |
| 4 | "CER = sweet spot" | Where FRR=FAR; lower CER = better biometric |
| 5 | "Kerberos needs a clock" | 5-min clock skew tolerance |
| 6 | "OAuth = Authorisation; OIDC = Authentication" | OAuth alone is NOT authentication |
| 7 | "RADIUS = Remote; TACACS+ = Terminal" | RADIUS for network access; TACACS+ for device admin |
| 8 | "DAC = Owner; MAC = System; RBAC = Role; ABAC = Attribute" | Access control models |
| # | Trap |
|---|---|
| 1 | Two passwords = NOT MFA (same factor type); must be DIFFERENT factor types |
| 2 | Type 1 error = False Rejection (FRR); Type 2 error = False Acceptance (FAR) — don't confuse with auth factor types |
| 3 | OAuth 2.0 is AUTHORISATION only — use OIDC for authentication |
| 4 | SAML uses XML; OIDC uses JWT tokens (modern, mobile-friendly) |
| 5 | Kerberos = symmetric crypto + time-dependent; Golden Ticket = compromised KRBTGT |
| 6 | RADIUS encrypts password only; TACACS+ encrypts entire payload |
| 7 | RBAC ≠ Rule-Based Access Control (common confusion) |
| 8 | Retina scan = most accurate BUT most invasive; can reveal health info |
| 9 | Privilege creep = accumulation without revocation (fix with periodic UARs) |
| 10 | DAC is most permissive (owner decides); MAC is most restrictive (system decides) |
| 11 | Federation = cross-org trust; SSO = same organisation, multiple apps |
| 12 | Smart card = possession (Type 2) + PIN = knowledge (Type 1) = MFA |
| 13 | Risk-based access control is DYNAMIC (changes per session); RBAC is STATIC (changes per role assignment) |
| 14 | Session tokens must be regenerated after login (prevent fixation); never in URLs (bookmarks/logs leak them) |
| 15 | Service accounts = top attack vector; hardcoded creds in scripts, orphan accounts, no rotation = audit failures |
| 16 | Managed identities (cloud-native) eliminate stored credentials entirely — preferred over service account passwords |
| 17 | Identity proofing = authentication |
| 18 | RBAC is the most granular access model |
| 19 | Privileged accounts need standing access |
| 20 | PAM and IAM are the same thing |
| 21 | Password spraying = brute force |
| 22 | Authentication only happens at login |
| Type | Description | Scope |
|---|---|---|
| Vulnerability Assessment | Identifies known weaknesses (scanning tools) | Breadth — "What's exposed?" |
| Penetration Test | Actively exploits vulnerabilities | Depth — "Can we get in?" |
| Security Audit | Formal evaluation against standard/policy | Compliance — "Are rules followed?" |
| Red Team | Adversary simulation (stealth, multi-vector) | Realistic attack — "How would APT do it?" |
| Blue Team | Defensive operations; detection & response | Defence — "Can we detect it?" |
| Purple Team | Red + Blue collaborate openly | Improvement — "Learn together" |
| Type | Prior Knowledge | Simulates |
|---|---|---|
| Black Box (External) | Zero knowledge | Outside attacker |
| White Box (Internal) | Full knowledge (source, diagrams) | Insider threat / thorough audit |
| Grey Box | Partial knowledge | Compromised user / partner |
| Score | Severity |
|---|---|
| 0.0 | None |
| 0.1–3.9 | Low |
| 4.0–6.9 | Medium |
| 7.0–8.9 | High |
| 9.0–10.0 | Critical |
| Scanner Type | What It Finds |
|---|---|
| Network Scanner | Open ports, services, OS fingerprinting |
| Vulnerability Scanner | Known CVEs, misconfigurations, missing patches |
| DAST | Dynamic Application Security Testing — tests running app (black-box) |
| SAST | Static Application Security Testing — analyses source code (white-box) |
| IAST | Interactive — combines SAST + DAST; agent inside running app |
| SCA | Software Composition Analysis — finds vulnerable libraries/dependencies |
| Technique | Description |
|---|---|
| Breach Attack Simulation (BAS) | Automated, continuous simulation of real attack paths across kill chain; validates control effectiveness without manual red team |
| Compliance Checks | Automated verification of systems against baseline standards (CIS, DISA STIG, PCI); often integrated into SIEM/config management |
| Activity | Description |
|---|---|
| Remediation | Fix identified vulnerabilities by priority (CVSS + business context); track to closure |
| Exception Handling | Document accepted risks where remediation is not feasible; formal exception with compensating controls, expiry date, and management sign-off |
| Ethical Disclosure | If testing reveals vulnerabilities in third-party products: responsible disclosure to vendor → allow time to patch → coordinate public disclosure |
| Type | Performed By | Purpose |
|---|---|---|
| Internal Audit | Internal team (reports to board/audit committee) | Self-assessment; identify issues early |
| External Audit | Independent third party | Regulatory compliance; SOC reports |
| Third-Party Audit | Customer/partner auditors | Supply chain assurance |
| Report | Scope | Audience |
|---|---|---|
| SOC 1 | Financial reporting controls (ICFR) | Financial auditors |
| SOC 2 | Trust Services Criteria (Security, Availability, PI, Confidentiality, Privacy) | Management, regulators, customers |
| SOC 3 | Same as SOC 2 but general-use (summary) | Public/marketing |
| Type | Period | Description |
|---|---|---|
| Type I | Point-in-time | Controls designed & implemented at a specific date |
| Type II | Over a period (6-12 months) | Controls operating effectively over time (MORE VALUABLE) |
| Concept | Definition |
|---|---|
| Log Integrity | Write-once storage, hash chains, centralised logging (prevents tampering) |
| NTP | Time synchronisation critical for log correlation (all systems same clock) |
| Retention | Logs retained per policy/regulation; balance storage vs compliance |
| Level | Scope | Who |
|---|---|---|
| Unit Testing | Individual functions/methods | Developers |
| Integration Testing | Combined modules; data flows between components | Developers / QA |
| System Testing | Complete system end-to-end | QA team |
| User Acceptance Testing (UAT) | Business requirements met; real-world scenarios | End users / business |
| Regression Testing | Verify changes didn't break existing functionality | QA (after every change) |
| Method | Description |
|---|---|
| Code Review | Manual inspection of source code (most effective for logic flaws) |
| Fagan Inspection | Formal 6-step code review: Planning → Overview → Preparation → Inspection → Rework → Follow-up (most rigorous) |
| Fuzz Testing | Random/malformed input to find crashes, buffer overflows, exceptions |
| Interface Testing | Test APIs, UIs, data flows between components |
| Misuse/Abuse Case Testing | Test from attacker's perspective; negative testing |
| Test Coverage Analysis | Measure % of code exercised by tests (branch, statement, path, condition, loop) |
| Type | How | When |
|---|---|---|
| Synthetic Monitoring | Scripted transactions simulate user actions proactively | Pre-production; 24/7 baseline |
| Real User Monitoring (RUM) | Captures actual user interactions passively | Production; real-world performance |
| Metric Type | Full Name | Purpose | Example |
|---|---|---|---|
| KPI | Key Performance Indicator | Measures how WELL security controls and processes are performing | % patches applied within SLA, mean time to detect, phishing click rate |
| KRI | Key Risk Indicator | Provides EARLY WARNING of increasing risk exposure | # unpatched critical CVEs, employee turnover in security team, % systems out of compliance |
| Data Area | What to Collect |
|---|---|
| Account Management | Orphan accounts, privilege creep, access review completion rate |
| Management Review | Security steering committee minutes, risk register updates, policy approval records |
| Backup Verification | Backup success/failure logs, restore test results (test restores regularly!), RPO verification |
| Training & Awareness | Completion rates, phishing simulation results, security champion participation |
| DR/BC | DRP test results, RTO/RPO achievement, plan update records |
| Metric | Measures |
|---|---|
| MTTD | Mean Time To Detect — how long before threat is discovered |
| MTTR | Mean Time To Respond/Remediate — how long to fix |
| MTTF | Mean Time To Failure — avg time until first failure (non-repairable) |
| MTBF | Mean Time Between Failures — avg time between failures (repairable) |
| Patch Latency | Time from patch release to deployment |
| Vulnerability Density | Vulnerabilities per 1000 lines of code |
| # | Mnemonic | Helps Remember |
|---|---|---|
| 1 | "VA = breadth; Pentest = depth" | Vulnerability assessment vs penetration test |
| 2 | "Black = blind; White = wide open; Grey = glimpse" | Pentest knowledge levels |
| 3 | "SOC 1 = $; SOC 2 = Security; SOC 3 = Summary" | SOC report types |
| 4 | "Type I = snapshot; Type II = movie" | Point-in-time vs over time |
| 5 | "DAST = Dynamic = running app; SAST = Static = source code" | App testing types |
| # | Trap |
|---|---|
| 1 | Vulnerability scan ≠ penetration test (scan identifies; pentest exploits) |
| 2 | Written authorisation REQUIRED before any pentest (no verbal OK) |
| 3 | SOC 2 Type II > Type I for ongoing assurance |
| 4 | Fuzz testing finds bugs code review misses (crashes, memory corruption) |
| 5 | MTBF includes repair time; MTTF = until first failure (no repair assumed) |
| 6 | Log integrity requires centralised logging + tamper protection + NTP |
| 7 | Red team = stealth adversary sim; Purple team = collaborative improvement |
| 8 | SCA finds vulnerable open-source libraries (not your code, their bugs) |
| 9 | KPI = performance (backward-looking); KRI = risk warning (forward-looking) — don't confuse them |
| 10 | Backup verification = actually TEST restores regularly, not just check backup logs succeeded |
| 11 | SOC 1 = SOC 2 = SOC 3 |
| 12 | 100% code coverage = no bugs |
| 13 | Patches don't need regression testing |
| 14 | False positives are worse than false negatives |
| 15 | Testing only covers what SHOULD work (not abuse cases) |
| Phase | Key Actions |
|---|---|
| Preparation | IR plan, team (CSIRT), tools, training, communication plan, legal counsel |
| Detection & Analysis | Monitoring (SIEM), IoC identification, triage, severity classification |
| Containment | Short-term (isolate host) → Long-term (patch, rebuild) → Evidence preservation |
| Eradication | Remove malware, close vulnerabilities, reset credentials |
| Recovery | Restore systems, verify functionality, enhanced monitoring |
| Lessons Learned | Post-mortem within 1-2 weeks; update IR plan; root cause analysis |
| Element | Detail |
|---|---|
| Notification Roster | Call tree / cascade: who calls whom, in what order; include alternates for each role |
| Stakeholder Communication | Executives, employees, customers, partners, regulators — each needs tailored messaging |
| Communication Methods | Primary + backup channels (if email is down, use SMS/mass notification system/satellite phone) |
| Spokesperson | Designated media contact; ONLY authorised person speaks to press (usually PR/legal, NOT IT) |
| Regulatory Notifications | Mandatory breach reporting (GDPR 72h, HIPAA 60d); regulator-specific requirements |
| Status Updates | Regular cadence during DR activation; include recovery progress vs RTO targets |
| All-Clear Declaration | Formal notification that operations have been restored and are verified; authorised by management |
| Concept | Definition |
|---|---|
| Chain of Custody | Documented history of evidence: who handled, when, what was done. UNBROKEN chain or evidence is inadmissible. |
| Forensic Image | Bit-for-bit exact copy of original media (dd, FTK Imager). Hash before & after to prove integrity. |
| Write Blocker | Hardware/software preventing writes to evidence drive during imaging |
| Legal Hold | Preserve all potentially relevant evidence; overrides retention policies |
| Type | Description | Strength |
|---|---|---|
| Real/Physical | Tangible objects (hard drive, printed document) | Strongest |
| Documentary | Written records (contracts, logs) | Strong (if authenticated) |
| Testimonial | Witness statements (expert/fact) | Moderate |
| Demonstrative | Charts, models, re-enactments | Supporting |
| Hearsay | Second-hand statements | Generally inadmissible |
| Challenge | Description |
|---|---|
| Jurisdictional Issues | Data may span multiple countries; which laws apply? Provider’s HQ, data location, or victim’s? |
| Multi-Tenancy | Shared infrastructure makes isolating evidence difficult; provider must cooperate |
| Volatile Evidence | VMs/containers can be destroyed instantly; auto-scaling removes instances; snapshots essential |
| Limited Access | Customer may not have access to hypervisor, network logs, or physical media — depends on service model (IaaS > PaaS > SaaS access) |
| Chain of Custody | Provider must assist with forensic imaging; contractual agreements for forensic support needed BEFORE incident |
| Log Availability | Cloud logs may have limited retention; must configure extended retention and centralised export proactively |
| Category | Indicators |
|---|---|
| Behavioural | Working unusual hours, excessive access requests, bypassing controls, hostility toward employer, financial stress |
| Technical | Bulk data downloads, USB use, accessing files outside scope, email to personal accounts, VPN at unusual times |
| Policy Violations | Disabling security tools, sharing credentials, ignoring classification labels |
| Site | Equipment | Data | Recovery Time | Cost |
|---|---|---|---|---|
| Hot Site | ✅ Active | ✅ Real-time/near | Minutes–hours | $$$$ |
| Warm Site | ✅ Partial | ⚠️ Needs restore | Hours–days | $$$ |
| Cold Site | ❌ Empty | ❌ From backup | Days–weeks | $ |
| Cloud/DRaaS | ✅ On-demand | ✅ Replicated | Minutes | Variable |
| Mobile Site | ✅ Portable | ⚠️ | Hours | $$ |
| Reciprocal | Partner org | — | Variable | $ |
| RAID | Description | Min Disks | Fault Tolerance |
|---|---|---|---|
| RAID 0 | Striping (performance, NO redundancy) | 2 | NONE |
| RAID 1 | Mirroring (exact copy) | 2 | 1 disk |
| RAID 5 | Striping + distributed parity | 3 | 1 disk |
| RAID 6 | Striping + double parity | 4 | 2 disks |
| RAID 10 | Mirror + Stripe (RAID 1+0) | 4 | 1 per mirror pair |
| Type | What It Backs Up | Archive Bit | Restore Needs |
|---|---|---|---|
| Full | Everything | Clears | 1 tape |
| Incremental | Changed since LAST backup | Clears | Full + ALL incrementals |
| Differential | Changed since last FULL | Does NOT clear | Full + LAST differential |
| Control | Description |
|---|---|
| Labelling | Mark classification level on all removable media (tapes, USB, optical) |
| Handling | Follow procedures per classification; clean desk for media; log check-in/out |
| Storage | Locked containers rated for classification; fire-rated safes for backups; off-site rotation |
| Transport | Encrypt before transport; tamper-evident bags; bonded courier for classified media |
| Sanitisation | Clearing (overwrite) → Purging (degauss/crypto-erase) → Destruction (shred/incinerate) per NIST 800-88 |
| Retention | Defined retention schedule per policy/regulation; destroy when no longer needed |
| Concept | Description |
|---|---|
| QoS | Prioritise critical traffic (VoIP, video, SCADA) over best-effort traffic; essential during DR |
| DiffServ | Differentiated Services — marks packets with DSCP values for priority routing |
| IntServ | Integrated Services — reserves bandwidth end-to-end via RSVP |
| Traffic Shaping | Smooth traffic bursts; delay non-critical packets to ensure SLA for priority flows |
| Change Type | Description | Approval |
|---|---|---|
| Standard | Pre-authorised, low-risk, well-documented (e.g., password reset) | Pre-approved — no CAB needed |
| Normal | Routine change with potential impact; follows full process | CAB review & approval required |
| Emergency | Urgent fix for critical issue (e.g., zero-day patch) | Expedited approval; retrospective CAB review |
| Concept | Definition |
|---|---|
| Configuration Baseline | Known-good approved configuration state |
| Configuration Item (CI) | Any component under config management (server, router, app) |
| CMDB | Configuration Management Database — tracks all CIs & relationships |
| CAB | Change Advisory Board — reviews/approves changes |
| Tool / Concept | Description |
|---|---|
| Infrastructure as Code (IaC) | Terraform, CloudFormation — define infrastructure in version-controlled templates; ensures consistent, repeatable deployments |
| Configuration Management Tools | Ansible, Puppet, Chef, SaltStack — enforce desired state; auto-remediate drift from baseline |
| Immutable Infrastructure | Never patch running systems; replace with new pre-hardened images. Prevents configuration drift & unpatched states |
| Baseline Compliance Scanning | CIS Benchmarks, DISA STIGs — automated scanning verifies systems match approved baseline; feed results to SIEM |
| Control Layer | Examples |
|---|---|
| Deter | Fences, lighting, signs, security guards |
| Detect | CCTV, motion sensors, intrusion alarms, dogs |
| Delay | Multiple barriers, mantraps/vestibules, bollards |
| Deny/Prevent | Locks, access cards, biometrics, guards |
| Height | Purpose |
|---|---|
| 3–4 ft | Boundary marker; deters casual trespass |
| 6–7 ft | Hard to climb; deters most intruders |
| 8 ft + razor wire | Critical/high-security areas |
| Class | Fuel | Suppression |
|---|---|---|
| A | Ordinary combustibles (wood, paper) | Water, soda acid |
| B | Flammable liquids (gas, oil) | CO₂, FM-200, dry chemical |
| C | Electrical equipment | CO₂, FM-200 (non-conductive) |
| D | Combustible metals (magnesium) | Dry powder (special agent) |
| K | Kitchen (cooking oils/fats) | Wet chemical |
| Agent | Best For | Key Concern |
|---|---|---|
| Water (wet/dry pipe) | General office | Electronics damage; dry pipe for freezing |
| FM-200 / Novec 1230 | Data centres | Clean agent; safe for electronics & humans |
| CO₂ | Unmanned areas | Displaces oxygen → LETHAL to humans |
| Halon | Legacy | Banned (ozone depletion); FM-200 is replacement |
| Concern | Control |
|---|---|
| Duress | Silent alarm / duress code (e.g., reverse PIN, panic button) |
| Travel Security | Encrypted laptops, VPN, no sensitive data on portable devices, tamper-evident bags |
| Emergency Evacuation | Drills, assembly points, head counts, AEDs, first-aid kits |
| Workplace Violence | Visitor logs, access controls, security guards, training |
| Malware Type | Characteristic | Key Fact |
|---|---|---|
| Virus | Requires host program; self-replicating | Needs user action to spread |
| Worm | Self-propagating; no host needed | Spreads via network autonomously |
| Trojan | Disguised as legitimate software | Does not self-replicate |
| Ransomware | Encrypts data; demands payment | Primary target = Availability |
| Rootkit | Hides deep in OS/firmware | Kernel rootkit = reinstall OS; firmware rootkit = replace hardware |
| Logic Bomb | Triggers on condition (date, event) | Often planted by insider |
| Spyware | Covert data collection | Keyloggers, screen capture |
| RAT (Remote Access Trojan) | Backdoor remote control | Full system control for attacker |
| Fileless Malware | Lives in memory; no files on disk | Evades traditional AV; uses PowerShell/WMI |
| Polymorphic | Changes code/signature each time | Evades signature-based detection |
| Metamorphic | Rewrites entire code | Even harder to detect than polymorphic |
| Aspect | Detail |
|---|---|
| Attack | Attacker has stolen credentials; sends repeated MFA push notifications until user approves out of frustration |
| Mitigation | Number matching (user must enter number shown on login screen), rate limiting push requests, phishing-resistant MFA (FIDO2) |
| Type | Description | Legal Note |
|---|---|---|
| Honeypot | Single decoy system designed to attract attackers | Enticement = legal |
| Honeynet | Network of honeypots; simulates entire infrastructure | More realistic; captures lateral movement |
| Type | Standard | Outcome |
|---|---|---|
| Criminal | Beyond reasonable doubt | Prosecution, jail, fines |
| Civil | Preponderance of evidence (more likely than not) | Monetary damages |
| Administrative | Least formal; organisational policy | Discipline, termination |
| Regulatory | Government agency investigation | Sanctions, fines, licence revocation |
eDiscovery is the process of identifying, collecting, and producing electronically stored information (ESI) in response to legal proceedings.
| Phase | Activity |
|---|---|
| Identification | Locate potentially relevant ESI across all systems |
| Preservation | Legal hold — prevent destruction of relevant data; overrides retention policies |
| Collection | Gather ESI in forensically sound manner |
| Processing | Reduce volume; de-duplicate; convert formats |
| Review | Attorneys assess for relevance and privilege |
| Production | Deliver to opposing counsel in agreed format |
| Direction | Monitors | Purpose |
|---|---|---|
| Ingress | Inbound traffic entering the network | Block malicious payloads, scans, unauthorized access |
| Egress | Outbound traffic leaving the network | Detect data exfiltration, C2 callbacks, policy violations |
Establishes an Information Security Continuous Monitoring (ISCM) strategy: ongoing awareness of security posture, vulnerabilities, and threats. Integrates with RMF step 7 (Monitor). Uses automated tools (SIEM, vulnerability scanners, configuration checkers) for near-real-time visibility.
| Term | Definition | Focus |
|---|---|---|
| Recovery | Bring IT operations back to functional state at alternate site | Getting systems running (DR site) |
| Restoration | Return operations to the original (or new permanent) primary facility | Moving back to normal operations |
| Concept | Definition |
|---|---|
| Threat Intelligence | IoCs, TTPs, threat feeds; actionable info about adversaries |
| Threat Hunting | Proactive search for threats that evade automated detection |
| MITRE ATT&CK | Knowledge base of adversary TTPs; maps real-world attack techniques |
| Threat | Description | Mitigation |
|---|---|---|
| Model Drift | Model accuracy degrades over time as real-world data distribution changes (data drift) or relationships shift (concept drift) | Continuous monitoring, periodic retraining, performance thresholds with automated alerts |
| Data Poisoning | Attacker manipulates training data to produce biased/wrong outputs | Input validation, provenance tracking, anomaly detection on training data |
| Model Inversion | Attacker queries model to reconstruct sensitive training data | Differential privacy, rate limiting queries, access controls on model APIs |
| Adversarial Inputs | Crafted inputs that cause model misclassification (e.g., fooling image recognition) | Adversarial training, input preprocessing, ensemble models |
| # | Mnemonic | Helps Remember |
|---|---|---|
| 1 | "Prepare Detect Contain Learn" | NIST IR phases |
| 2 | "Real Rascals Swap Places, Detectives" | Order of volatility (Registers, RAM, Swap, Processes, Disk…) |
| 3 | "RAID 0 = ZERO protection" | RAID 0 has no redundancy |
| 4 | "Hot = Hours; Warm = Wait; Cold = Construct" | Recovery site readiness |
| 5 | "Incremental = each step; Differential = from Full" | Backup types restore complexity |
| 6 | "CO₂ = Coffin; FM-200 = Friendly" | Fire suppression safety |
| 7 | "Virus needs a ride; Worm drives itself" | Virus = host + user; Worm = self-propagating |
| 8 | "A-B-C-D-K" fire classes | Ash (ordinary), Boil (liquids/gases), Current (electrical), Dynamite (combustible metals), Kitchen (cooking oils) |
| 9 | "CPTED = See-Access-Territory" | Natural surveillance, access control, territorial |
| 10 | "Duress = Silent SOS" | Covert distress signal, reverse PIN, panic button |
| # | Trap |
|---|---|
| 1 | FIRST priority in incident = human safety, THEN containment, THEN evidence |
| 2 | Evidence without chain of custody = INADMISSIBLE |
| 3 | Collect most volatile evidence FIRST (RAM before disk) |
| 4 | Forensic images must be hashed before AND after (integrity proof) |
| 5 | RAID is NOT backup — protects against disk failure only, not data loss |
| 6 | RAID 0 = performance only; 1 disk fails = ALL data lost |
| 7 | Incremental restore needs Full + ALL incrementals (slow restore) |
| 8 | Differential restore needs Full + LAST differential only (faster restore) |
| 9 | CO₂ fire suppression = lethal to humans; FM-200 = safe for people |
| 10 | Halon is banned (ozone); FM-200 is the replacement |
| 11 | Criminal = beyond reasonable doubt; Civil = preponderance of evidence |
| 12 | Change management = formal CAB approval BEFORE implementation |
| 13 | Mantrap prevents tailgating; CCTV detects but doesn't prevent |
| 14 | Lessons learned meeting ideally within 1-2 weeks of incident |
| 15 | Virus needs host + user action; Worm self-propagates across network autonomously |
| 16 | Rootkit in firmware = replace hardware; OS rootkit = full reinstall |
| 17 | Polymorphic changes signature; metamorphic rewrites entire code — both evade signature AV |
| 18 | Allowlisting > blocklisting (default-deny is stronger than default-allow) |
| 19 | Entrapment = illegal (inducing crime); enticement = legal (honeypot lures existing intent) |
| 20 | Fire Class C = electrical — NEVER use water (electrocution risk) |
| 21 | DR Communications plan must have BACKUP channels (primary comms may be destroyed by the disaster) |
| 22 | Cloud forensics: SaaS = least forensic access; IaaS = most. Negotiate investigation rights in contract BEFORE incident |
| 23 | UEBA = best technical control for insider threats (baselines normal behaviour, detects anomalies) |
| 24 | IaC + config automation (Ansible/Puppet) enforces baseline compliance at scale — manual doesn’t work for large environments |
| 25 | Recovery = move TO DR site; Restoration = move BACK to primary. During restoration, DR site becomes the backup |
| 26 | Copies of evidence are always as admissible as originals |
| 27 | Computer logs are inadmissible hearsay in all cases |
| 28 | All evidence types have equal legal weight |
| 29 | Criminal burden of proof applies to all investigations |
| 30 | IDS catches everything |
| 31 | SPAN port and network tap are equally reliable |
| 32 | Clipping levels are unnecessary overhead |
| 33 | Warm site = hot site without data |
| Model | Approach | Key Feature |
|---|---|---|
| Waterfall | Sequential, linear | No going back; requirements fixed upfront; documentation-heavy |
| V-Model | Waterfall + testing at each stage | Verification & validation mapped to each dev phase |
| Spiral | Iterative with risk analysis | Each loop = risk assessment; prototyping; cost estimation |
| Agile | Iterative, incremental | Sprints (2-4 weeks); working software; customer collaboration |
| Scrum | Agile framework | Product Owner, Scrum Master, Sprint, Daily Standup, Sprint Review |
| DevOps | Dev + Operations collaboration | CI/CD pipelines; automation; rapid deployment |
| DevSecOps | DevOps + Security | "Shift left" — integrate security from the start (SAST/DAST in pipeline) |
| Scaled Agile Framework (SAFe) | Agile at enterprise scale | Multi-team coordination; Program Increments (PIs); Agile Release Trains (ARTs); adds governance layer to Agile for large organisations |
| Role | Contribution |
|---|---|
| Security Architect | Threat models, security requirements, design review |
| Developer | Secure coding, fix vulnerabilities from SAST/DAST |
| QA / Test | Security test cases, regression testing, fuzz testing |
| Operations | Deployment hardening, monitoring, incident response readiness |
| Product Owner | Prioritises security stories alongside features |
| Source | Security Considerations |
|---|---|
| COTS (Commercial Off-The-Shelf) | Evaluate vendor security posture; review CVEs; ensure patch support; contractual SLAs for vulnerability response |
| Open Source | Review licence, community activity, known vulns (SCA); verify integrity of downloads (checksums/signatures) |
| Third-Party Libraries | SBOM (Software Bill of Materials); track dependencies; automated SCA in CI/CD pipeline |
| Managed / Cloud Services | Shared responsibility model; vendor SOC 2 reports; assess API security; data residency; exit strategy |
| Concept | Description |
|---|---|
| Policy as Code | Security policies written in code (OPA/Rego, Sentinel); version-controlled, testable, auditable |
| Infrastructure as Code (IaC) | Terraform, CloudFormation — security configs embedded in templates; drift detection |
| Security Orchestration (SOAR) | Automated incident response playbooks; enrichment → decision → action |
| Concept | Definition | Security Relevance |
|---|---|---|
| Encapsulation | Hides internal state; exposes only public interface | Data hiding prevents direct manipulation — enforces controlled access to object data |
| Inheritance | Child class inherits properties/methods from parent | Inherited permissions can create unintended access; must review inherited security attributes |
| Polymorphism | Same interface, different behaviour depending on object type | Malicious class could override methods — validate object type at runtime |
| Abstraction | Simplifies complex systems; shows only relevant detail | Reduces attack surface by hiding implementation complexity |
| Coupling | Degree of interdependence between modules | Loose coupling preferred — vulnerability in one module doesn't cascade to others |
| Cohesion | Degree to which module elements belong together | High cohesion preferred — single-purpose modules are easier to secure and test |
| # | Vulnerability | Mitigation |
|---|---|---|
| A01 | Broken Access Control | Deny by default, enforce server-side, least privilege |
| A02 | Cryptographic Failures | Strong algorithms, key management, encrypt at rest/transit |
| A03 | Injection (SQLi, XSS, LDAP, OS command) | Parameterised queries, input validation, escaping |
| A04 | Insecure Design | Threat modelling, secure design patterns, abuse cases |
| A05 | Security Misconfiguration | Hardening, remove defaults, minimal install |
| A06 | Vulnerable Components | SCA scanning, patch management, SBOM |
| A07 | Authentication Failures | MFA, strong passwords, session management |
| A08 | Software & Data Integrity | Verify updates, code signing, CI/CD integrity |
| A09 | Logging & Monitoring Failures | Centralised logging, alert on suspicious events |
| A10 | SSRF (Server-Side Request Forgery) | Validate URLs, whitelist destinations, network segmentation |
| Attack | Description | Prevention |
|---|---|---|
| SQL Injection | Malicious SQL in input fields | Parameterised queries / prepared statements |
| XSS (Cross-Site Scripting) | Inject malicious script into web pages | Output encoding, CSP headers |
| CSRF (Cross-Site Request Forgery) | Trick authenticated user into unintended action | Anti-CSRF tokens, SameSite cookies |
| Buffer Overflow | Write beyond allocated memory | Bounds checking, ASLR, DEP/NX, safe languages |
| Race Condition (TOCTOU) | Time-of-check vs time-of-use gap exploited | Locks, atomic operations |
| SSRF | Server tricked into fetching internal resources | Whitelist, disable unnecessary protocols |
| Control | Description |
|---|---|
| Authentication | OAuth 2.0 / OpenID Connect for API auth; API keys for identification (NOT authentication alone) |
| Authorisation | Scope-based access; enforce least privilege per endpoint; RBAC on API resources |
| Rate Limiting | Throttle requests to prevent abuse/DoS; implement per-user and per-IP limits |
| Input Validation | Validate all parameters, headers, body; reject unexpected fields; type checking |
| API Gateway | Centralised enforcement point for auth, rate limiting, logging, TLS termination |
| Versioning | Deprecate old API versions gracefully; avoid breaking changes; sunset policy |
| Documentation | OpenAPI/Swagger specs; avoid exposing internal endpoints; restrict discovery in production |
| Concept | Definition |
|---|---|
| Aggregation | Combining low-classification data to derive higher-classification information |
| Inference | Deducing sensitive info from non-sensitive data + metadata |
| Polyinstantiation | Multiple rows with same key but different classification levels (prevents inference) |
| Views | Virtual table limiting what users see (constrained interface) |
| Stored Procedures | Precompiled DB operations; prevent direct SQL access |
| Type | Description |
|---|---|
| Relational (SQL) | Tables, rows, columns; structured; ACID; SQL (MySQL, PostgreSQL, Oracle) |
| NoSQL | Document, key-value, graph, columnar; flexible schema; BASE (MongoDB, Cassandra) |
| Data Warehouse | Historical aggregated data; OLAP; decision support |
| Data Lake | Raw unstructured/structured data; schema-on-read; big data analytics |
| Normal Form | Requirement | Eliminates |
|---|---|---|
| 1NF | Each cell contains a single atomic value; no repeating groups | Duplicate data in rows |
| 2NF | 1NF + all non-key attributes fully depend on the ENTIRE primary key | Partial dependencies (attributes depending on part of composite key) |
| 3NF | 2NF + no transitive dependencies (non-key attributes don't depend on other non-key attributes) | Transitive dependencies |
| Concept | Definition |
|---|---|
| SBOM | Software Bill of Materials — lists all components/libraries/dependencies |
| Code Signing | Digital signature on code to prove integrity & authenticity |
| CI/CD Pipeline Security | Automated build-test-deploy; integrate SAST, DAST, SCA at each stage |
| Third-Party Libraries | SCA to identify vulnerable components; pin versions |
| Model | Levels | Focus |
|---|---|---|
| CMM/CMMI | 1-Initial → 2-Managed → 3-Defined → 4-Quantitatively Managed → 5-Optimising | Process maturity |
| SAMM (OWASP) | Governance, Design, Implementation, Verification, Operations | Software security maturity |
| BSIMM | Observation-based (descriptive, not prescriptive) | Real-world software security practices |
| Threat | Description |
|---|---|
| Data Poisoning | Adversary corrupts training data → model produces wrong results |
| Adversarial Inputs | Carefully crafted inputs that fool model (e.g., slightly modified image misclassified) |
| Model Stealing | Querying model enough to reconstruct it |
| Prompt Injection | Manipulating LLM inputs to bypass controls/extract data |
| # | Mnemonic | Helps Remember |
|---|---|---|
| 1 | "Waterfall = Water flows down only" | Can't go back in Waterfall |
| 2 | "Shift Left = Security Sooner" | Test security early in SDLC |
| 3 | "ACID = All Consistent Isolated Durable" | Database transaction properties |
| 4 | "CMMI 1-5: I Must Define, Quantify, Optimise" | CMM maturity levels |
| 5 | "Parameterised = Protected (from SQLi)" | SQL injection prevention |
| 6 | "The Key, the Whole Key, Nothing but the Key" | Normalization: 1NF, 2NF, 3NF |
| 7 | "Loose Coupling + High Cohesion = Secure Code" | OOP design quality |
| 8 | "Encapsulation = Envelope (hide internals)" | Best OOP security feature |
| # | Trap |
|---|---|
| 1 | SQL injection prevention = parameterised queries, NOT input filtering alone |
| 2 | XSS prevention = output encoding (not just input validation) |
| 3 | Buffer overflow prevention = ASLR + DEP + bounds checking |
| 4 | Aggregation ≠ Inference (aggregation = combining; inference = deducing) |
| 5 | TOCTOU = race condition; atomic operations fix it |
| 6 | Waterfall = no iteration; Spiral = risk-driven iteration; Agile = customer-driven iteration |
| 7 | DevSecOps = "shift left"; integrate security into CI/CD pipeline |
| 8 | SBOM = know what's in your software (supply chain transparency) |
| 9 | BSIMM = descriptive (what orgs DO); SAMM = prescriptive (what orgs SHOULD do) |
| 10 | Fail secure = deny on error; Fail open = allow on error (fail secure is default for security) |
| 11 | Encapsulation = best OOP security feature (data hiding); inheritance can WEAKEN security (inherits parent's flaws) |
| 12 | Normalization: 1NF=atomic values, 2NF=no partial dependency, 3NF=no transitive dependency. Denormalization trades integrity for performance. |
| 13 | Software escrow protects against VENDOR FAILURE, not code quality. Triggers: bankruptcy, cease of support, breach of SLA |
| 14 | Polyinstantiation prevents inference attacks by creating multiple versions of data at different classification levels |
| 15 | SAFe = Agile for large enterprises; adds governance layer; exam may distinguish SAFe from Scrum (team-level) and Kanban (flow-based) |
| 16 | All XSS types are equally dangerous |
| 17 | CSRF and XSS are the same attack |
| 18 | Deserialization is safe if input is validated |
| 19 | Coupling and cohesion are both "higher is better" |
| 20 | CMMI levels are not test-relevant in CISSP |
| 21 | Developer testing = acceptance testing |
| 22 | Authorization checks are only needed at login |
| 23 | SSRF is a client-side attack |
| # | Trap (What the Exam Wants You to Get Wrong) | Correct Answer |
|---|---|---|
| 1 | Data Owner is IT / sysadmin | Data Owner = business executive; Custodian = IT |
| 2 | ISO 27002 is certifiable | Only ISO 27001 is certifiable; 27002 is guidance |
| 3 | "Ignore" as risk response | Not valid. Use "Accept" (documented decision) |
| 4 | Transfer eliminates accountability | Transfers financial burden only, NOT legal liability |
| 5 | Compliance = security | Compliance is the floor, not the ceiling |
| 6 | Copyright protects ideas | Copyright protects expression not ideas |
| 7 | Trade secrets auto-protected | Require active protection or they are lost |
| 8 | GPL is safe for commercial | GPL is viral/copyleft — derivative works must be GPL |
| 9 | EF is a percentage number (50) | EF is a decimal (0.50) |
| 10 | Ransomware primarily hits confidentiality | Primary target = Availability (to extort payment) |
| 11 | Hot site is always the right answer | Choose cheapest option meeting MTD/RTO/RPO |
| 12 | First action in disaster = restore systems | First action = personnel safety |
| 13 | First action on termination = exit interview | First action = revoke access immediately |
| 14 | SoD prevents collusion | SoD prevents fraud, NOT collusion |
| 15 | RTO = total recovery time | RTO + WRT ≤ MTD; WRT is verification time after restore |
| 16 | Mandatory vacation is preventive | Mandatory vacation = detective (exposes fraud) |
| 17 | Training completion = effectiveness | Behavioural metrics (click/report rate) > activity metrics |
| 18 | Canon 3 (employer) over Canon 1 (society) | Society always first — whistleblowing justified |
| 19 | Reciprocal agreements are reliable | Unreliable — both orgs may face same disaster |
| 20 | Least Privilege = Need to Know | LP = permissions (what you do); NtK = information (what you see) |
| # | ❌ Wrong Belief (Trap) | ✅ Correct Answer |
|---|---|---|
| 21 | Higher-numbered canon takes precedence when canons conflict | Canon 1 (society/public interest) always overrides higher-numbered canons — whistleblowing is justified when public safety is at stake |
| 22 | Policy and guideline are both mandatory documents | Policy = mandatory WHY; Standard = mandatory WHAT; Procedure = mandatory HOW; Guideline = optional HOW — only one non-mandatory level |
| 23 | Data sovereignty is determined by the cloud provider's HQ country | Determined by the country where data is stored/processed; provider HQ is irrelevant |
| 24 | Technical controls are the best fix for human error | Root cause of human error = lack of awareness; exam answer = security awareness training |
| 25 | First priority in a disaster is restoring critical systems | Personnel safety ALWAYS comes first, before any system recovery action |
| 26 | Work-for-hire copyright = creator's life + 70 years | Individual = life + 70 yrs; work-for-hire = 95 yrs from publication OR 120 yrs from creation (whichever is shorter) |
| 27 | EF is expressed as a percentage (e.g., 50) | EF is a decimal (0.50, not 50); ARO is a frequency — 0.1 = once every 10 years |
| 28 | FAIR is a qualitative risk method like OCTAVE | FAIR is quantitative — uses Loss Event Frequency × Loss Magnitude to produce numeric risk values |
| 29 | Due care and due diligence mean the same thing | Different concepts: due diligence = research/investigation before acting; due care = ongoing responsible action after deciding |
| 30 | The CISO is ultimately accountable for organisational security | Senior management (executives/board) are ultimately accountable; CISO is responsible for execution |
| 31 | Risk appetite and risk tolerance are synonyms | Different levels: risk appetite = strategic high-level willingness; risk tolerance = tactical acceptable variance from targets |
| 32 | Delphi technique is structured group brainstorming | Delphi = anonymous expert consensus gathered in iterative rounds — specifically designed to prevent groupthink |
| 33 | BIA and Risk Assessment perform the same analysis | Different outputs: BIA identifies business impact and criticality (MTD/RTO/RPO); Risk Assessment evaluates threats and likelihood |
| 34 | Criminal, civil, and administrative law are interchangeable legal categories | Three distinct categories: Criminal = beyond reasonable doubt, prison/fines; Civil = preponderance of evidence, monetary damages; Administrative = regulatory penalties, licence revocation |
| 35 | MTD (Maximum Tolerable Downtime) is set by the IT department | MTD is a business decision made by data owners/business executives, not IT — IT must satisfy the MTD IT cannot define it |
| 36 | Prudent Person Rule does not apply to cybersecurity professionals | It applies fully — security professionals are held to the standard of a reasonably prudent person in the same role; negligence is judged against this standard |
| # | Trap | Correct Answer |
|---|---|---|
| 1 | "Confidential" means the same in govt & commercial | LOWEST govt classified but HIGHEST commercial level — naming collision |
| 2 | Data Owner = IT department | Data Owner = senior management (NOT IT); Custodian = IT |
| 3 | Degaussing works on SSDs | Degaussing SSDs = ZERO effect (data fully intact) |
| 4 | DoD 5220.22-M overwrite works on SSDs | UNRELIABLE for SSDs (wear-levelling bypasses it) |
| 5 | Use overwrite for cloud data destruction | Crypto-erase = preferred for SSDs AND cloud |
| 6 | Degaussed HDD can be reused | Degaussed HDD becomes permanently inoperable (servo tracks destroyed) |
| 7 | Retention schedule overrides everything | Litigation hold OVERRIDES all retention schedules |
| 8 | Anonymised & pseudonymised treated the same under GDPR | Anonymised = GDPR no longer applies; Pseudonymised = GDPR still applies |
| 9 | Processor can do whatever it wants with data | Processor exceeding instructions BECOMES a controller (full liability) |
| 10 | Right to Erasure is absolute | NOT absolute — 6 major exceptions (legal claims, public health, etc.) |
| 11 | DPO can also serve as CISO | DPO cannot hold CISO/CTO/CEO roles simultaneously (conflict of interest) |
| 12 | GDPR 72-hour clock starts at incident time | Starts at controller awareness, not incident discovery |
| 13 | Network DLP sees all traffic | Network DLP requires SSL inspection to see HTTPS content |
| 14 | Data in transit is hardest to protect | Data in use is HARDEST to protect (requires hardware TEE) |
| 15 | FDE protects a running machine | FDE useless on powered-on, logged-in devices |
| 16 | Mixed-classification system = lowest level | Classify UP: system classified at the highest level of data it handles |
| 17 | Simple delete = secure destruction | Standard file deletion only removes pointers — data remanence persists. Use NIST 800-88. |
| 18 | EOS systems are fine if isolated | EOS = unpatched = high-risk. Must: isolate, increase monitoring, compensating controls, document risk acceptance. |
| 19 | Data steward = data owner | Steward handles data quality/governance; owner sets classification/access decisions |
| 20 | Scoping = tailoring | Scoping selects controls; tailoring customizes selected controls |
| 21 | Marking and labeling are the same | Marking is internal/metadata context; labeling is external/physical indicator |
| 22 | All sanitization methods are equivalent | NIST 800-88: Clear < Purge < Destroy; choose by sensitivity and reuse intent |
| # | Trap | Correct Answer |
|---|---|---|
| 1 | BLP and Biba have the same rules | EXACT opposites. BLP = confidentiality (no read up/write down); Biba = integrity (no read down/write up) |
| 2 | Clark-Wilson is about confidentiality | Clark-Wilson = commercial integrity (well-formed transactions via TPs on CDIs) |
| 3 | Brewer-Nash uses static rules | Dynamic rules based on access HISTORY (Chinese Wall) |
| 4 | SABSA / Zachman / TOGAF are all the same | SABSA = security framework; Zachman/TOGAF = enterprise architecture (not security-specific) |
| 5 | EAL 7 is the target for commercial products | EAL 4 = highest practically achievable; EAL 7 = formal verification (extremely rare) |
| 6 | Reference Monitor = Security Kernel | Reference Monitor = concept; Security Kernel = implementation |
| 7 | Data leakage between VMs is the top threat | VM Escape is the most critical virtualisation attack |
| 8 | SCADA/ICS uses CIA priority order | SCADA priority = Safety first, NOT confidentiality (SAIC not CIA) |
| 9 | AES block size changes with key size | AES block size ALWAYS 128 bits — only key size varies (128/192/256) |
| 10 | ECB mode is acceptable | ECB is INSECURE — identical plaintext blocks → identical ciphertext blocks (patterns leak) |
| 11 | DH and DSA can do everything RSA does | DH = key exchange ONLY; DSA = signatures ONLY; RSA = everything |
| 12 | HMAC provides non-repudiation | HMAC cannot provide non-repudiation (shared secret key — both parties could generate) |
| 13 | Encryption provides non-repudiation | Digital signatures = ONLY way to get non-repudiation |
| 14 | 128-bit hash = 128-bit collision resistance | Birthday attack = 2^(n/2); 128-bit hash = only 64-bit collision resistance |
| 15 | RA can sign certificates | RA verifies identity but does NOT sign certificates |
| 16 | Root CA should be online for availability | Root CA must be OFFLINE (air-gapped) |
| 17 | Escrow all keys for recovery | NEVER escrow signing keys (destroys non-repudiation). Only escrow encryption keys. |
| 18 | Side-channel attacks break the algorithm | Side-channel attacks exploit implementation, NOT algorithm math |
| 19 | TLS 1.3 supports RSA key exchange | TLS 1.3 mandates PFS (only DHE/ECDHE); RSA key exchange removed |
| 20 | Containers have the same isolation as VMs | Container isolation WEAKER than VM (shared kernel — kernel compromise = all containers) |
| 21 | Dedicated security mode is the most complex | Dedicated = simplest; Multilevel = most complex (different clearances; needs MAC) |
| 22 | Covert storage and timing channels are equally hard to detect | Covert timing channels are HARDER to detect than storage channels |
| 23 | RAM is empty immediately after power-off | Cold boot attack: RAM retains data briefly — freeze chips to extract encryption keys |
| 24 | Private cloud = on-premises | Private cloud can be hosted off-site by a third party — key is exclusive use |
| 25 | TCSEC B2 requires covert channel mitigation | B2+ requires covert channel ANALYSIS; B3+ requires MITIGATION |
| 26 | Encapsulation is just about hiding code | Encapsulation = BEST OOP security feature (data hiding). Inheritance can weaken security. |
| 27 | ECC needs the same key size as RSA | ECC-256 ≈ RSA-3072 ≈ 128-bit security level. ECC punches above its weight. |
| 28 | Any block cipher mode provides authentication | Only GCM (AEAD) provides both confidentiality AND authentication. CBC/CTR do NOT. |
| 29 | Symmetric key count = 2n | Symmetric = n(n−1)/2; Asymmetric = 2n. Don't mix them up. |
| 30 | Security depends on keeping algorithm secret | Kerckhoffs: security should depend on key secrecy, not algorithm secrecy |
| 31 | Quantum breaks all encryption equally | Asymmetric is hit hardest; AES-256 remains viable with adjusted assumptions |
| 32 | One-time pad is always unbreakable in real deployments | Only if key is truly random, never reused, and at least message-length |
| 33 | Zero-knowledge proof requires revealing secret | It proves knowledge without disclosing the secret |
| 34 | Stream and block ciphers are interchangeable | Different primitives; do not confuse cipher type with mode of operation |
| 35 | Confusion and diffusion are the same | Confusion obscures key relation; diffusion spreads plaintext influence |
| # | Trap | Correct Answer |
|---|---|---|
| 1 | IPv6 requires IPSec use | IPv6 has mandatory IPSec SUPPORT, not mandatory USE |
| 2 | DNSSEC encrypts DNS queries | DNSSEC = integrity/authentication only, NOT confidentiality (use DoH/DoT for that) |
| 3 | AH provides encryption | AH provides NO encryption; also broken by NAT (NAT modifies IP header) |
| 4 | TLS 1.3 is backward-compatible with RSA key exchange | TLS 1.3 = 1-RTT, mandates PFS, removed RSA key exchange |
| 5 | WEP is weak but usable | WEP IV is only 24 bits → exhausted in minutes → trivially cracked |
| 6 | WPA3 and WPA2 handle offline attacks the same | WPA3-SAE resists offline dictionary attacks (unlike WPA2-PSK) |
| 7 | 802.1X uses TACACS+ | 802.1X uses RADIUS (not TACACS+) for wireless enterprise auth |
| 8 | Switches are inherently secure | Switches can be compromised (MAC flooding, VLAN hopping) |
| 9 | IPSec VPN is always easier to deploy than SSL VPN | SSL VPN works through firewalls (port 443) — advantage over IPSec |
| 10 | SDN has distributed control | SDN separates control plane from data plane (centralised management) |
| 11 | Zero Trust = block everything | Zero Trust = "never trust, always verify" not "block everything" |
| 12 | Smurf = TCP attack | Smurf attack uses ICMP + broadcast + spoofed source (amplification) |
| 13 | Management plane doesn't need special protection | Management plane = most sensitive; must isolate via out-of-band management |
| 14 | Cut-through switching is more secure | Cut-through is faster but passes corrupted frames; store-and-forward checks CRC (more secure) |
| 15 | Data sovereignty = country of company HQ | Data sovereignty = governed by country where data is STORED |
| 16 | Multilayer protocols are always inspected by security controls | Encapsulated protocols may bypass security controls that only inspect one layer (VPN within VPN, IPv6 in IPv4) |
| 17 | Bluetooth attacks are all equivalent | Bluejacking (message), bluesnarfing (data theft), bluebugging (device control) |
| 18 | FTPS and SFTP are the same protocol | FTPS = FTP over TLS; SFTP = SSH file transfer protocol |
| 19 | L2TP encrypts traffic by itself | L2TP needs IPSec for encryption |
| 20 | SYN floods are difficult to mitigate | SYN cookies and rate limiting are standard controls |
| 21 | S/MIME and PGP use the same trust model | S/MIME is CA/PKI; PGP is web-of-trust |
| 22 | Fraggle and Smurf are identical | Smurf uses ICMP; Fraggle uses UDP echo amplification |
| 23 | DNS cache poisoning affects one host only | Compromised resolver can poison responses for all its clients |
| # | Trap | Correct Answer |
|---|---|---|
| 1 | Two passwords = MFA | NOT MFA (same factor type); must be DIFFERENT factor types |
| 2 | Type 1 error = authentication Type 1 factor | Type 1 error = False Rejection (FRR); Type 2 error = False Acceptance (FAR). Don't confuse with auth factor types. |
| 3 | OAuth 2.0 authenticates users | OAuth 2.0 is AUTHORISATION only — use OIDC for authentication |
| 4 | SAML and OIDC use the same format | SAML uses XML; OIDC uses JWT tokens (modern, mobile-friendly) |
| 5 | Kerberos uses asymmetric crypto | Kerberos = symmetric crypto + time-dependent; Golden Ticket = compromised KRBTGT |
| 6 | RADIUS encrypts everything | RADIUS encrypts password only; TACACS+ encrypts entire payload |
| 7 | RBAC and Rule-Based are the same | RBAC ≠ Rule-Based. RBAC = Role-Based; Rule-Based = IF-THEN (e.g., firewall rules) |
| 8 | Iris scan is the most invasive | Retina scan = most accurate AND most invasive; can reveal health info |
| 9 | Access rights only grow when appropriate | Privilege creep = accumulation without revocation. Fix with periodic UARs. |
| 10 | MAC and DAC have similar restrictiveness | DAC is most permissive (owner decides); MAC is most restrictive (system decides) |
| 11 | Federation and SSO are the same | Federation = cross-org trust; SSO = same organisation, multiple apps |
| 12 | Smart card is single-factor | Smart card = possession (Type 2) + PIN = knowledge (Type 1) = MFA |
| 13 | RBAC and risk-based access control work the same way | Risk-based = DYNAMIC (changes per session); RBAC = STATIC (changes per role assignment) |
| 14 | Session tokens can go in URLs | Session tokens must be regenerated after login (prevent fixation); never in URLs (bookmarks/logs leak them) |
| 15 | Service accounts are low-risk | Service accounts = top attack vector; hardcoded creds, orphan accounts, no rotation = audit failures |
| 16 | Service accounts need stored passwords | Managed identities (cloud-native) eliminate stored credentials entirely — preferred approach |
| 17 | FAR is less dangerous than FRR | FAR is MORE DANGEROUS (lets intruder in). CER/EER = where FRR=FAR (lower = more accurate). |
| 18 | Kerberos has unlimited clock tolerance | Kerberos requires 5-minute clock skew tolerance (NTP synchronisation critical) |
| 19 | Push-based MFA is phishing-resistant | Push-based MFA alone is NOT phishing-resistant. MFA fatigue/push bombing is real. Use FIDO2/WebAuthn or number matching. |
| 20 | Identity proofing = authentication | Proofing is initial enrollment identity verification; authentication is ongoing login verification |
| 21 | RBAC is the most granular model | ABAC is generally more granular and context-aware |
| 22 | Privileged users should have standing access | JIT/JEA reduces standing privilege risk |
| 23 | PAM and IAM are the same scope | PAM is a focused subset for privileged identities |
| 24 | Password spraying = brute force = credential stuffing | Distinct attack patterns with different detection/mitigation |
| 25 | Authentication only happens at login | Continuous/adaptive auth validates session posture over time |
| # | Trap | Correct Answer |
|---|---|---|
| 1 | Vulnerability scan = penetration test | Vulnerability scan identifies; penetration test exploits |
| 2 | Verbal approval is sufficient for pentest | Written authorisation REQUIRED before any pentest (no verbal OK) |
| 3 | SOC 2 Type I and Type II are equally valuable | SOC 2 Type II > Type I for ongoing assurance (period vs point-in-time) |
| 4 | Code review catches all bugs | Fuzz testing finds bugs code review misses (crashes, memory corruption) |
| 5 | MTBF and MTTF are interchangeable | MTBF includes repair time (repairable items); MTTF = until first failure (no repair assumed) |
| 6 | Logs are tamper-proof by default | Log integrity requires centralised logging + tamper protection + NTP |
| 7 | Red team and Purple team are the same | Red team = stealth adversary sim; Purple team = collaborative improvement |
| 8 | SCA scans your code | SCA finds vulnerable open-source libraries (not your code, their bugs) |
| 9 | KPI and KRI are interchangeable | KPI = performance (backward-looking); KRI = risk warning (forward-looking) |
| 10 | Backup logs confirming success = backups work | Backup verification = actually TEST restores regularly, not just check logs |
| 11 | SOC 2 can skip Security criteria | Security (Common Criteria) is MANDATORY in every SOC 2 report. Other TSC categories are optional. |
| 12 | SAST and DAST test the same thing | SAST = static source code analysis (white-box); DAST = running app testing (black-box). Both needed. |
| 13 | Synthetic monitoring = Real User Monitoring | Synthetic = scripted/proactive (pre-production); RUM = actual users/passive (production) |
| 14 | SOC 1, SOC 2, SOC 3 are equivalent reports | SOC 1 = financial controls; SOC 2 = trust services; SOC 3 = public summary |
| 15 | 100% code coverage proves software is secure | Coverage is a quantity metric, not proof of defect absence |
| 16 | Patches do not require regression testing | Regression testing is required to avoid break/fix side effects |
| 17 | False positives are more dangerous than false negatives | False negatives are riskier because true attacks are missed |
| 18 | Only use-case testing is needed | Abuse/misuse-case testing is critical for security assurance |
| # | Trap | Correct Answer |
|---|---|---|
| 1 | First priority in incident = contain the breach | FIRST = human safety, THEN containment, THEN evidence |
| 2 | Evidence is always admissible | Evidence without chain of custody = INADMISSIBLE |
| 3 | Image hard drive first | Collect most volatile evidence FIRST (RAM before disk) |
| 4 | Hash forensic image after creation only | Forensic images must be hashed before AND after (integrity proof) |
| 5 | RAID = backup | RAID is NOT backup — protects against disk failure only, not data loss/corruption |
| 6 | RAID 0 has some redundancy | RAID 0 = performance only; 1 disk fails = ALL data lost |
| 7 | Incremental backup = fast restore | Incremental restore needs Full + ALL incrementals (slow restore) |
| 8 | Differential backup = slow restore | Differential restore needs Full + LAST differential only (faster restore) |
| 9 | CO₂ is safe for data centres | CO₂ fire suppression = lethal to humans; FM-200 = safe for people |
| 10 | Halon is still available | Halon is banned (ozone depletion); FM-200 is the replacement |
| 11 | Criminal and civil cases use the same burden of proof | Criminal = beyond reasonable doubt; Civil = preponderance of evidence |
| 12 | Emergency changes skip CAB | Emergency changes have expedited approval but still require retrospective CAB review |
| 13 | CCTV prevents tailgating | CCTV detects but doesn't prevent. Mantrap/vestibule prevents tailgating. |
| 14 | Lessons learned can wait months | Lessons learned meeting ideally within 1-2 weeks of incident |
| 15 | Virus and worm are the same | Virus needs host + user action; Worm self-propagates across network autonomously |
| 16 | OS reinstall fixes all rootkits | OS rootkit = full reinstall; firmware rootkit = REPLACE HARDWARE |
| 17 | Polymorphic and metamorphic are the same | Polymorphic changes signature; metamorphic rewrites entire code — both evade signature AV |
| 18 | Blocklisting is effective enough | Allowlisting > blocklisting (default-deny is stronger than default-allow) |
| 19 | Honeypot = entrapment | Enticement = legal (honeypot lures existing intent); Entrapment = illegal (inducing crime) |
| 20 | Water works for electrical fires | Fire Class C = electrical — NEVER use water (electrocution risk); use CO₂ or FM-200 |
| 21 | DR plan only needs one communication channel | DR Communications plan must have BACKUP channels (primary comms may be destroyed) |
| 22 | Cloud forensics is like traditional forensics | Cloud: SaaS = least forensic access; IaaS = most. Negotiate rights in contract BEFORE incident. |
| 23 | Technical controls are best for insider threats | UEBA = best technical control (baselines behaviour, detects anomalies). But combine with administrative controls (rotation, vacation). |
| 24 | Manual config management is fine | IaC + config automation (Ansible/Puppet) enforces baseline at scale — manual doesn't work for large environments |
| 25 | Recovery = restoration | Recovery = move TO DR site; Restoration = move BACK to primary. During restoration, DR site becomes the backup. |
| 26 | Push-based MFA is fully secure | MFA fatigue/push bombing: attacker spams push notifications. Fix: number matching, FIDO2, rate limiting. |
| 27 | Low humidity is fine for electronics | Too low (<40%) → ESD damage; too high (>60%) → condensation/corrosion. Ideal: 40-60% RH. |
| 28 | Spoliation has minor consequences | Failure to preserve evidence under litigation hold = spoliation = severe legal sanctions |
| 29 | Egress monitoring is optional | Egress filtering is critical but often neglected. DLP + firewall + proxy prevent data exfiltration and C2 callbacks. |
| 30 | UPS is sufficient for extended outages | UPS = short-term (minutes); Generator = long-term. Blackout needs BOTH. |
| 31 | Evidence copies are always equal to originals in court | Original preferred; copies need authenticity proof (hash + custody) |
| 32 | System logs are always inadmissible hearsay | Can be admitted under business-records exception with proper controls |
| 33 | All evidence types carry equal legal weight | Real/documentary/testimonial/demonstrative have different strengths |
| 34 | Criminal burden of proof applies to all cases | Standards vary by criminal, civil, and administrative context |
| 35 | IDS alone detects all attacks | Signature misses unknowns; anomaly catches unknowns with more false positives |
| 36 | SPAN ports are as forensically reliable as taps | Taps are more reliable; SPAN can drop packets under load |
| 37 | Clipping levels are optional tuning noise | Threshold tuning is essential to avoid alert fatigue or misses |
| 38 | Warm site = hot site without data | Recovery capability and activation effort differ significantly by hot/warm/cold |
| # | Trap | Correct Answer |
|---|---|---|
| 1 | Input filtering stops SQL injection | SQL injection prevention = parameterised queries, NOT input filtering alone |
| 2 | Input validation stops XSS | XSS prevention = output encoding (not just input validation) |
| 3 | Buffer overflows need one defence | Buffer overflow prevention = ASLR + DEP + bounds checking (defence in depth) |
| 4 | Aggregation and inference are the same | Aggregation = combining; Inference = deducing |
| 5 | Race conditions are hard to fix | TOCTOU = race condition; fix with atomic operations and locks |
| 6 | Waterfall/Spiral/Agile are interchangeable | Waterfall = no iteration; Spiral = risk-driven iteration; Agile = customer-driven iteration |
| 7 | Security can be added at the end of the SDLC | DevSecOps = "shift left"; integrate security into CI/CD pipeline from the start |
| 8 | Supply chain is someone else's problem | SBOM = know what's in your software (supply chain transparency) |
| 9 | BSIMM and SAMM are the same | BSIMM = descriptive (what orgs DO); SAMM = prescriptive (what orgs SHOULD do) |
| 10 | Fail open is the secure default | Fail secure = deny on error; Fail open = allow on error. Fail secure is the security default. |
| 11 | All OOP features improve security equally | Encapsulation = best OOP security feature (data hiding); inheritance can WEAKEN security (inherits parent's flaws) |
| 12 | Denormalization is always bad | Normalization: 1NF=atomic, 2NF=no partial dep, 3NF=no transitive dep. Denormalization trades integrity for performance (intentional choice). |
| 13 | Software escrow = code review | Software escrow protects against VENDOR FAILURE, not code quality. Triggers: bankruptcy, SLA breach. |
| 14 | Inference attacks can't be prevented | Polyinstantiation prevents inference attacks by creating multiple data versions at different classification levels |
| 15 | SAFe = Scrum | SAFe = Agile for large enterprises; adds governance layer. Scrum = team-level. Kanban = flow-based. |
| 16 | API keys = authentication | API keys = identification only, NOT authentication. Use OAuth 2.0/OIDC for API auth. |
| 17 | OWASP Top 10 Web and API are the same | OWASP API Security Top 10 is separate. Key API risks: BOLA (Broken Object Level Auth), mass assignment, excessive data exposure. |
| 18 | Whitelist (allow-list) input validation < blacklist | Whitelist (allow known-good) > Blacklist (block known-bad) — always prefer whitelist approach |
| 19 | All XSS variants are equally dangerous | Stored XSS usually has broader impact than reflected/DOM depending on context |
| 20 | CSRF and XSS are the same attack class | CSRF forges trusted requests; XSS injects script into trusted content |
| 21 | Deserialization is safe if basic validation exists | Unsafe deserialization can trigger RCE; avoid untrusted object deserialization |
| 22 | Coupling and cohesion both should be high | Prefer low coupling and high cohesion |
| 23 | CMMI levels are not exam-relevant | Know progression from Initial to Optimizing |
| 24 | Developer test completion = user acceptance | Acceptance testing is business/user validation against requirements |
| 25 | Authorization checks are only needed at login | Enforce object-level authorization on every request (IDOR prevention) |
| 26 | SSRF is a client-side issue | SSRF coerces server-side requests to internal/unintended targets |
| # | Trap | Domains |
|---|---|---|
| 1 | "Think like a manager, not a technician." CISSP is a management exam. When two answers are technically correct, choose the one that addresses governance, risk, policy, or process over the technical fix. | ALL |
| 2 | Human safety is ALWAYS the first priority. Before recovering systems, saving evidence, or containing the threat — protect people. | D1, D7 |
| 3 | Data Owner = business executive. ALWAYS. Not IT, not DBA, not CISO. The owner is the person who classifies the data and approves access. Appears in D1, D2, D5. | D1, D2, D5 |
| 4 | Compliance ≠ Security. You can be compliant and still get breached. Compliance is the floor. Security goes beyond. | D1, D6 |
| 5 | Non-repudiation requires digital signatures. Not encryption, not hashing, not HMAC. Only asymmetric digital signatures provide non-repudiation. Appears in D3, D5. | D3, D5 |
| 6 | Least privilege ≠ Need-to-know. LP = what you CAN DO (permissions). NtK = what you CAN SEE (information). Both needed together. | D1, D5, D7 |
| 7 | "FIRST" / "BEST" / "MOST IMPORTANT" — Read these words very carefully. They narrow the answer to exactly ONE choice. Eliminate good-but-not-best answers. | ALL |
| 8 | Legal liability cannot be transferred. You can transfer financial risk (insurance) but you REMAIN legally accountable. Risk transfer ≠ accountability transfer. | D1, D2 |
| 9 | The answer CISSP wants is the PROCESS answer, not the product. "Implement a risk assessment" beats "buy a firewall." "Develop a policy" beats "install antivirus." | ALL |
| 10 | When in doubt, pick the answer that reduces risk to the organisation. Not the cheapest, not the most technical, not the fastest — the one that best manages risk within business context. | ALL |