CompTIA Security+ SY0-701

Security+ asks you to classify any control into one of four families and to map it back to a framework. The exam loves drag-and-drop PBQs that hand you 10 controls and ask you to bucket them.

• Technical controls: implemented through technology — firewalls, encryption, intrusion detection systems, antivirus. Also called "logical" controls.
• Managerial controls: administrative — policies, risk assessments, security awareness programs, background checks. The paperwork layer.
• Operational controls: carried out by people — change management, incident response procedures, security guard patrols, awareness training delivery.
• Physical controls: protect the tangible environment — locks, mantraps, surveillance cameras, fencing, badge readers, server-room cages.
• NIST Cybersecurity Framework (CSF): five functions — Identify, Protect, Detect, Respond, Recover. Voluntary US framework, widely adopted by critical-infrastructure sectors.
• ISO/IEC 27001: international standard for an Information Security Management System (ISMS) — certifiable, requires Statement of Applicability + Annex A controls.
• CIS Critical Security Controls: prioritised set of 18 defensive actions mapping to common attack patterns. CIS v8 is the current edition.

Scenario: a SOC analyst is auditing a new office build-out and must classify 6 controls in ServiceNow GRC for the ISO 27001 audit. Response: step 1 the badge-reader at the entrance → physical. Step 2 the AUP that every employee signs → managerial. Step 3 the SIEM correlation rule for failed logins → technical. Step 4 the daily backup-verification checklist run by ops → operational. Step 5 map each to ISO 27001 Annex A (A.7 physical, A.5 organisational, A.8 technological, A.5 organisational). Step 6 export the matrix as evidence for the auditor.

The CIA triad is the vocabulary the exam uses to describe every breach scenario. AAA + non-repudiation extend it to the access-control side. Memorise which CIA leg each control protects.

• Confidentiality: data is accessible only to authorised individuals. Enforced through encryption (AES-256), access control lists, data masking, classification labels.
• Integrity: data has not been altered in an unauthorised manner. Verified through hashing (SHA-256), digital signatures, file-integrity monitors like Tripwire.
• Availability: systems and data are accessible when needed. Achieved through redundancy, failover clustering, load-balancing, capacity planning, and DDoS mitigation.
• Authentication: verifies identity. Factors: something you know (password), have (hardware token), are (biometric), do (signature dynamics), where (location).
• Authorisation: determines what an authenticated user may access. Implemented via RBAC, ABAC, ACLs, group memberships.
• Accounting (auditing): tracks user activity for compliance and forensics. Logged via SIEM, syslog, Windows Event Log, cloud audit trails like CloudTrail.
• Non-repudiation: sender cannot deny having sent a message. Enforced through digital signatures (private-key signed hash) and tamper-evident audit logs.

Scenario: an attacker exfiltrates a customer database. The SOC must classify the breach across CIA. Response: step 1 exfiltration breaks confidentiality — data left the boundary unauthorised. Step 2 if the attacker also modified records before exfil, integrity is also broken; verify with sha256sum against the last known-good backup. Step 3 if a ransomware payload also encrypted production, availability is impacted. Step 4 pull the Splunk audit trail and the WAF logs to reconstruct who did what (accounting) — non-repudiation requires that the WAF logs are signed and tamper-evident.

SY0-701 expects you to match an attack pattern to the most likely threat actor. The taxonomy drives every later module — threat-informed defence picks controls based on who is most likely to attack you.

• Nation-state actors: government-sponsored, substantial resources, target critical infrastructure, IP, foreign governments. Run Advanced Persistent Threats (APTs) — long-dwell, low-noise campaigns.
• Organised crime: financially motivated. Ransomware-as-a-service operators (LockBit, BlackCat), business email compromise (BEC) rings, large-scale credit-card data theft.
• Hacktivists: ideologically driven. DDoS attacks, website defacements, doxing leaks. Anonymous-style collectives + lone wolves with a cause.
• Insider threats: current/former employees, contractors, partners. Two flavours: malicious (disgruntled, data theft on exit) and unintentional (clicked phish, lost laptop).
• Script kiddies / unskilled attackers: use public exploits + pre-built tools (Metasploit, off-the-shelf RAT). Low sophistication, high volume.
• Shadow IT & unintentional internal: not adversaries per se but a major risk source — staff using unsanctioned SaaS, personal devices, public AI tools with company data.
• Attack vectors & surfaces: message-based (phishing email/SMS), image/file-based, voice (vishing), removable media (USB drops), supply-chain (compromised vendor).

Scenario: a defence contractor sees stealthy credential theft over 8 months, exfiltration in small encrypted chunks to a CDN, no ransomware. Response: step 1 profile matches a nation-state APT — long dwell, low noise, IP focus. Step 2 pivot the Splunk hunt to MITRE ATT&CK techniques aligned to APT groups (T1078 Valid Accounts, T1071 Application Layer Protocol). Step 3 escalate to FBI/CISA via the ISAC channel — DIB sector is treaty-protected. Step 4 contrast with a noisy ransomware hit (organised-crime profile) where speed + extortion beats stealth.

Cryptography is the most-failed Security+ topic. The exam tests algorithm selection — given a use case, pick the right primitive and parameters. Memorise the matrix cold.

• Symmetric encryption: single shared key. AES-128/256 for bulk data, modes GCM (authenticated) preferred over CBC. Fast — used for data at rest + bulk TLS payload after handshake.
• Asymmetric encryption: key pair (public/private). RSA-2048/3072 classical, ECDSA P-256 / Ed25519 elliptic-curve (smaller keys, same strength). Used for key exchange + digital signatures, not bulk encryption.
• Hashing: one-way fixed-size digest. SHA-256 for integrity; MD5 + SHA-1 deprecated (collision attacks). Password hashing requires a slow function — bcrypt, scrypt, or Argon2id with a unique salt per password.
• Digital signatures: hash the message → encrypt the hash with the sender's private key. Recipient decrypts the hash with the sender's public key + rehashes the message — match = authentic + untampered + non-repudiable.
• Certificates & PKI: X.509 certificate binds a public key to an identity. Signed by a Certificate Authority (CA) at the root of a trust chain. Revocation via CRL or OCSP.
• Key exchange: Diffie-Hellman (DH) for classical, ECDHE (Elliptic-Curve DH Ephemeral) for modern TLS 1.3 forward secrecy.
• HMAC: keyed-hash message authentication. Used in API request signing (AWS SigV4) and message-integrity protocols.

Scenario: a developer must secure four use cases for a fintech app. Response: step 1 sign the software release for tamper-evidence → RSA-3072 or ECDSA P-256 private key; publish the public key on the website. Step 2 encrypt customer PII at rest in PostgreSQL → AES-256-GCM with keys held in AWS KMS. Step 3 secure the TLS 1.3 handshake → X25519 + ChaCha20-Poly1305 cipher suite (forward secrecy). Step 4 hash user passwords for the auth table → Argon2id with per-user salt, never SHA-256 alone.

Security+ expects you to identify a malware family from a one-line indicator description. Memorise the propagation, persistence, and detection profile of each type.

• Ransomware: encrypts the victim's files and demands payment. Modern double-extortion variants also exfiltrate data and threaten public disclosure. Triage = isolate, identify variant via ID Ransomware, restore from offline backup.
• Trojans: disguised as legitimate software to trick execution. Often install a backdoor for remote access (RAT) and harvest credentials.
• Rootkits: operate at the kernel or firmware level to hide presence from security tools. Detection requires offline boot scanning or hardware-rooted attestation.
• Spyware: covertly monitors user activity — keystrokes, screenshots, browsing history. Often bundled with adware or commercial stalkerware.
• Worms: self-replicating across the network without user interaction. Exploit unpatched services (e.g., WannaCry on SMBv1 / EternalBlue). Containment = network segmentation + immediate patching.
• Fileless malware: resides entirely in memory, leverages legitimate system tools (PowerShell, WMI, mshta). Traditional AV misses it; EDR + behavioural detection is required.
• Indicators of Compromise (IoCs): file hashes, IP addresses, domain names, registry mods, unusual process trees. Shared via STIX/TAXII feeds for collective defence.

Scenario: a SOC analyst sees a PowerShell.exe process spawned by winword.exe reaching out to 185.x.x.x on port 443 — no file dropped to disk. Response: step 1 classify as fileless malware in Splunk + tag the CrowdStrike EDR alert as confirmed. Step 2 contain by isolating the host with the EDR's network-quarantine action. Step 3 collect IoCs (parent-child process tree, destination IP, PowerShell command line) into MISP and push to the team's threat-intel feed. Step 4 document the ticket in ServiceNow with NIST 800-61 phase tags.

Phishing is the single most common breach origin in Verizon DBIR year after year. Security+ tests not just the name of each technique but the right detective + corrective controls to deploy.

• Phishing: fraudulent email impersonating a trusted entity. Spear phishing = targeted to one person; whaling = targets executives; clone phishing = duplicates a real prior message with malicious link swapped in.
• Vishing: voice phishing over phone, often with spoofed caller ID — impersonates IT support, banks, IRS. AI voice-cloning has made this dramatically harder to detect since 2024.
• Smishing: SMS-delivered phishing, typically with a shortened URL leading to a credential-harvesting page. Carrier reputation filtering is the primary defence.
• Pretexting: fabricated scenario to justify the ask — e.g., posing as an auditor requesting employee records, or as IT support claiming a "ticket".
• Baiting: physical lure — USB drives labelled "Salary 2026" dropped in the parking lot; or digital "free movie download" links delivering malware.
• Watering-hole attacks: compromise a website frequently visited by a target group + inject malicious code. Higher-skill technique, often used by APTs.
• Typosquatting / homograph: register lookalike domains (g00gle.com) to fool eyeball checks. Defence = browser SafeBrowsing + DNS filtering.
• BEC (Business Email Compromise): impersonate CEO/CFO to request wire transfers. Highest financial-impact category in DBIR — defence is process (callback verification on every wire over $X).

Scenario: finance receives an email from "CEO" requesting an urgent $80k wire to a new vendor. Response: step 1 inspect headers — Received-SPF: fail and DKIM=none in the raw source visible via Outlook → View Source. Step 2 the reply-to domain is ceo-acmecorp.com not acmecorp.com (typosquat). Step 3 follow the wire-transfer callback policy — phone the CEO at the number in HRIS, not the one in the email. Step 4 report via the phishing-report button to Microsoft Defender for Office 365 and label the thread for awareness training.

SY0-701 tests application-layer attacks against the OWASP Top 10 plus network-layer attacks like DDoS and DNS poisoning. For each attack, know the mitigation a developer or network engineer would actually deploy.

• SQL injection (SQLi): malicious SQL inserted into input fields to manipulate the backend database. Defence: parameterised queries (prepared statements), stored procedures, ORM with bound parameters. WAF as defence-in-depth.
• Cross-site scripting (XSS): inject scripts into pages viewed by other users (reflected, stored, DOM-based). Defence: input validation + context-aware output encoding + Content-Security-Policy header.
• Cross-site request forgery (CSRF): trick an authenticated user's browser into executing actions on the app. Defence: anti-CSRF tokens, SameSite=Strict cookies, requiring re-auth for sensitive actions.
• Buffer overflow: write data past allocated memory, enabling code execution. Defence: ASLR (Address Space Layout Randomisation), DEP (Data Execution Prevention), stack canaries, safe languages (Rust/Go).
• Directory traversal / path traversal: manipulate paths with ../ to access files outside the intended directory. Defence: canonicalise paths server-side + reject any input containing ...
• DDoS (Distributed Denial of Service): botnet floods the target with traffic. Mitigation: upstream scrubbing (Cloudflare, AWS Shield Advanced), anycast distribution, rate-limiting.
• DNS poisoning / cache poisoning: corrupt resolver cache entries to redirect users. Defence: DNSSEC validation + DNS-over-HTTPS / DNS-over-TLS.

Scenario: a SOC analyst sees a 500x increase in UNION SELECT patterns in WAF logs targeting /api/search. Response: step 1 classify as SQL injection probing in Splunk + correlate the source IPs against threat-intel. Step 2 contain by enabling a blocking WAF rule (the rule was previously in detect-only mode) — e.g., iptables -A INPUT -s 185.x.x.x -j DROP as a stop-gap on the LB. Step 3 escalate to the dev team to confirm the endpoint uses parameterised queries — pull the source from git and grep for raw string concatenation. Step 4 document in ServiceNow as an incident + open a remediation Jira if the code is vulnerable.

Vulnerability management is a continuous lifecycle, not a one-shot scan. Security+ tests the scan-assess-test-deploy-verify loop plus CVE/CVSS literacy and the difference between pen tests, vuln scans, and bug bounties.

• Vulnerability scanning: automated tools — Nessus, Qualys, OpenVAS, Rapid7 InsightVM — discover known vulnerabilities across network assets, applications, and configurations. Credentialed scans give deeper visibility than unauthenticated.
• CVE (Common Vulnerabilities and Exposures): the unique-identifier system maintained by MITRE — e.g., CVE-2024-6387. Every published vulnerability gets one.
• CVSS (Common Vulnerability Scoring System): 0-10 severity score. CVSS v3.1 base metrics — attack vector (network/local), complexity, privileges required, user interaction, scope, and CIA impacts. v4 adds threat + environmental refinements.
• Patch management lifecycle: scan → assess (CVSS + asset criticality) → test in staging → deploy in waves → verify with rescan. Critical patches under SLA (e.g., 14 days), normal 30-90 days.
• Penetration testing: simulated attack to validate exploitability. Black-box (no prior knowledge), white-box (full knowledge), gray-box (partial). Scoped by Rules of Engagement.
• Bug bounty programs: crowdsourced vulnerability discovery — pay-per-finding to external researchers via HackerOne, Bugcrowd, Intigriti.
• Zero-day vulnerabilities: no available patch when exploited. Defence-in-depth + virtual patching (WAF rules, IPS signatures) buys time until a vendor fix lands.

Scenario: the weekly Nessus scan flags CVE-2024-6387 (regreSSHion, CVSS 8.1) on 47 production hosts. Response: step 1 triage in Tenable.io — filter by asset criticality + exposure (internet-facing first). Step 2 apply the vendor patch via ansible-playbook patch-sshd.yml against the internet-facing 8 hosts within the 14-day critical SLA. Step 3 deploy to the remaining 39 internal hosts in two waves over 7 days, with rollback procedures via ansible tags. Step 4 rescan with Nessus + document closure in ServiceNow with the patch ticket linked.

Architecture exists to shrink the blast radius. Security+ tests segmentation patterns, Zero Trust principles, and the difference between perimeter-trust and identity-trust models.

• DMZ (Demilitarised Zone): isolated network segment for public-facing services (web, mail relay), sandwiched between two firewalls — external and internal — so a compromise of a web server doesn't reach internal LAN.
• Network segmentation: divides the internal network into isolated zones (HR, finance, dev, IoT). Attacker who breaches one segment cannot freely move laterally.
• Zero Trust: architectural philosophy — "never trust, always verify". Every user, device, and flow is authenticated + authorised regardless of network location. Implemented via identity-aware proxies, BeyondCorp, ZTNA.
• Microsegmentation: extends segmentation to the workload level — granular policy per VM or container. Implemented via VMware NSX, Illumio, or cloud-native security groups.
• VPN: encrypted tunnel — site-to-site (IPsec) for office-to-office, client (TLS-based, SSL VPN) for remote workers. Increasingly being replaced by ZTNA.
• NAC (Network Access Control): enforces security-posture checks (patch level, AV status, EDR running) before granting LAN access. Quarantine VLAN for non-compliant.
• SDN (Software-Defined Networking): separates control plane from data plane → centralised, programmable policy enforcement.

Scenario: a healthcare provider must redesign a flat network to limit ransomware blast radius post-incident. Response: step 1 place public web in a DMZ with WAF + IPS on the north-south firewalls. Step 2 segment internal into per-department VLANs (clinical, finance, HR, IoT/biomed) with inter-VLAN ACLs deny-by-default. Step 3 deploy microsegmentation on the clinical workload tier so that an infected workstation cannot reach the EHR database — iptables hostfirewalls + cloud security groups. Step 4 add ZTNA in front of admin consoles so engineering laptops authenticate per-session via Okta + device posture.

The cloud shared-responsibility model is one of the most-tested topics in SY0-701. Memorise which party owns what across IaaS, PaaS, and SaaS — the exam loves edge cases like "who patches the database engine in RDS?"

• Shared responsibility model: in IaaS the provider secures the physical infrastructure + hypervisor; the customer manages OS, apps, data, IAM. In PaaS the provider also handles the runtime + middleware. In SaaS the customer is responsible mostly for data + access control.
• CASB (Cloud Access Security Broker): sits between users and cloud services to enforce policy — visibility into shadow IT, DLP for cloud uploads, threat protection. Inline or API-based.
• Hypervisor security: Type 1 (bare-metal, ESXi/Hyper-V/Xen) is generally more secure than Type 2 (hosted, VirtualBox/VMware Workstation). VM escape vulnerabilities remain the biggest risk class.
• Container security: scan images for vulns (trivy, grype), enforce least-privilege at runtime (drop capabilities, read-only rootfs), isolate via namespaces + cgroups. Never run privileged containers in production.
• Serverless: attack surface shifts to the application code + dependencies. Secrets management, IAM least-privilege per function, and dependency scanning become primary controls.
• Cloud IAM: roles + policies, MFA enforcement, no long-lived static credentials. Use role assumption (AWS STS, GCP service-account impersonation) instead of access keys.
• Cloud-native security tools: AWS GuardDuty, Azure Defender, GCP Security Command Center. SCC + CSPM tools (Wiz, Prisma Cloud) for posture management.

Scenario: a fintech is moving from on-prem to AWS and asks who is responsible for what. Response: step 1 EC2 instances (IaaS) — AWS owns the hypervisor + physical; customer owns OS patching, IAM, app config. Step 2 RDS (PaaS) — AWS patches the DB engine + OS; customer manages schema, queries, IAM, encryption keys (KMS). Step 3 S3 (PaaS-storage) — customer manages bucket policy + object encryption + public-access blocks. Step 4 enable AWS Config + GuardDuty + IAM Access Analyzer for continuous posture validation, with findings funneled to Splunk via EventBridge.

Integrating security into the SDLC is cheaper than patching post-deploy. SY0-701 tests where in the lifecycle each control belongs and the difference between SAST, DAST, IAST, and SCA.

• Secure SDLC phases: requirements (define security stories) → design (threat modelling, STRIDE) → implement (secure coding standards) → test (SAST, DAST, code review) → deploy (signed artefacts) → operate (monitoring, IR).
• OWASP Top 10: industry standard list of the most critical web app risks — broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable components, identification failures, integrity failures, logging failures, SSRF.
• Input validation: allow-list rather than deny-list. Validate length, type, format, range. Reject untrusted input at the boundary.
• SAST (Static Application Security Testing): analyses source code without executing — SonarQube, Semgrep, Checkmarx. Runs early in CI on every PR.
• DAST (Dynamic Application Security Testing): tests the running app by simulating attacks — OWASP ZAP, Burp Suite. Runs against staging environments.
• Code review: peer review with a security checklist; mandatory for changes to auth, crypto, payment, or PII handling.
• DevSecOps: embed security into CI/CD — SAST on PR, SCA (Software Composition Analysis) for dependencies, container image scanning at build, infrastructure-as-code scanning (tfsec, checkov) before terraform apply.
• API security: OAuth 2.0 / OIDC for auth, API keys + HMAC for service-to-service, rate limiting, input validation, schema validation (OpenAPI), proper error handling that doesn't leak.

Scenario: a dev team needs to shift security left in their GitHub Actions pipeline. Response: step 1 add Semgrep SAST as a required check on every PR — block merge on high-severity findings. Step 2 add Trivy container image scan in the build stage — fail the pipeline on critical CVEs. Step 3 run OWASP ZAP baseline scan against the staging deploy nightly + push findings to Jira. Step 4 instrument Datadog RUM + APM in production for runtime detection of injection patterns, with alerts routed to PagerDuty.

Availability is the often-forgotten CIA leg. Security+ tests RAID levels, backup strategies, RPO/RTO definitions, and the spectrum of DR sites from cold to hot.

• RAID levels: RAID 1 mirrors across 2 disks; RAID 5 stripes with distributed parity (3+ disks, survives 1 disk loss); RAID 6 double parity (survives 2 disk loss); RAID 10 = 1+0, both performance and redundancy.
• Backup types: Full (complete copy), Incremental (data changed since last backup of any type — fast to back up, slow to restore), Differential (data changed since last full — slower backup, faster restore).
• 3-2-1 rule: 3 copies of data, on 2 different media, with 1 offsite. Modern variant 3-2-1-1-0: also 1 offline/immutable copy + 0 errors on verification.
• RPO (Recovery Point Objective): maximum acceptable data loss measured in time. RPO = 1 hour → back up at least hourly. Drives backup frequency.
• RTO (Recovery Time Objective): maximum acceptable downtime. RTO = 4 hours → recovery procedures must restore service within 4h. Drives DR site spend.
• DR site spectrum: Hot site = fully operational duplicate, near-zero RTO; Warm site = partially equipped, hours-to-days; Cold site = empty facility, days-to-weeks; Cloud DR = pilot light / warm standby / active-active in another region.
• High availability vs DR: HA = within-region redundancy (multi-AZ, load balancers, clustering). DR = cross-region or cross-site capability. Both are needed; they solve different problems.

Scenario: a fintech with an RPO of 15 min + RTO of 1 hour needs a DR strategy. Response: step 1 deploy primary in AWS eu-west-1 with multi-AZ RDS for HA (sub-second failover). Step 2 replicate RDS via cross-region read replica to eu-central-1 (replication lag normally <1 min, well inside the 15-min RPO). Step 3 stage a warm-standby in eu-central-1 — scaled-down ASG + DNS failover via Route 53 health checks for the 1-hour RTO. Step 4 run a quarterly DR drill: failover, verify, measure actual recovery time, document in the BCP.

Identity is the new perimeter. Security+ asks you to pick the right access-control model, distinguish authentication factors, and identify when PAM applies.

• Multi-Factor Authentication (MFA): combine two or more factors — something you know (password), something you have (hardware token, smartphone TOTP), something you are (fingerprint, face). FIDO2 / WebAuthn hardware keys are phishing-resistant; SMS is not.
• Single Sign-On (SSO): authenticate once, access multiple apps. Implemented via SAML, OAuth 2.0, or OpenID Connect (OIDC). Centralises auth + reduces password fatigue.
• RBAC (Role-Based Access Control): permissions assigned to roles ("network-admin", "help-desk"); users assigned to roles. Simplest model at scale.
• ABAC (Attribute-Based Access Control): decisions based on attributes of user, resource, action, environment — e.g., "allow access only from managed devices during business hours". More flexible than RBAC.
• MAC vs DAC: Mandatory Access Control (MAC) uses system-enforced labels (TS, S, C, U) — military model. Discretionary Access Control (DAC) lets the owner set permissions — typical Unix/Windows ACLs.
• Least privilege: users and processes get the minimum permissions necessary. Enforced via role boundaries, JIT elevation, and regular access reviews.
• Federation: identity established by one organisation is trusted by another via SAML/OIDC. The basis of "Sign in with Google", workforce SSO into vendor SaaS.
• PAM (Privileged Access Management): additional controls for high-risk accounts — credential vaulting (CyberArk, HashiCorp Vault), session recording, just-in-time access elevation, MFA enforcement.

Scenario: a SOC analyst sees a privileged account being used at 3am from an unmanaged device. Response: step 1 investigate the session in Splunk + the PAM session recording in CyberArk. Step 2 contain via okta admin-revoke-session + disable the account in Active Directory. Step 3 require FIDO2 hardware key MFA for all admin accounts going forward + apply an ABAC policy: "privileged actions only from managed corp devices, business hours unless break-glass approved". Step 4 document the IR ticket in ServiceNow + run an access review on all peer admin accounts.

SY0-701 expects you to name the right tool for a defensive job — and know when SIEM, SOAR, EDR, and XDR overlap or replace each other.

• Firewalls: filter traffic on rules. Next-Generation Firewalls (NGFWs) add deep packet inspection, application awareness, identity-aware policy, and threat-intel integration — Palo Alto, Cisco Firepower, Fortinet FortiGate.
• IDS vs IPS: Intrusion Detection Systems passively alert; Intrusion Prevention Systems sit inline and actively block. Signature-based catches known threats; anomaly-based catches the unknown but flags more false positives.
• SIEM (Security Information & Event Management): aggregates logs from diverse sources, correlates events, alerts on detection rules + UEBA. Splunk, Microsoft Sentinel, Elastic Security, QRadar.
• SOAR (Security Orchestration, Automation & Response): automates IR playbooks — block IPs, quarantine endpoints, enrich alerts with threat intel. Cortex XSOAR, Splunk SOAR, Tines.
• EDR / XDR: Endpoint Detection & Response runs on endpoints; eXtended DR correlates endpoints + network + identity + email signals. CrowdStrike Falcon, SentinelOne, Defender XDR.
• Proxy servers: intermediaries that inspect, filter, log web traffic. Forward proxy for outbound, reverse proxy in front of services.
• WAF (Web Application Firewall): protects web apps from SQLi, XSS, OWASP Top 10 attacks. Cloudflare, AWS WAF, F5 ASM.
• DLP (Data Loss Prevention): monitors and controls data in motion (network DLP), at rest (storage DLP), and in use (endpoint DLP). Prevents PII / PCI / IP exfiltration through email, USB, cloud uploads.

Scenario: a SOC analyst gets a SIEM alert: "100 failed logins on vpn-edge-01 in 60 seconds". Response: step 1 investigate in Splunk — correlate to source IP + user enumeration pattern. Step 2 the SOAR playbook auto-blocks the source IP at the firewall (iptables -A INPUT -s 185.x.x.x -j DROP), pushes an enrichment lookup to VirusTotal + AbuseIPDB, and creates a Jira ticket. Step 3 EDR (CrowdStrike) is queried for any successful auth from that IP — none found. Step 4 document the case in ServiceNow as a contained brute-force attempt + add the IP to the watchlist.

The NIST 800-61 IR lifecycle is the framework you will be tested against. Know each phase, the artefacts it produces, and the typical pitfalls.

• Preparation: build the IR team, define communication plans + escalation tree, deploy monitoring (SIEM, EDR), develop playbooks for ransomware, phishing, data breach, insider threat. Tabletop exercises validate the plan.
• Detection & Analysis: triage alerts from SIEM, IDS/IPS, EDR, user reports. Determine scope (single host vs lateral spread), classify severity, declare an incident.
• Containment: two phases — short-term isolates affected systems (network quarantine, disable accounts); long-term applies temporary fixes while preserving evidence for forensics.
• Eradication: remove root cause — delete malware, close exploited vulns, disable compromised accounts, rotate credentials/keys. The exam loves the "containment vs eradication" distinction.
• Recovery: restore systems from clean backups or rebuilt images; monitor for reinfection; gradually return to normal operations. RTO clock stops here.
• Lessons Learned (post-incident review): document timeline, what worked, what failed; feed improvements back into Preparation. PIR within 2 weeks of close.
• Playbooks: step-by-step procedures for specific incident types — ransomware, BEC, lost laptop, malicious insider, credential stuffing. SOAR encodes playbooks as automation.

Scenario: a SOC analyst receives a phishing-credential-theft alert. Response: Preparation — block sender + push EDR signature for the dropper already done; Microsoft 365 phishing playbook in Tines is ready. Detection — Defender for Office 365 alert correlated with anomalous logon from new geography in Sentinel. Containment — revoke all session tokens in Entra ID, force MFA re-enrolment, disable the account temporarily. Eradication + Recovery — sandboxed payload analysis in CAPE Sandbox, password reset, account re-enabled with hardware-key MFA. Lessons Learned — PIR documented in Confluence; awareness training updated with this exact phishing template.

Digital forensics turns IR output into legally defensible evidence. Security+ tests chain-of-custody, the order of volatility, and which tool fits which artefact.

• Chain of custody: documented record tracking evidence from collection through analysis to court — who handled it, when, what was done. Any break can render evidence inadmissible.
• Order of volatility: CPU registers + cache → RAM → process state + routing tables → temporary files on disk → persistent storage → archived/offline backups. Capture in that order.
• Disk imaging: bit-for-bit copy using FTK Imager, dd, or Guymager. Write-blockers (hardware or software) prevent any modification to the original.
• Hashing for integrity: after imaging, compute SHA-256 of both source and image — record both in the chain-of-custody form. Any mismatch invalidates the evidence.
• Memory forensics: volatile RAM analysis via Volatility — find running processes, network connections, encryption keys, fileless malware artefacts that never touched disk.
• Log analysis: examine OS, app, firewall, auth logs to reconstruct timelines. Centralised logging (syslog, Windows Event Forwarding, Splunk) is essential for correlation.
• Network forensics: packet captures (Wireshark, tcpdump), NetFlow data, full-packet-capture appliances. Reconstruct sessions to prove what data left the boundary.
• SCAP (Security Content Automation Protocol): family of specifications (CVE, CVSS, CPE, OVAL) standardising vulnerability + compliance reporting. Backs DISA STIGs, CIS Benchmarks scanning.
• eDiscovery: identification, collection, and production of electronic records for legal proceedings. Distinct from forensics — broader, often civil litigation.

Scenario: an executive's laptop is suspected of harbouring insider-threat evidence. Response: step 1 seize the laptop powered on; capture RAM first with Magnet RAM Capture while it's still running (volatility order). Step 2 shut down via pull-the-plug for desktops or normal shutdown for laptops with disk encryption; attach to a hardware write-blocker. Step 3 create a forensic image with FTK Imager + record SHA-256 of source and image. Step 4 store the original in a tamper-evident bag with the chain-of-custody form; do all analysis on the image only in Splunk + Volatility + Autopsy.

Governance is the framework that makes security repeatable across an organisation. Security+ tests the policy-standard-procedure-guideline hierarchy and the difference between internal + external audits.

• Policies: high-level management intent — e.g., an Acceptable Use Policy, Information Security Policy, Data Classification Policy. Approved by executive leadership, reviewed annually.
• Standards: mandatory requirements that implement policies with specificity — e.g., "all data at rest encrypted with AES-256", "password length ≥ 14 chars".
• Procedures: detailed step-by-step instructions — e.g., the exact 12-step process for onboarding a new employee's access in HRIS + Active Directory + SaaS apps.
• Guidelines: recommended (non-mandatory) practices — e.g., suggested phishing-reporting workflow. Provide flexibility in implementation.
• Regulatory compliance: meeting legal/industry requirements based on data type, industry, and geography. Includes GDPR (EU), HIPAA (US healthcare), PCI-DSS (cards), SOX (US public companies), CCPA (California).
• Audits: internal audits verify controls operate as designed; external (third-party) audits provide independent assurance. Findings tracked in audit reports, remediated by risk-based priority.
• Governance structures: board of directors, security steering committee, CISO, data protection officer (GDPR), risk committee. Clear roles via a RACI matrix.
• Change management: structured process for any change to a production system — request, approval, implementation, verification, rollback plan. Often coordinated through ServiceNow CAB workflow.

Scenario: a fintech CISO is building the governance hierarchy for SOC 2 Type II readiness. Response: step 1 draft the top-level Information Security Policy + Acceptable Use Policy, approved by the board, published in Confluence. Step 2 write supporting standards for encryption (AES-256 at rest, TLS 1.2+ in transit), password complexity, MFA, logging retention. Step 3 document procedures for joiner-mover-leaver, vulnerability response, IR. Step 4 the auditor reviews against the SOC 2 Trust Service Criteria + samples evidence in ServiceNow CAB tickets. Gaps become remediation items with assigned owners and SLAs.

Risk management is the engine that prioritises every security spend. SY0-701 tests the qualitative vs quantitative distinction, the ALE formula, and the four risk-response strategies.

• Qualitative risk assessment: descriptive scales (high/medium/low). Risk matrix maps likelihood against impact. Fast, subjective, used early in maturity.
• Quantitative risk assessment: monetary values. SLE (Single Loss Expectancy) × ARO (Annualised Rate of Occurrence) = ALE (Annualised Loss Expectancy). Drives the cost-benefit analysis of controls.
• Risk register: centralised document tracking all identified risks — owner, severity, likelihood, treatment plan, status. Reviewed quarterly by the risk committee.
• Business Impact Analysis (BIA): identifies critical business functions, quantifies impact of disruption, sets recovery priorities (RPO, RTO, MTTR, MTBF). Feeds the BCP.
• Risk-response strategies: Mitigate (apply controls to reduce), Accept (within tolerance, sign-off), Avoid (eliminate the activity), Transfer (insurance, contract clauses to a 3rd party).
• Risk = likelihood × impact: NOT "vulnerability + threat". The exam-canonical definition matters because question wording probes it directly.
• Key Risk Indicators (KRIs): measurable metrics that signal increasing risk — failed phishing-simulation rate, mean time to patch, % systems out of SLA, third-party score trend.
• Third-party / supply-chain risk: evaluate vendor security via questionnaires (SIG, CAIQ), SOC 2 reports, ISO 27001 certificates, right-to-audit clauses. Continuous monitoring via tools like SecurityScorecard, BitSight.

Scenario: a CISO must justify spending $80k on a DLP rollout to the CFO. Response: step 1 quantitative model — a data-breach event costs SLE = $400k (regulatory fines + IR + notification + brand). Step 2 ARO without DLP = 0.5/year; ALE = 400k × 0.5 = $200k. With DLP, ARO drops to 0.1; ALE_residual = $40k. Step 3 annual benefit = 200k − 40k = $160k. Annualised DLP cost = $80k (licence + ops). Net benefit ≈ $80k/yr → mitigate. Step 4 add the residual risk to the risk register with owner = CISO, review = quarterly. The CFO approves the spend in the next budget cycle.

People remain the most-attacked vector. Security+ tests both the structure of an awareness program and the metrics that prove it works.

• Awareness training: at onboarding + annual refresh + role-specific modules. Executives need BEC awareness; developers need secure-coding; finance needs wire-fraud procedures.
• Security culture: beyond compliance checkboxes — every employee feels ownership for security. Reinforced by leadership messaging, recognition for reporting, no blame for honest mistakes.
• Phishing simulations: controlled exercises sending realistic phish to staff. Measure click rate, reporting rate, time-to-report. Target additional training at the most-susceptible cohorts.
• Acceptable Use Policy (AUP): defines permitted + prohibited uses of org systems — personal use, BYOD, social media, AI tools. Acknowledged on hire + annually.
• Social media policy: addresses oversharing risks — geo-tagged photos, employee directories, project leaks that fuel social engineering or reconnaissance.
• Insider threat program: combines technical monitoring (DLP, UEBA, PAM session recording) with behavioural indicators + non-punitive reporting channels.
• Metrics: phishing-simulation failure rate trend, incident-reporting rate, training-completion rate, mean time to report a phish. Report to the board quarterly.
• Anti-phishing techniques: hover before click, verify sender domain, callback for any financial action, use the report-phish button + reward reporting publicly.

Scenario: a CISO wants to drop the phishing-simulation click rate from 18% to under 5% in 12 months. Response: step 1 baseline the current rate via a KnowBe4 or Hoxhunt campaign across the org. Step 2 deliver role-specific modules — wire-transfer callback for finance, MFA-prompt-bombing for IT, IP-theft scenarios for engineering. Step 3 run monthly simulations of increasing realism; clickers get a 5-min remediation module + manager notification (non-punitive). Step 4 track click-rate + report-rate + mean-time-to-report in Splunk; publish quarterly trend to the board. Reward the top reporters publicly.

Data classification drives encryption, access, retention, and destruction requirements. Security+ tests the major regulations and the data-lifecycle stages.

• Data classification: Public (no harm if disclosed), Private/Internal (limited to org), Confidential (significant harm if exposed), Restricted/Top Secret (strictest controls). Labels drive encryption, ACLs, retention.
• GDPR (General Data Protection Regulation): EU regulation for personal data of EU residents. Right to access + erasure + portability, 72-hour breach notification, DPO requirement, fines up to 4% of global revenue.
• HIPAA (Health Insurance Portability & Accountability Act): US healthcare. Privacy Rule (use + disclosure of PHI) + Security Rule (admin, physical, technical safeguards) + Breach Notification Rule.
• PCI-DSS (Payment Card Industry Data Security Standard): requirements for cardholder data — network segmentation, encryption of CHD in transit + at rest, quarterly ASV scans, annual pen test, no storage of CVV.
• Other regulations: SOX (financial reporting controls, US public companies), CCPA / CPRA (California consumer privacy), LGPD (Brazil), PIPEDA (Canada). Industry-specific: GLBA (US finance), FERPA (US education).
• Data sovereignty: data is subject to the laws of the country where it is stored/processed. Drives cloud-region selection for multinational orgs — EU residents' data should stay in EU regions.
• Data lifecycle: create → store → use → share → archive → destroy. Each stage has compliance + security obligations. Destruction: NIST 800-88 sanitisation — clear, purge, destroy.
• Privacy Impact Assessment (PIA / DPIA): mandatory under GDPR for high-risk processing. Identify data, purpose, risks, mitigations, consultation needs.

Scenario: an EU healthcare SaaS handles PHI + payment cards + EU resident data. Response: step 1 classify data: clinical = Restricted (HIPAA + GDPR Special Category), cardholder = Confidential (PCI-DSS), marketing emails = Private. Step 2 store all EU data in eu-west-1 + eu-central-1 — data sovereignty. Step 3 encrypt PHI with AES-256 at rest in AWS KMS-managed keys + TLS 1.3 in transit; segment cardholder data into a PCI scope VPC with WAF + quarterly ASV scan. Step 4 stand up a 72-hour breach-notification runbook in PagerDuty + appoint a DPO. Document the DPIA in Confluence.