Incident Response and Recovery practice questions

Disconnect the system from the network

Why it fails: Network isolation is a containment step, but evidence preservation should be prioritized.

Create a forensic image of the hard drive

Why it fails: Hard drive imaging is important but volatile data should be collected first.

Run an antivirus scan to remove malware

Why it fails: Running AV can modify evidence; it should be avoided during initial forensics.

Hard drive image, network connections, running processes, RAM

Why it fails: RAM should be first, not last.

Running processes, RAM, hard drive image, network connections

Why it fails: RAM should be first.

Network connections, hard drive image, RAM, running processes

Why it fails: RAM is more volatile than network or disk.

Disconnect the system from the network

Why it fails: Network isolation is important but memory capture should be done first to capture network state.

Run antivirus scans to identify malware

Why it fails: Running tools on a live system alters evidence; memory capture should precede any analysis.

Create a forensic image of the hard drive

Why it fails: Hard drive imaging is less volatile and should be done after memory capture.

Reimaging the system from a verified clean image

Why it fails: Reimaging is an effective eradication method, but if a clean image is available, it's a valid step; however, cleaning persistence is more critical in a non-reimage scenario. The question asks for the MOST critical, and cleaning persistence is fundamental.

Resetting compromised user credentials

Why it fails: Resetting credentials is important but does not remove malware already on the system.

Patching the exploited vulnerability

Why it fails: Patching prevents re-exploitation but does not remove existing malware.

cat /proc/kcore > /tmp/mem.dump

Why it fails: catting /proc/kcore can capture memory but is not recommended for forensics because it does not produce a clean dump and may cause system instability.

memdump -o /tmp/mem.dump

Why it fails: memdump is not a standard Linux memory acquisition tool; it may exist on some systems but is not as widely recognized as LiME.

dd if=/dev/mem of=/tmp/mem.dump bs=1M

Why it fails: /dev/mem provides access to physical memory but may be restricted; dd can be used but LiME is designed for forensic acquisition and is more reliable.

Resetting all user passwords

Why it fails: Resetting passwords is important but does not remove the backdoor from the system.

Reimaging all affected systems from a known-good backup

Why it fails: Reimaging is effective but the question asks for the MOST critical step; if the backdoor is still present, reimaging might be necessary. However, the scenario implies the backdoor is already identified and removal can be attempted.

Conducting security awareness training for all employees

Why it fails: Training reduces future risk but does not address the current infection.

Notify the affected customers of the data breach

Why it fails: Notification is done after investigation and legal guidance, not immediately upon classification.

Create a forensic image of the compromised server

Why it fails: Forensic imaging is part of evidence collection, which occurs after containment and escalation.

Begin containment by isolating affected systems

Why it fails: Containment comes after escalation and decision-making; initial triage and escalation are immediate.

Disk image, memory dump, process list, network connections

Why it fails: Disk is non-volatile and should be collected after volatile data.

Process list, memory dump, disk image, network connections

Why it fails: Memory should be first.

Network connections, memory dump, process list, disk image

Why it fails: Memory is most volatile and should be captured first.

Disable the affected user accounts.

Why it fails: Account disabling is containment, not eradication.

Reimage all affected systems.

Why it fails: Reimaging is effective but may be too drastic if cleaning is possible.

Run an antivirus scan on the systems.

Why it fails: Antivirus may not detect fileless malware.

A warm site is typically ready to operate within hours.

Why it fails: Warm sites may take hours to days; hot sites are ready within minutes.

A warm site has live data replication from the primary site.

Why it fails: Live replication is characteristic of hot sites.

Extend the RTO to allow time for manual data re-entry.

Why it fails: RTOs are defined requirements; extending them indicates a failure of the DR plan.

Failover to the hot DR site immediately without data restoration.

Why it fails: Without replicated data, the hot site may have stale or no data, causing data loss and operational failure.

Switch to a cold DR site that requires hardware setup.

Why it fails: A cold site takes days to activate, exceeding the 4-hour RTO.

Perform a containment strategy by disabling the user's account and blocking malicious IPs.

Why it fails: Additional containment may be needed, but NIST SP 800-61 places detection and analysis before containment. The analyst has already isolated the laptop, which is a containment step. The immediate next action after confirming an incident is to analyze it to understand its scope, impact, and root cause, not to apply further containment blindly.

Conduct a lessons learned meeting to discuss how the infection occurred.

Why it fails: Lessons learned is performed after the incident is resolved, during the post-incident activity phase. Holding it now would be premature because the investigation is ongoing and the full scope and impact are not yet known. The meeting's purpose is to improve future response based on complete information, which is not yet available.

Eradicate the malware by reinstalling the operating system and restoring data from backup.

Why it fails: Eradication and recovery are later phases in the incident response lifecycle. Before removing the malware, the analyst must first determine the scope and impact, such as whether other systems are affected and what data was compromised. Jumping directly to reimaging could destroy valuable evidence and leave other compromised hosts undetected.

ISO/IEC 27035

Why it fails: ISO/IEC 27035 is an international standard for incident management, but it is less prescriptive than NIST SP 800-61 and does not provide the same level of detailed operational guidance. While it is a valid framework, it is not the primary reference for structuring the incident response lifecycle in most organizations, especially those seeking a practical, step-by-step approach.

COBIT 2019

Why it fails: COBIT 2019 is a governance framework for enterprise IT, emphasizing control objectives and alignment with business goals. It does not provide a detailed incident response lifecycle or operational steps for handling security incidents. While it can complement incident response planning, it is not the primary reference for structuring the response process itself.

ITIL v4 Incident Management

Why it fails: ITIL v4 focuses on IT service management and treats incidents primarily as service disruptions, not security incidents. It lacks the security-specific phases such as detection, containment, eradication, and recovery from a threat perspective. Therefore, it is not the appropriate primary framework for structuring a security incident response lifecycle.

Perform a reverse DNS lookup on 192.168.1.50 to obtain the hostname associated with the IP address.

Why it fails: Reverse DNS for a private IP address is unlikely to yield useful information because private IPs are not globally unique and internal DNS may not have a PTR record. Even if a hostname is returned, it may not be reliable for attribution. This is not the most effective first action compared to checking DHCP logs.

Analyze the TCP sequence numbers to determine if the session was established through a spoofed handshake.

Why it fails: TCP sequence numbers can help detect spoofing if the handshake appears incomplete, but in a full TCP session with a destination port of 22 (SSH), the handshake likely completed. This method is more relevant for identifying blind spoofing attempts, not for tracing the source of an established connection. It does not directly identify the source host.

Examine the TTL and IP identification fields in the packet headers to infer the original source operating system and potential spoofing.

Why it fails: While TTL and IP ID can hint at the source OS and whether the source IP is spoofed, this is not the first step. The immediate priority is to determine if the source IP is internal and thus likely the actual origin or a pivot point. TTL analysis is secondary and may be inconclusive if the attacker used a tool that manipulates these fields.

Create a bit-for-bit copy of the hard drive using a write blocker.

Why it fails: Creating a forensic image is a key step, but it is not the first. Before imaging, the examiner must ensure the system is isolated and volatile data is captured, as these are more easily lost. Imaging the hard drive without first securing the system could result in a tainted image if the system is still running and modifying data.

Document the chain of custody form and take photographs of the server.

Why it fails: Documentation and photographs are important, but they are not the first step. The examiner must first ensure that the evidence is not altered. Taking photographs could be done after securing the scene, but the immediate priority is to prevent modification of the system state, often by using a write blocker or isolating the system from network access.

Capture the contents of volatile memory (RAM) using a forensic tool.

Why it fails: Capturing RAM is critical, but it is not the first step. Before capturing volatile data, the examiner must ensure that the system is isolated and that no actions are taken that could alter the memory contents, such as running programs. The very first step is to secure the system to prevent evidence contamination, often by disconnecting it from the network or using a write blocker.

Review the file server logs to determine which files were accessed during the suspicious session.

Why it fails: While reviewing logs is important for analysis, it is not the first step. The incident response process must be initiated to ensure proper documentation and coordination. Immediate log review without proper process can lead to missed evidence or lack of proper chain of custody. The first step is to start the process, then gather details.

Change the password for the user account to prevent further unauthorized use.

Why it fails: Changing the password might lock out the attacker but could also alert them and prompt destructive actions. It may also disrupt legitimate business if the account is needed. Without understanding the full scope, this could be ineffective if the attacker has other credentials. The first step should be to follow the incident response process, not to take unilateral action.

Disable the user account immediately to prevent further unauthorized access.

Why it fails: Disabling the account may stop the attacker but could also alert them, causing them to escalate or destroy evidence. The first step should be to preserve evidence and understand the scope. NIST SP 800-61 emphasizes containment after analysis, but immediate disabling without analysis can hinder investigation and may not address other compromised accounts.

Isolating affected systems from the network to prevent lateral movement.

Why it fails: Isolating affected systems is a containment activity that occurs during the incident, not in the post-incident phase. The post-incident phase happens after the incident has been contained and eradicated. While isolation is critical, it is not part of the review and learning process. NIST SP 800-61 places containment in the containment, eradication, and recovery phase.

Implementing additional security controls to prevent similar incidents.

Why it fails: Implementing additional controls is part of the recovery or follow-up actions, but it is not a distinct post-incident activity phase task. The post-incident phase focuses on reviewing and learning, not on implementing changes. Changes are typically made after the review, as part of continuous improvement, but the activity itself is not the review. NIST SP 800-61 lists lessons learned and using feedback to improve as the core post-incident activities.

Restoring data from backups to resume normal operations.

Why it fails: Restoring data from backups is part of the recovery phase, which is distinct from post-incident activity. The post-incident phase begins after recovery is complete. NIST SP 800-61 defines recovery as restoring systems and data, while post-incident focuses on reviewing the incident and improving processes. Therefore, restoration is not a post-incident activity.

Weekly full backups with daily differential backups to a warm site.

Why it fails: Daily differential backups give an RPO of up to 24 hours, far exceeding the 15-minute requirement. A warm site may take hours or days to become operational, violating the 2-hour RTO. This strategy is suitable for less critical applications but not for one with such stringent objectives.

Hourly incremental backups with daily full backups to tape.

Why it fails: Hourly incremental backups provide an RPO of up to 1 hour, which exceeds the 15-minute RPO. Tape backups are slow to restore, likely violating the 2-hour RTO. While incremental backups reduce backup windows, they do not meet the low RPO and RTO requirements of this critical application.

Daily full backups with weekly offsite replication.

Why it fails: Daily full backups provide an RPO of 24 hours, which exceeds the 15-minute requirement. Weekly offsite replication would further increase potential data loss. This strategy does not meet the RPO, and recovery from full backups could take longer than the 2-hour RTO, especially if data volumes are large.

ls -l /etc/passwd

Why it fails: The ls -l command on /etc/passwd shows the file's modification time, similar to stat, but not individual account timestamps. It does not reveal when specific users were added or changed. This is a basic file listing, not a forensic tool for account analysis.

stat /etc/passwd

Why it fails: The stat command on /etc/passwd shows the last time the file was modified, which could indicate when any account was changed, but it does not provide per-account details. It only gives a single timestamp for the file, not for individual user entries. This is insufficient to determine which specific accounts were created or modified.

lastlog

Why it fails: The lastlog command displays the most recent login time for each user account. It does not show when accounts were created or modified. While useful for identifying dormant accounts or recent logins, it does not provide the account creation or modification timestamps needed for this investigation.

Preparation

Why it fails: Preparation precedes incidents, covering plan creation, training and tooling before anything occurs. Revising the plan after an incident is tempting because preparation owns the plan document, yet NIST SP 800-61 places lessons-learned documentation and updates in post-incident activity, using real incident experience.

Containment, Eradication, and Recovery

Why it fails: Containment, eradication and recovery covers limiting damage, removing the threat and restoring systems; lessons-learned review and plan updates occur after that work concludes. Documenting improvements here is tempting because recovery feels like closure, yet NIST SP 800-61 places post-incident activity in its own final phase.

Detection and Analysis

Why it fails: Detection and analysis covers identifying and investigating the incident, not revising the response plan. Capturing lessons while details are fresh is tempting, but NIST SP 800-61 assigns plan updates and lessons learned to post-incident activity, which follows containment, eradication and recovery.