Chapter 4: Security Operations

What you will learn

By the end of this chapter, you will be able to:

• Describe the identity lifecycle: provisioning, account changes, deprovisioning, and account audits
• Compare multifactor authentication (MFA) factors and explain passwordless authentication with FIDO2
• Explain privileged access management (PAM), single sign-on (SSO), and federation
• Recognize identity attacks such as password spraying, brute force, and credential stuffing — and the defenses against each
• Apply access control models in daily operations: RBAC, ABAC, MAC, DAC, and rule-based access control, together with least privilege and separation of duties
• Explain how automation, scripting, and SOAR playbooks improve security operations — and the guardrails they need
• Walk through the incident response process from preparation to lessons learned
• Describe core digital forensics practices: legal hold, chain of custody, order of volatility, imaging, and e-discovery
• Compare monitoring tools: SIEM, SOAR, EDR/XDR, DLP, and IDS/IPS
• Explain vulnerability response: patch management, compensating controls, and exceptions
• Explain how SPF, DKIM, and DMARC protect email
• Describe endpoint and mobile security controls: anti-malware, host firewalls, HIDS/HIPS, allow lists, MDM, sideloading, and jailbreaking

Reading

Security operations is where security stops being theory and becomes daily work. The previous chapters explained what threats exist and how secure systems are designed; this chapter is about running security day after day: creating and removing accounts, watching alerts, patching systems, answering phishing reports, and responding when something goes wrong. Domain 4 is the largest part of the Security+ exam (28%), and it rewards practical thinking. For almost every topic in this chapter, ask yourself two questions: What does the security team actually do here? and What tool or process makes it happen?

Identity and Access Management Operations

Identity is the control plane of modern security. Attackers rarely "break in" through a Hollywood-style exploit; far more often they simply log in with stolen or guessed credentials. That makes the operational side of identity and access management (IAM) — creating accounts correctly, changing them when roles change, and removing them the moment they are no longer needed — one of the highest-value activities in security operations.

Provisioning and deprovisioning. The identity lifecycle has three operational moments that matter most. Provisioning (sometimes called onboarding or account creation) happens when a person joins or a service is deployed: the account is created, given a unique identity, assigned to the correct groups, and granted only the access the role requires. Good provisioning is driven by HR events and role definitions, not by copying the account of "someone who does a similar job" — copying accounts quietly copies their accumulated excess privileges too. Account changes happen when people move teams, get promoted, or take on temporary duties; each change should add the new access and remove the old, because privilege creep — the slow accumulation of rights nobody ever takes away — is one of the most common findings in access reviews. Deprovisioning happens when someone leaves or a contract ends: the account is disabled (and later deleted according to policy), sessions are revoked, tokens and keys are rotated, and any shared secrets the person knew are changed. Deprovisioning must be fast. A disabled-within-minutes leaver account is a control; a leaver account that stays active for three weeks is an incident waiting to happen.

Account audits and permission auditing. Because provisioning is imperfect, organizations periodically review who has access to what. An account audit (also called an access review or recertification) asks managers and system owners to confirm that each account still exists, belongs to a current employee, and holds only appropriate permissions. Audits hunt for specific problems: orphaned accounts (no owner), dormant accounts (not used in 90+ days), shared accounts with no accountability, and excessive privilege (standard users holding admin rights). Permission auditing goes one level deeper, examining the actual rights assigned to accounts and groups rather than just their existence. Both are detective controls: they do not stop bad access from being granted, but they find and correct it before an attacker does.

Password policies. Password policy is the set of rules an organization enforces on passwords: minimum length, complexity requirements, history (how many old passwords are remembered so users cannot reuse them), maximum and minimum age, and lockout settings (how many failed attempts trigger a lockout, and for how long). Modern guidance — and CompTIA's position on the exam — is that length beats complexity: a policy requiring 14+ characters with a password manager and MFA is stronger than an 8-character policy with symbols that forces users to write passwords on sticky notes. Account lockout policy is a balance: lock too fast and attackers can denial-of-service your users by deliberately failing logins; lock too slowly and brute force becomes practical. Policies are enforced technically through directory settings (for example, Group Policy in Active Directory), not by asking users nicely.

Multifactor authentication. MFA requires two or more different kinds of evidence. The factor types are:

A password plus a fingerprint is MFA. A password plus a PIN is not — both are "something you know," so it is single-factor twice. Watch also for MFA fatigue (push bombing): an attacker with a stolen password spams push approvals until the user taps "approve" to make it stop. Defenses include number matching (the user must type a number shown on the login screen into the app), rate limiting pushes, and user training to report unexpected prompts.

Passwordless authentication and FIDO2. Passwordless removes the shared secret entirely. In a FIDO2 flow, the user's device holds a private key that never leaves it; the server stores only the public key. At login, the server sends a challenge, the device signs it after a local unlock (biometric or PIN), and the server verifies the signature. There is no password to phish, reuse, or crack, and because the key pair is scoped to the legitimate site's origin, a look-alike phishing site cannot replay it. Windows Hello, platform passkeys, and roaming hardware security keys are all FIDO2-based examples you should recognize.

Single sign-on and federation. SSO lets a user authenticate once to an identity provider (IdP) and then access many applications without re-entering credentials. SSO is usually built on federation — a trust relationship between the IdP and service providers — using protocols such as SAML (XML-based assertions, common in enterprise web apps), OAuth 2.0 (authorization framework, what "sign in with…" consent screens use), and OpenID Connect (OIDC) (an identity layer on top of OAuth 2.0). Operationally, SSO improves security (fewer passwords, one place to enforce MFA and to disable access) but concentrates risk: the IdP becomes a high-value target and a single point of failure, so it gets the strongest controls in the environment.

Privileged access management. Administrator, root, service, and break-glass accounts are privileged accounts, and PAM is the discipline of controlling them. A PAM solution typically vaults privileged credentials (checking them out for a session, then rotating them automatically afterward), records privileged sessions, enforces just-in-time (JIT) elevation — admin rights granted only for the window of a task, then removed — and alerts on privileged use. The related principle is to eliminate standing privilege: nobody should hold permanent admin rights "just in case." On the exam, PAM pairs naturally with least privilege, password vaulting, and session monitoring.

Identity Attacks and Defenses

Three credential attacks appear constantly on the exam, and telling them apart is a favorite test point:

• Brute force attacks try many passwords against one account. Online brute force is slowed by lockouts and throttling; offline brute force (against a stolen password hash file) is limited only by the attacker's hardware, which is why strong hashing and long passwords matter.
• Password spraying flips the pattern: the attacker tries one or a few common passwords ("Winter2026!", "Company123") against many accounts. Because each account sees only one or two failures, account lockout never triggers. Spraying exploits the statistical certainty that in a large organization, someone chose a weak, seasonal, or company-themed password.
• Credential stuffing uses username/password pairs leaked from other breaches and replays them against your login page, betting that users reuse passwords. The attacker is not guessing at all — the credentials are real, just stolen from somewhere else. Defenses include MFA (the stuffed password alone is not enough), breach-password screening at enrollment and login, bot detection and rate limiting, and user education about reuse.

Defenses overlap but are not interchangeable: lockout policies help against brute force but barely touch spraying; MFA defeats stuffing and most spraying impact; impossible-travel and geolocation alerts catch successful logins from implausible locations; and monitoring for distributed, low-and-slow attempts catches spraying that stays under per-account thresholds.

Access Control Models in Operation

Chapter material on access control design becomes operational here: someone must decide, for every user and resource, which model governs the decision — and then enforce it consistently.

Two enforcement principles cut across every model. Least privilege means every account holds the minimum access needed for its function, for the minimum time needed — enforced through role design, JIT elevation, and regular permission auditing. Separation of duties splits a sensitive process so no single person can complete (or abuse) it alone: the person who creates a vendor should not be the person who approves payment to that vendor; the developer who writes code should not be the only approver who pushes it to production. Separation of duties is a fraud and error control as much as a security one, and it requires collusion to defeat — which is exactly the point. A related concept, job rotation, moves people between roles to expose hidden fraud and cross-train staff.

Real-world example: a hospital uses RBAC so that "nurse," "physician," and "billing clerk" roles map to clinical systems; ABAC rules then refine it — a nurse can open a chart only for patients on their ward (attribute: ward assignment) during their shift (attribute: time); and MAC-style labels protect psychiatric records, which require a specific clearance regardless of role. The models are not rivals; mature environments layer them.

Automation and Orchestration in Security Operations

Security teams face more alerts, assets, and vulnerabilities than humans can handle manually, so operations increasingly run on automation. Automation is a single task performed by a script or tool without human intervention (disable a compromised account, snapshot a VM, enrich an alert with threat-intelligence lookups). Orchestration coordinates many automated tasks across different tools into one workflow: an alert fires, the SIEM creates a case, the SOAR platform looks up the user in the IdP, checks the endpoint in the EDR, opens a ticket, and posts to the team chat — in seconds, the same way every time.

Scripting use cases you should recognize include user provisioning/deprovisioning from HR feeds, enforcing baselines (checking that systems match a configuration standard and remediating drift), rotating keys and certificates, collecting logs and evidence on a schedule, scanning for IOCs (indicators of compromise) across endpoints, and generating compliance reports. Automation shines on tasks that are high-volume, repetitive, well-understood, and time-sensitive — exactly the profile of tier-1 alert triage.

SOAR playbooks (runbooks) encode the response to a recurring situation: "phishing email reported" triggers detonation of the attachment in a sandbox, a search for the same message across all mailboxes, removal of delivered copies, and a block on the sender domain. Guardrails are the safety mechanisms that keep automation from causing the outage it was meant to prevent:

• Approvals for destructive actions — automation may recommend isolating a server, but a human approves isolating a domain controller or production database.
• Scope limits and allow lists — a playbook can only act on assets in its defined scope, never on excluded critical systems.
• Rate limits and circuit breakers — if a playbook starts disabling hundreds of accounts, something is wrong with the playbook, not the workforce; it should stop and escalate.
• Testing in a safe environment first, version control for playbooks, and full logging of every automated action for later review.

The exam also expects the balanced view: automation reduces response time, error rates, and analyst burnout, but it introduces its own risks — a buggy playbook acts at machine speed and machine scale, playbooks need maintenance as the environment changes ("a single point of failure" if everyone depends on one automation platform), and over-automation can deskill the team. The strongest programs automate the predictable and keep humans in the loop for the consequential.

Incident Response

An incident is a confirmed event that threatens confidentiality, integrity, or availability — not every alert, and not every policy violation, but something the organization must actively manage. Incident response (IR) follows a lifecycle; CompTIA uses these phases, in this order:

1. Preparation — before anything happens: write the incident response plan (IRP), assemble the team, buy and configure tools, train staff, and practice. Preparation is a phase, not paperwork; incidents are won or lost here.
2. Detection — an alert, a user report, a threat-intel hit, or an anomaly signals a possible incident. Detection must be declared/triaged: is this an incident, and how severe?
3. Analysis — responders determine scope and impact: which systems, which data, is the attacker still active, what is the root cause so far? Analysis runs through the whole response and drives decisions.
4. Containment — stop the bleeding: isolate affected hosts, disable compromised accounts, block malicious IPs/domains. Short-term containment limits damage now; long-term containment keeps systems running in a safer state while the fix is built. Containment is deliberately before eradication: you do not rebuild a server the attacker is still using as a beachhead.
5. Eradication — remove the threat completely: delete malware, remove persistence mechanisms and attacker accounts, close the exploited vulnerability, rebuild systems where integrity is in doubt.
6. Recovery — return systems to production safely: restore from clean backups, patch, reset credentials, monitor closely for the attacker's return, and formally return operations to normal.
7. Lessons learned — after the dust settles, hold a blameless review: what happened, what worked, what did not, and what changes (controls, detections, playbook updates) will be made. The output is a report and tracked improvements, not blame.

An incident response plan is the governing document: what counts as an incident, severity levels, who is on the incident response team and their roles (incident lead/handler, technical responders, communications, legal, management, HR as needed), escalation paths and call trees, communication rules (including out-of-band channels in case email is compromised), evidence-handling requirements, and when to involve law enforcement or regulators. Related documents include communication plans, stakeholder notification lists, and playbooks for common incident types (ransomware, phishing, DDoS, insider misuse).

Tabletop exercises are discussion-based rehearsals: the team sits around a table and walks through a scenario ("It's 2 a.m. Friday; the EDR just reported encryption behavior on a file server — what do you do first?"), talking through decisions, gaps, and handoffs. They are cheap, safe, and excellent at exposing unclear roles and missing contact information. They differ from functional/simulated exercises (such as red team engagements or live-fire simulations) where actions are actually performed. Organizations also run call-tree tests (can we actually reach everyone?), and lessons from every exercise feed back into preparation — closing the loop.

Real-world example: a midsize retailer detects (via EDR) a workstation beaconing to a known botnet domain. Analysis shows one host infected, no lateral movement yet. Containment: the host is network-isolated but left powered on for forensics. Eradication: the malware and its scheduled-task persistence are removed and the entry point (an outdated, internet-facing plugin) is identified. Recovery: the machine is rebuilt from a clean image, the plugin patched everywhere, credentials on the box reset. Lessons learned: the plugin inventory was incomplete, so asset management and patch SLAs are tightened, and a new detection rule is written for the beacon pattern.

Digital Forensics

Forensics is the disciplined collection and analysis of evidence so that findings are accurate and defensible — in court, in disciplinary proceedings, or before a regulator. Two ideas dominate: preserve the evidence exactly as found, and be able to prove you did.

Order of volatility. Data disappears at different speeds, so collect the most fragile evidence first. The typical order, most volatile to least:

This is why responders often capture memory and network state before imaging the disk, and why "just unplug it" can be the wrong first move — pulling power destroys RAM evidence and any in-memory-only malware or encryption keys.

Acquisition and integrity. A write blocker is a hardware or software device placed between the evidence drive and the forensic workstation that prevents any writes to the source, guaranteeing the evidence cannot be altered during imaging. The examiner creates a bit-for-bit forensic image (not a file copy — an exact sector-level duplicate, including deleted data and unallocated space) and then works only on copies of that image, never the original. Hashing proves integrity: the examiner hashes the source (SHA-256 is the modern standard) and the image at acquisition; if the hashes match, the image is a perfect copy. Hashes are re-verified whenever evidence is accessed — if a hash ever changes, the evidence's integrity is in question.

Chain of custody is the documented history of the evidence: who collected it, when, where, how it was stored, and every person who handled it, signed at each transfer. A break in the chain — an undocumented gap where someone could have tampered with the evidence — can make it inadmissible. Evidence is stored in sealed, labeled containers or a controlled evidence locker with restricted, logged access.

Legal hold is a formal directive (usually from legal counsel) requiring that specific data be preserved unchanged because litigation or an investigation is expected. It overrides normal retention and deletion schedules: backups are kept, mailboxes are frozen, and auto-deletion is suspended for the in-scope data. Deleting data under a legal hold (spoliation) carries serious legal consequences. E-discovery is the process built around litigation: identifying, preserving, collecting, processing, and producing electronically stored information (ESI) for legal review.

Data sources for investigations. Responders piece together timelines from many sources, each with strengths:

• Endpoint and application logs — authentication events, process creation, file access; detailed but high-volume.
• Firewall, proxy, and DNS logs — what communicated with what, and when; DNS logs are gold for catching malware domains.
• SIEM dashboards and alerts — correlated events across sources; the fastest way to see an attack's shape, dependent on what was ingested.
• NetFlow / flow records — metadata about conversations (source, destination, ports, bytes) without payload; ideal for spotting exfiltration volumes and beaconing patterns over long periods.
• Packet captures (PCAP) — the actual traffic content; the most definitive source, but storage-heavy and often only kept for short windows or on demand.
• Vulnerability scan output, system images/memory dumps, and mobile device images round out the set, along with mundane but decisive records such as badge/access logs and CCTV.

Monitoring Tools and Alerting

Operations runs on telemetry. The core toolset:

• SIEM (security information and event management) collects logs from across the environment, normalizes and correlates them, applies detection rules and analytics, and presents alerts and dashboards for hunting and reporting. A SIEM is only as good as what it ingests and how well its rules are tuned.
• SOAR (security orchestration, automation, and response) sits on top of detections and executes playbooks, as covered earlier — SIEM finds and correlates, SOAR acts and coordinates.
• EDR (endpoint detection and response) monitors endpoint behavior (processes, file changes, registry, network connections), detects malicious behavior, and lets responders isolate a host, kill a process, or roll back changes. XDR (extended DR) widens that same behavioral approach across endpoints, network, email, identity, and cloud, correlating the telemetry into unified incidents.
• DLP (data loss prevention) identifies sensitive data (by pattern, fingerprint, or classification) in motion, at rest, and in use, and can alert on, block, or encrypt transfers — for example, stopping an email that contains 500 credit card numbers to a personal address.
• IDS/IPS. An IDS detects and alerts; an IPS sits inline and can also block. Detection methods matter: signature-based detection matches traffic against known patterns (fast and precise for known attacks, blind to novel ones); heuristic/behavioral detection models normal behavior and flags deviations or suspicious characteristics (can catch new attacks, at the cost of more false positives). Modern tools combine both, plus reputation and threat-intel feeds.
• SNMP traps are unsolicited notifications sent by network devices (switches, routers, UPSs, printers) to a management system when a predefined event occurs — a link goes down, a temperature threshold is crossed, an unauthorized device is detected. They feed the same monitoring pipeline as logs and alerts.
• Baselines and alerting. Effective alerting starts from a baseline: a profile of what normal looks like (login volumes by hour, typical egress destinations, normal CPU/disk/network ranges). Alerts then fire on meaningful deviation from the baseline, tuned so that analysts trust them. Untuned monitoring produces alert fatigue — thousands of low-quality alerts that train analysts to ignore the console, which is how real incidents hide in plain sight. Good operations teams continuously measure alert precision, retire noisy rules, and enrich alerts with context (asset criticality, user role, threat intel) so the first screen an analyst sees is already a head start.

Vulnerability Response and Patch Management

Vulnerability management finds weaknesses; vulnerability response is the operational discipline of fixing them at scale without breaking the business. The cycle is: scan and identify, prioritize by risk (severity scores like CVSS combined with asset criticality, exposure, and whether the vulnerability is being exploited in the wild), remediate, and verify by rescanning.

Patch management is the main remediation path and a formal process, not a free-for-all: patches are inventoried, tested in a non-production environment, deployed in rings (pilot group first, then broad rollout), and verified, with a rollback plan if something breaks. Mature programs define patch SLAs by severity — for example, critical internet-facing vulnerabilities within days, routine updates on the monthly cycle — and they track compliance, because the patch that was "deployed" but failed silently on 200 machines is a classic audit finding. Emergency (out-of-band) patching exists for actively exploited vulnerabilities, but it still gets expedited testing rather than no testing.

Not everything can be patched. When a fix does not exist, cannot be applied (legacy systems, vendor appliances, operational technology that cannot reboot), or would break a business function, operations turns to compensating controls: measures that reduce the risk to an acceptable level by other means. Examples: placing a vulnerable system behind a firewall rule or IPS virtual patch that blocks the exploit, disabling the vulnerable feature or service, network segmentation to isolate the system, stricter monitoring and alerting on it, or removing its internet exposure. A compensating control must actually address the same risk — "we watch it closely" is weak; "the exploit path is blocked at the IPS and the service is reachable only from the management VLAN" is a control.

Sometimes even that is not possible, and the organization formally accepts the risk through an exception (risk acceptance/exemption): a documented, approved record stating the vulnerability, the business justification, the owner, any partial mitigations, and an expiration date. Exceptions are temporary by design and are reviewed at expiry; an exception register full of permanent, ownerless entries is a red flag for auditors. On the exam, the trio matters: patch it if you can, compensate if you cannot patch, and document an exception with an expiry when you accept the risk.

Email Security: SPF, DKIM, and DMARC

Email remains the top delivery channel for phishing, and three DNS-based standards work together to authenticate it. They answer different questions, and examiners love the distinctions:

Practical reading: SPF alone can be defeated by a look-alike From display, DKIM alone says nothing about which servers may send, and neither stops an attacker who registers a similar domain and authenticates it perfectly. DMARC with a reject policy, properly aligned, is what actually prevents direct spoofing of your domain; organizations typically roll it out gradually (monitor with p=none, then quarantine, then reject) while fixing legitimate senders that fail authentication. These controls pair with secure email gateways, user reporting (the phish button), and the simulated-phishing training from earlier chapters.

Endpoint Security

Endpoints — laptops, desktops, servers — are where users, data, and attackers meet, so they carry layered controls:

• Antivirus / anti-malware detects and removes malicious software using signatures, heuristics, and cloud reputation; modern platforms are behavior-aware and centrally managed. Keep definitions and engines current, and alert on disabled protection — malware's first move is often to kill the AV.
• Host-based firewall controls inbound and outbound connections per device (Windows Defender Firewall, iptables/nftables, pf). It protects the machine even off the corporate network and can restrict applications to approved ports and destinations.
• HIDS/HIPS (host-based intrusion detection/prevention) watch host behavior — system calls, file integrity, log anomalies, privilege escalation attempts. The HIDS alerts; the HIPS can block the action. File integrity monitoring (FIM) of critical system and config files is a classic HIDS function.
• Application allow lists (allowlisting) permit only approved executables/scripts to run and block everything else by default — the inverse of signature-based blocking, and one of the strongest anti-malware controls because unknown malware is simply not on the list. The trade-off is operational effort: every legitimate application and update must be managed. (The weaker inverse, a deny list/blocklist, blocks known-bad items and allows everything else.)
• Supporting controls round out the picture: full-disk encryption, EDR (covered above), disabling unneeded services and ports, secure configuration baselines, and timely patching.

Real-world example: a finance laptop is protected by allowlisting (only the approved accounting suite and browser can execute), a host firewall that denies inbound connections, EDR streaming behavior to the SOC, and disk encryption — so a malicious email attachment fails at three independent points: it cannot execute, its payload's outbound connection is blocked, and the attempt is seen and alerted.

Mobile Security

Phones and tablets hold email, MFA apps, and corporate data, and they leave the building every night. Mobile device management (MDM) — and its broader successor, unified endpoint management (UEM) — is the control platform: it enrolls devices, enforces policy (passcode/biometric requirements, encryption on, OS minimum versions, restrictions on cloud backup or USB), deploys and removes apps, separates work data in a container, locates devices, and can remote-wipe a lost phone or just the corporate container. Deployment models matter operationally: BYOD (employee-owned; lightest touch, privacy-sensitive, container-only control), COPE (company-owned, personally enabled; full management with personal use allowed), COBO/CYOD variants trade control against convenience — the exam may test that the more personal the device's use, the more limited the organization's management rights and wipe scope.

Two risky practices get their own exam attention. Sideloading is installing apps from outside the official app stores (direct APK/IPA files or third-party stores). It bypasses store vetting, code signing checks, and revocation — a primary malware delivery route on mobile. MDM policy typically disables it on managed devices. Jailbreaking (iOS) and rooting (Android) remove the operating system's built-in security restrictions to gain full control of the device. A jailbroken device escapes the sandbox model, can run unsigned code, and undermines every control built on platform integrity, so MDM/MAM checks (attestation, jailbreak detection) should block jailbroken devices from corporate data entirely. Supporting controls include keeping OS and apps patched, requiring device attestation, encrypting in transit with per-app VPN, and educating users about malicious profiles and configuration profiles that can reroute traffic.

Key terms

Exercises

Exercise 1 — Triage a log excerpt and decide on escalation

Scenario. You are the tier-1 analyst on shift. The SIEM shows the following events for the last 15 minutes (all times local):

09:02  AUTH FAIL  user=mscott   src=185.220.x.x  (VPS provider range)  attempt 1 of 1
09:02  AUTH FAIL  user=jhalpert src=185.220.x.x  (VPS provider range)  attempt 1 of 1
09:03  AUTH FAIL  user=pbeesly  src=185.220.x.x  (VPS provider range)  attempt 1 of 1
...    (41 more accounts, one or two failures each, same source, password tried: "Spring2026!")
09:11  AUTH FAIL  user=dschrute src=185.220.x.x  attempt 1 of 1
09:12  AUTH SUCCESS user=kkapoor src=185.220.x.x  (account has VPN + mailbox access)
09:14  MFA PUSH SENT user=kkapoor (no approval yet; second push sent at 09:15)

Steps.

1. Count the distinct accounts targeted and the number of failures per account. Write down what pattern this is (hint: compare with the three identity attacks in this chapter).
2. Explain why the account lockout policy never fired.
3. Decide: is this an incident to escalate now, or a ticket to watch? Justify your decision in two sentences, naming the single event that most changes your answer.
4. List your first three containment actions, in order, and one thing you must not do yet (and why).
5. State what you would check next in the kkapoor account if the MFA push gets approved.

What good looks like. You should identify password spraying (many accounts, one common password, few attempts each), treat the successful login from the hostile source as a likely compromise requiring immediate escalation, prioritize disabling/forcing a reset on kkapoor and blocking the source at the perimeter, and avoid wiping or logging off evidence before the responders capture session and log data.

Exercise 2 — Read email authentication results

Scenario. A user reports an email claiming to be from your CFO asking staff to buy gift cards. The message headers your gateway recorded show:

Authentication-Results: spf=fail (sender IP 203.0.113.87 not in SPF record for example-corp.com)
                       dkim=none (no signature)
                       dmarc=fail (From: ceo@example-corp.com — note the missing "m")

Steps.

1. For each of SPF, DKIM, and DMARC, state in one sentence what the result tells you.
2. Identify the second, independent red flag in the From domain, and explain why SPF/DKIM/DMARC on your own domain cannot prevent this particular trick.
3. Your DMARC policy for example-corp.com is p=none. Explain what that policy does and does not do for mail that fails DMARC, and why a company might still be at p=none temporarily.
4. Recommend two actions: one technical control change and one user-facing action.

What good looks like. SPF fail = the sending server is not authorized for the (look-alike) domain's envelope checks performed; the decisive tell is the spoofed look-alike domain itself, which the attacker can authenticate perfectly for their domain — defenses are gateway detection of look-alike domains, external-sender banners, and user training. p=none is monitor-only: failures are reported, not blocked.

Exercise 3 — Plan a forensic acquisition in the right order

Scenario. At 16:40 a developer reports their workstation behaving strangely; EDR shows an unknown process running in memory and connections to an external IP. The machine is still on and logged in. Legal has authorized a forensic examination. Your toolkit has a memory-imaging tool, a write blocker, a forensic imager, evidence bags/tags, and a camera.

Steps.

1. Write your acquisition plan as a numbered list in the order you would perform it, citing the order of volatility for each placement decision.
2. State exactly where the write blocker goes and at what point in your plan it is attached.
3. Note the two hashes you will compute and when, and what matching results prove.
4. List the first five entries your chain-of-custody form must capture for this workstation.
5. Name one action that would destroy evidence in this scenario, and when (if ever) it becomes acceptable.

What good looks like. Photograph the screen and connections; capture RAM and live network state first (most volatile); then image the disk through the write blocker; hash source and image with SHA-256 and record the match; bag, tag, and log custody from the moment of collection. Pulling the power plug first is the classic error — it destroys the in-memory process and any encryption keys.

Exercise 4 — Decide: patch, compensate, or except

Scenario. A scan finds: (a) a critical, actively exploited vulnerability in the internet-facing VPN appliance — a vendor patch exists; (b) the same class of flaw on a lab-only legacy server that cannot be patched because the vendor is defunct, but the server holds no sensitive data and is reachable only from the engineering VLAN; (c) a medium flaw on a kiosk in the lobby that displays the cafeteria menu, where patching requires a vendor visit scheduled in 45 days.

Steps.

1. For each system, choose the response: patch now, apply compensating controls, or file an exception — and name the specific control(s) for (b).
2. Write the five fields you would require on the exception form for (c), including who signs it.
3. State the SLA you would apply to (a) and the verification step that closes the finding.
4. Explain in two sentences why "we accept the risk forever" is not a valid exception for any of them.

What good looks like. (a) Emergency patch with expedited testing, closed by a rescan. (b) Compensating controls: IPS virtual patching, ACLs limiting sources, enhanced monitoring, no internet path. (c) A time-boxed exception owned by a named manager with an expiry tied to the vendor visit. Exceptions expire; risk acceptance without an expiry is unmanaged risk.

PBQ practice

Scenario — Build the firewall rule set

You are the security engineer for a small company rolling out a new architecture. The firewall sits between three zones: Internet (untrusted), DMZ (contains a public web server at 10.10.1.20 and nothing else), and Internal LAN (10.20.0.0/16, contains workstations, a file server at 10.20.1.15, and an admin workstation at 10.20.5.10). The business requirements are:

1. Anyone on the Internet must be able to reach the web server on HTTPS (443) only.
2. Internal users must be able to browse the web (HTTP/HTTPS out) and use DNS.
3. Only the admin workstation may manage the web server, using SSH (22), and only from the LAN.
4. The web server must be able to query the internal file server for content updates on SMB (445) — this is a business-approved exception, and nothing else in the DMZ may initiate connections into the LAN.
5. Everything else is denied, and denied traffic must be logged.

Your task (printable). Complete the ACL table below in the order the rules will be evaluated. Use the columns: #, Source, Destination, Port/Protocol, Action. Then answer, in one or two sentences each: (A) Why does the order of your rules matter here? (B) Which requirement does your final rule implement, and why must it be last? (C) A colleague proposes adding "Allow Internet → DMZ, any port" temporarily for troubleshooting. Give two reasons to refuse or to tightly scope that change.

Model answer

(A) Firewall ACLs are evaluated top-down and the first match wins, so specific allows must precede the general deny; if the deny-all rule were first, it would shadow every allow below it and nothing would work. (B) The final rule implements requirement 5 (default deny with logging) and it must be last so it only catches traffic that no earlier rule matched. (C) Refuse or rescope because (1) "any port from the Internet" exposes every service on the web server — including SSH and any accidentally started service — defeating the DMZ design and requirement 1; and (2) temporary broad rules are routinely forgotten, so any troubleshooting access should be narrowed to the engineer's source IP and the single needed port, given an expiry, and logged. (Return traffic for allowed outbound sessions is handled by the firewall's stateful inspection, which is why no explicit "allow replies" rules are needed.)

End-of-chapter test

1. An employee resigned on Friday. On Monday, IT discovers the employee's account is still active and was used over the weekend. Which part of the identity lifecycle failed?
A. Provisioning
B. Deprovisioning
C. Federation
D. Recertification reporting

2. A login page shows thousands of failed attempts spread across 600 different user accounts, with only one or two attempts per account, all using the password "Welcome123!". Which attack is this?
A. Brute force
B. Credential stuffing
C. Password spraying
D. Rainbow table attack

3. Which of the following is a true multifactor combination?
A. Password and PIN
B. Password and security questions
C. Password and fingerprint scan
D. Two different passwords, one typed and one written into a password manager's note

4. A company must keep a vulnerable legacy server running because its vendor no longer exists. The team blocks the exploit path at the IPS, restricts access to the server to one management VLAN, and adds enhanced monitoring. What is this approach called?
A. Risk transference
B. A compensating control
C. An exception with expiry
D. Patch management

5. During an investigation, responders need evidence from a running server that is suspected of being compromised by malware operating only in memory. What should they collect FIRST?
A. A forensic image of the hard drive
B. The contents of RAM and live network connections
C. Archived backup tapes from last month
D. The server's BIOS settings

6. A receiver checks a message and finds the sending server is not listed in the sender domain's DNS record of authorized mail servers. Which control produced this result?
A. DKIM
B. DMARC policy enforcement
C. SPF
D. TLS opportunistic encryption

7. Which incident response phase comes immediately after containment?
A. Preparation
B. Recovery
C. Lessons learned
D. Eradication

8. A security team wants only approved applications to run on finance workstations; anything not on the approved list is blocked by default, including never-before-seen malware. Which control should they implement?
A. Signature-based antivirus
B. Application allow list
C. Host-based firewall
D. Data loss prevention

9. A junior analyst builds a SOAR playbook that automatically disables any account flagged by the SIEM. Before deploying it to production, which guardrail is MOST important?
A. Making the playbook run as fast as possible
B. Testing the playbook and scoping/testing its actions so it cannot disable accounts at uncontrolled scale
C. Giving the playbook permanent administrator rights on every system
D. Removing logging so the playbook runs with less overhead

10. An employee installs a game on their company phone from a third-party website that offers direct app downloads. Which mobile security risk does this describe?
A. Jailbreaking
B. Containerization failure
C. Sideloading
D. Geofencing bypass

Answer key

1. B — Deprovisioning failed: a leaver's account must be disabled promptly when employment ends, including revoking sessions and access.

2. C — Password spraying tries a few common passwords across many accounts, staying under per-account lockout thresholds. Brute force would concentrate many attempts on one account, and stuffing would use known leaked pairs.

3. C — A password (something you know) plus a fingerprint (something you are) combines two different factor types. Options A, B, and D pair knowledge factors with knowledge factors, which is still single-factor.

4. B — A compensating control reduces the risk by other means (IPS blocking, network restriction, monitoring) when the primary fix — patching — is impossible. An exception documents accepted risk; the team here actively mitigated it.

5. B — Order of volatility: RAM and live network state are the most fragile and vanish at power-off, and memory-only malware may leave little on disk. Capture them before imaging storage.

6. C — SPF publishes the list of servers authorized to send for a domain in DNS, and the receiver compares the connecting server against it. DKIM uses signatures; DMARC sets policy on SPF/DKIM results.

7. D — The order is preparation, detection, analysis, containment, eradication, recovery, lessons learned. The root cause and persistence must be removed before systems are safely restored.

8. B — An application allow list permits only approved software to execute and blocks everything else by default, which is why unknown malware is stopped without needing a signature.

9. B — Guardrails — testing, scoping allowed actions, rate limits, approvals for destructive steps, and logging — keep automation from causing damage at machine scale. Speed and permanent privilege increase risk rather than control it.

10. C — Sideloading is installing apps from outside official stores, bypassing store vetting and signing checks. Jailbreaking removes OS restrictions; it is a different risk, though the two often appear together.