CISSP Security Operations: 48 practice questions

12 of the 48 Security Operations questions in the Certsqill CISSP bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for CISSP? Take the free 5-min readiness check →

1. Post-Incident Activity: Which NIST SP 800-61 incident response phase addresses the team meeting at the end?

1. Containment, Eradication, and Recovery phase

   Containment (isolating the server), Eradication (removing malware), and Recovery (restoring from backup) make up this phase. The lessons-learned meeting occurs in the Post-Incident Activity phase, which follows recovery.
2. Post-Incident Activity (Lessons Learned) ✓

   NIST SP 800-61 defines the final phase as Post-Incident Activity, which includes a lessons learned meeting to review what happened, evaluate the response effectiveness, identify process improvements, and update documentation. This is the phase where root cause analysis and recommendations for preventing recurrence are documented.
3. Preparation phase (pre-incident readiness)

   Preparation is the first phase — establishing policies, procedures, tools, and training before incidents occur. The lessons-learned meeting occurs after an incident, in the Post-Incident Activity phase.
4. Detection and Analysis of the incident

   Detection and Analysis is the second phase — detecting the anomaly, confirming the malware infection, and scoping the incident. It does not include lessons-learned meetings.

NIST SP 800-61 phases: (1) Preparation, (2) Detection & Analysis, (3) Containment/Eradication/Recovery, (4) Post-Incident Activity — lessons learned is phase 4.

2. Running processes → Network connections → RAM contents →: In what order should the following sources be collec

1. Network connections → Disk image → RAM contents → Running processes → Swap/page file

   Collecting the disk image before RAM, processes, and swap violates the order of volatility. The disk is the most durable source and should be captured after the volatile in-memory data.
2. RAM contents → Running processes → Network connections → Swap/page file → Disk image

   Running processes and network connections are more volatile than a full RAM capture — individual processes and connections can terminate at any moment, so the order should begin with those most ephemeral sources before the RAM image.
3. Running processes → Network connections → RAM contents → Swap/page file → Disk image ✓

   Order of volatility (most to least volatile): CPU registers/cache (not listed), then running processes (lost when process ends/system reboots), network connections (lost when connection closes), RAM contents (lost on power off), swap/page file (lost on reboot, but persists until overwritten), disk image (persists until overwritten — most durable). Collect in this order to capture most ephemeral data first.
4. Disk image → RAM contents → Swap/page file → Network connections → Running processes

   This reverses the order — collecting the most durable evidence first means the most volatile evidence (running processes, network connections) is lost or changed before collection. Disk images are the most durable and should be collected last.

Order of volatility (most to least volatile): CPU registers → running processes → network connections → RAM → swap/page file → disk → remote logs → backups.

3. Broken chain of custody: What is the primary legal/evidentiary concern?

1. Violation of the best evidence rule; because investigators retained the original drive instead of first imaging it, the court will exclude the original and instead demand that a verified forensic copy be produced

   The best evidence rule concerns producing originals rather than copies when possible. The scenario's problem is not originals versus copies but the undocumented handling that breaks the chain of custody.
2. Fourth Amendment violation; the drive was seized from the workstation without first obtaining a judicial search warrant, making any evidence recovered from it inadmissible as an unconstitutional search and seizure

   Fourth Amendment protections apply to government searches. Corporate internal investigations are conducted under corporate authority, not government action. The concern here is evidentiary integrity (chain of custody), not the constitutional legality of the seizure.
3. Privacy violation; the employee's explicit written consent was never obtained before the drive was seized, which under workplace privacy law invalidates the evidence and bars its use in any later proceeding

   Consent requirements for corporate investigations depend on policy and jurisdiction, but the scenario's primary evidentiary problem is the missing chain-of-custody documentation, not consent for collection.
4. Broken chain of custody; without documented handling records, the drive's admissibility as evidence may be challenged because it cannot be proven the evidence was not tampered with ✓

   Chain of custody requires continuous documentation of who possessed evidence, when, where, and what was done with it from collection to court. Any gap creates an opportunity for a defense to argue the evidence was tampered with, planted, or contaminated. Inadmissible evidence cannot be used in legal proceedings.

Broken chain of custody (no documentation of evidence handling) allows the evidence's integrity to be challenged in legal proceedings, potentially making it inadmissible.

4. System A = IDS: What are Systems A and B, and which detection method detected the zero-day?

1. System A = IDS (passive, alert-only), System B = IPS (inline, blocking). Zero-day detected by anomaly-based/behavioral detection in System A ✓

   IDS (Intrusion Detection System) passively monitors and alerts — it does not block traffic. IPS (Intrusion Prevention System) sits inline and can actively block matching traffic. Anomaly-based detection establishes behavioral baselines and alerts when traffic deviates from normal patterns — it can detect zero-days that have no known signature, at the cost of higher false positives. Signature-based detection only matches known patterns — it misses zero-days.
2. System A = HIDS, System B = NIDS. Zero-day detected by signature matching once updated threat feeds add the new attack pattern to both sensors' databases

   HIDS monitors individual host activity and NIDS monitors network traffic, but the scenario describes an inline blocking system (IPS) versus an alert-only system (IDS). Detecting a zero-day by signature matching is also contradictory — a zero-day has no existing signature.
3. System A = IPS (inline, blocking), System B = IDS (passive, alert-only). Zero-day detected by signature-based detection in System B after the pattern is known

   System A only alerts (passive) = IDS, and System B blocks traffic inline (active) = IPS, so this reversal is wrong. Signature-based detection also cannot catch a zero-day, which by definition has no known signature.
4. Both A and B are SIEM platforms. Zero-day detected by cross-source correlation rules firing on the aggregated firewall and endpoint log data

   A SIEM aggregates and correlates logs across sources — it does not directly inspect network traffic for attack patterns inline. IDS/IPS specifically examine network traffic against signatures or behavioral profiles.

IDS = passive alert-only; IPS = inline active blocking. Anomaly/behavioral detection catches zero-days by detecting deviations from baseline; signature-based detection only matches known patterns.

5. Hot site; only a fully operational replica: Which recovery site type is most appropriate, and why?

1. Warm site; its pre-staged hardware balances cost and recovery time and can be configured well within this system's 2-hour RTO window

   A warm site has basic infrastructure pre-staged but still needs significant configuration time (typically hours to days). With complex custom middleware, it likely cannot meet a 2-hour RTO — and any site taking 4+ hours would breach the 4-hour MTD.
2. Hot site; only a fully operational replica with pre-configured systems can achieve a 2-hour RTO for complex custom middleware ✓

   A hot site is fully equipped with all hardware, software, and data replication running — recovery is primarily a failover operation. A 2-hour RTO with complex middleware configuration eliminates warm sites (require hours to days to configure) and cold sites (require days to weeks). Only a hot site with pre-configured middleware can achieve the required RTO.
3. Cold site; it is the most cost-effective option and still provides sufficient lead time to procure and rebuild the middleware inside the 2-hour RTO

   A cold site has only basic utilities (power, cooling, connectivity) with no pre-staged hardware or software. Recovery requires procurement, installation, and configuration from scratch (days to weeks) — completely incompatible with a 2-hour RTO.
4. Reciprocal agreement; a partner organization offers on-demand facility access that dependably meets the 2-hour RTO for this custom middleware

   Reciprocal agreements depend on the partner having available capacity and compatible systems — neither is guaranteed. For a 2-hour RTO with complex custom middleware, this is the least reliable option and is generally considered the least dependable DR arrangement.

A 2-hour RTO with complex middleware requires a hot site — only a fully pre-configured replica can achieve this RTO; warm sites need hours-to-days for setup, cold sites need days-to-weeks.

6. Tabletop exercise → Walkthrough → Simulation → Parallel: Which sequence correctly orders DR testing methods fr

1. Full interruption test → Parallel test → Simulation → Walkthrough → Tabletop exercise

   This sequence starts with the most disruptive test (full interruption) and moves toward the least disruptive — it is reversed. Best practice builds from low disruption to high disruption progressively.
2. Simulation → Tabletop exercise → Walkthrough → Full interruption test → Parallel test

   Simulations involve more activity than tabletops and walkthroughs, so leading with them is out of order. Full interruption should also rank as more disruptive than parallel, since it actually shuts production down.
3. Tabletop exercise → Walkthrough → Simulation → Parallel test → Full interruption test ✓

   Tabletop = discussion only, no systems involved. Walkthrough = participants follow the plan step-by-step verbally. Simulation = mimics a disaster scenario without activating recovery systems. Parallel = recovery systems activated while production continues (both run simultaneously). Full interruption = production is actually shut down and recovery is fully tested — most realistic, most disruptive.
4. Parallel test → Tabletop exercise → Full interruption test → Walkthrough → Simulation

   This ordering is scrambled and ignores progressive disruption. Organizations should not start with parallel tests (which activate recovery systems) before validating the plan through tabletops and walkthroughs.

DR testing disruption order: Tabletop (discussion only) → Walkthrough (plan review) → Simulation (scenario, no activation) → Parallel (recovery + production both run) → Full interruption (production shut down).

7. SIEM: Which technology is designed for this purpose?

1. Endpoint Detection and Response (EDR) host platform

   EDR focuses on endpoint visibility — detecting and responding to threats on individual hosts. While it provides rich telemetry, it does not aggregate and correlate events across network, identity, and application sources the way a SIEM does.
2. IDS/IPS with continuously updated signatures

   IDS/IPS identify individual attack attempts based on signatures or anomalies. They do not correlate events across many disparate systems over time — an IDS emits individual alerts, whereas a SIEM correlates multiple alerts into higher-fidelity incidents.
3. Log aggregation server using plain syslog

   A syslog server collects and stores log data but provides no correlation or analysis. It solves the storage problem, not the triage problem — analysts would still have to search the aggregated logs manually.
4. SIEM (Security Information and Event Management) ✓

   SIEM aggregates logs from multiple sources and applies correlation rules to identify patterns across events, time, and systems. Instead of individual alerts, SIEM generates incidents when multiple related events match an attack pattern (e.g., failed logins from one IP + privilege escalation + data access = potential breach scenario). This reduces alert volume while increasing signal quality.

SIEM aggregates multi-source events and applies correlation rules to identify attack patterns spanning time and systems — reducing alert noise by creating high-fidelity incidents from related events.

8. Follow the emergency change process: What is the correct approach?

1. Follow the emergency change process: deploy the patch using an expedited approval (emergency CAB or designated approver), document the change, and retroactively complete full change documentation after deployment ✓

   Most change management frameworks (ITIL) include an emergency change process for situations requiring immediate action to prevent significant business impact. An emergency CAB or designated emergency approver provides expedited approval. Documentation is still required but can be completed retroactively. The key principle: change management should never prevent necessary emergency response, but changes still require authorization.
2. Wait for the next regularly scheduled CAB meeting in two weeks and deploy the patch only after it receives full standard change-advisory-board review and formal approval through the normal governance process

   Waiting two weeks for a standard CAB meeting while an active exploit targets production would be a failure of security risk management — the organization would almost certainly be compromised first. Emergency change processes exist precisely for this scenario.
3. Skip patching entirely and rely on a compensating WAF rule as a permanent substitute, since a virtual-patching control blocks the exploit and requires no change-management approval to put into production

   A WAF rule can buy time but typically still needs change approval, and a compensating control is not equivalent to remediation. Patching should proceed via the emergency change process; relying on the control indefinitely is a risk-acceptance decision requiring management approval.
4. Deploy the patch to the affected web servers immediately with no approval and no documentation, because active exploitation removes any obligation to record the change or obtain even retroactive authorization

   Although speed is critical, bypassing approval and documentation entirely creates audit failures, accountability gaps, and outage risk from an unvetted change. Emergency processes provide expedited approval, not no approval, and documentation is still required even if retroactive.

Emergency change processes provide expedited approval for urgent security changes — change management ensures accountability, but never prevents necessary emergency response.

9. Bollards and vehicle barriers + mantrap with occupancy: Which layered combination of controls addresses all th

1. Security cameras covering every entrance, exit, and server aisle as a single detective layer that records vehicle approaches, tailgating attempts, and equipment removal alike

   Cameras are detective controls — they record incidents but do not prevent vehicle ramming, tailgating, or equipment theft. Preventive physical controls (barriers, mantraps, locks) are needed to stop incidents, with cameras as a complementary detective layer.
2. Bollards and vehicle barriers (vehicle threat) + mantrap with occupancy sensors (tailgating) + cable locks and equipment logging with security cameras (insider theft) ✓

   Bollards prevent vehicle ramming attacks. Mantraps with occupancy sensors physically prevent tailgating (one person per badge swipe). Cable locks prevent equipment removal; asset logging and cameras detect and deter insider theft. This implements defense-in-depth across the physical security perimeter.
3. Security guards posted at all entrances around the clock to screen arriving vehicles, verify badges against tailgating, and inspect departing staff for concealed server equipment

   Guards address some threats but are subject to human error, social engineering, and fatigue. Guards alone lack the physical barriers (bollards) needed for vehicle threats and the automated single-occupancy enforcement of a mantrap. Defense-in-depth requires both technical and human controls.
4. Biometric authentication at every entry point, using fingerprint and iris matching to stop vehicle intrusion, block a second person from tailgating, and prevent insider theft of server equipment

   Biometrics authenticate identity at access points but do not prevent vehicle ramming (no barrier), do not physically stop a second person from tailgating through, and do not prevent equipment theft by an authorized insider.

Physical security defense-in-depth: bollards (vehicle), mantraps with occupancy sensors (tailgating), cable locks + cameras + asset logging (insider theft).

10. The internet-facing financial system: Which should be patched first, and what factor justifies the prioritizat

1. Patch both vulnerabilities simultaneously at equal priority, because each carries a CVSS base score in the Critical range and the scoring standard treats all Critical findings as demanding identical urgency

   When resources are constrained, effective security requires risk-based prioritization. Equal treatment ignores differences in exploitability and business impact. CVSS base scores do not account for environmental factors, so exposure and asset value must drive prioritization.
2. Patch the air-gapped lab system (CVSS 9.5) first, because air gaps create a false sense of security and isolated systems are statistically the most common entry point exploited by advanced persistent threats

   Air gaps are not absolute barriers, but the comparison is about relative risk. An internet-facing system holding financial data presents immediate, direct exposure, whereas the isolated lab system has inherently lower exploitability — so the higher-exposure system is patched first.
3. The internet-facing financial system (CVSS 9.8); exploitability, exposure (internet-accessible), and business impact (financial data) together make it the higher operational risk despite similar CVSS scores ✓

   Effective vulnerability prioritization goes beyond raw CVSS scores. Risk = Likelihood × Impact. The internet-facing financial system has: higher exploitability (directly accessible, no air gap), higher likelihood (internet exposure), and higher impact (financial data, regulatory requirements). CVSS base score alone doesn't account for environment-specific factors — this is what CVSS Environmental Score metrics address.
4. Defer both patches until the next scheduled monthly maintenance window regardless of exposure, since batching critical fixes into planned outages minimizes operational disruption and change-related risk

   Critical vulnerabilities on internet-facing systems with sensitive data should not wait for a routine maintenance window. The emergency change process exists for exactly this situation, and deferral is unacceptable risk acceptance without proper authorization.

Risk-based patch prioritization considers exploitability + exposure + business impact — internet-facing financial systems take priority over air-gapped lab systems despite similar CVSS base scores.

11. DRP covers IT system recovery: Which plans are being executed, and what is the distinction between them?

1. BCP and DRP are simply two interchangeable names for one identical document, and different organizations arbitrarily choose one label or the other with no real difference in scope or focus between them

   Even where organizations combine them, BCP and DRP have fundamentally different focuses. DRP may be a subset of BCP in some frameworks, but they address distinct concerns — IT system restoration versus business process continuity — and CISSP treats them as distinct plans.
2. DRP covers every aspect of the disaster response effort, while BCP is a narrow plan that exists only to satisfy regulatory requirements imposed specifically on firms operating in the financial services sector

   DRP is specifically IT-focused, not all-encompassing, and BCP is a broad discipline applicable to every industry, not just financial services. BCP requirements come from many sources, including ISO 22301 and NIST SP 800-34.
3. BCP (Business Continuity Plan) covers IT system recovery and failover, while DRP (Disaster Recovery Plan) covers the people, business processes, and customer communications that continue during a disruption

   This reverses the definitions. DRP handles IT systems recovery, while BCP handles business operations continuity (people, processes, communications). Reversing the two is a classic CISSP trap.
4. DRP (Disaster Recovery Plan) covers IT system recovery; BCP (Business Continuity Plan) covers people, processes, and business operations — they are complementary but distinct plans ✓

   DRP focuses on recovering IT infrastructure and systems after a disaster. BCP focuses on maintaining business operations and processes when normal operations are disrupted — including people management, customer communications, alternative work arrangements, and operational continuity. Both are required for comprehensive organizational resilience.

DRP = IT systems recovery. BCP = people, processes, and business operations continuity. They are complementary: DRP restores technology; BCP keeps the organization functioning during disruption.

12. Grant only Q2 access: Following security best practices, how should this access request be handled?

1. Grant only Q2 access; the need-to-know principle requires that access be limited to information actually required for the current work task, not for general reference ✓

   Need-to-know (a subset of least privilege) limits access to information required for a specific, current task. 'Reference purposes' and 'might be useful' are not sufficient justification. Access to historical reports not required for the current project should be denied. This limits the damage if the account is compromised and reduces insider threat exposure.
2. Grant Q2 access now and schedule a formal review in six months to decide whether the requested Q1 reference access should also be provisioned to the analyst at that later point

   The correct handling is to deny Q1 access now because there is no current business need. Scheduling a future review does not address the immediate lack of necessity — unneeded access should not be granted proactively on the chance it might be useful later.
3. Grant both Q1 and Q2 access because the analyst holds a legitimate financial role and may plausibly need the historical reference reports at some point during the project's lifecycle

   Granting speculative access ('may need') violates need-to-know. Access should map to specific, documented business requirements, not general convenience. If the analyst later needs Q1 data for a defined task, they can request it then.
4. Escalate the entire request to senior management for executive sign-off, since decisions about granting access to any financial reporting data must be approved above the level of the data owner

   For routine requests under established policy, escalation to senior management is unnecessary and creates bottlenecks. The data owner or manager decides based on documented need; management escalation is for exceptions, not routine need-to-know denials.

Need-to-know limits access to information required for the current specific task — 'reference purposes' or 'might be useful' are not sufficient justification for granting access.

Other CISSP domains

• Security and Risk Management — 89 questions →
• Security Architecture and Engineering — 87 questions →
• Communication and Network Security — 63 questions →
• Identity and Access Management (IAM) — 63 questions →
• Software Development Security — 59 questions →
• All 497 CISSP questions →