Security+ Incident Response: The Order Is the Question

Most Security+ questions about incident response don't test your understanding of what each phase is. Instead, they present a scenario and ask what should come next. If you have the steps memorized, the correct answer should logically fit into the situation. But if you just know the definitions, a few options might seem plausible, leaving you to guess.

Objective 4.8 outlines the process in seven steps: preparation, detection, analysis, containment, eradication, recovery, and lessons learned. NIST SP 800-61 groups these into four phases, folding containment, eradication and recovery (the action steps) into one. Know both versions; either could be used, but the seven-step list helps spot the tricky options.

Find where the story is

Before you look at the options, read the situation and ask one thing: what has already happened? If the alert just went off and no one knows if it's real, you're in the detection or analysis phase. If the team has confirmed the malware and knows which hosts are affected, analysis is done and the next step is containment. Once the hosts are cut off and the attacker can't get back in, eradication is next.

The habit pays off because the distractors are nearly always real steps. They're just the wrong move for this moment. Picture a confirmed infection that is still spreading. The question will offer "reimage the servers" and "restore from last night's backup" beside "isolate the hosts." All three occur at some point. Only one takes place now.

Contain before you clean

The trap CompTIA leans on most is rushing to eradication. Cleaning up malware seems like the right action, but doing so can backfire. If the system is still connected to the network and the attacker retains access, a freshly cleaned machine will simply be reinfected, and you'll have destroyed evidence you might need later.

Containment, on the other hand, restricts the damage. Short-term containment is swift and can be reversed; disconnect the host from the network, block the attacker's IP or domain at the firewall, and disable the compromised account. Long-term containment keeps things secure while you plan the recovery, such as moving systems to a separate VLAN and changing passwords.

So, when a question says the threat is confirmed and still active, look for the response that halts its spread. That is the answer CompTIA seeks, even if a seemingly more comprehensive option is presented.

Clean before you restore

The second trap is rushing into recovery. Restoring from backup looks like the end goal, and it is, just not while the underlying issue is still present. If you restore while the vulnerability that was exploited remains, the attacker can easily return through the same entry point.

To truly eradicate the problem, you must remove the cause. This means not just deleting the obvious infected file but also eliminating any methods the attacker used to maintain access, like scheduled tasks or services. You also need to patch whatever allowed the attacker in and invalidate any credentials or tokens they might have stolen. Recovery then restores from a backup taken before the breach and checks that the system is clean before it goes back into production. After that, you watch it closely for a while.

A related concern is deciding which backup to use. The most recent one is often the wrong choice. If the compromise began before that backup, restoring it will reintroduce the malware. The proper choice is a backup from a time before the breach that has been confirmed to be clean.

The two ends people mix up

Preparation and lessons learned can seem alike because they both relate to planning. The key difference is the timing. Preparation takes place before any incident happens. That's where playbooks get written, tools like EDR and SIEM get set up, and backups get tested. Lessons learned happen after an incident, as a review of what was slow and what caused it, leading to action items that each have an owner.

The two concepts connect, which is why NIST illustrates the lifecycle as a loop. Findings from lessons learned feed back into preparation. If a question describes updating a playbook because of what went wrong in the last incident, CompTIA refers to that as lessons learned. A question about writing the playbook before anything has happened is preparation.

Tabletop or simulation

The same objective also deals with testing the plan, and the main issue is determining which method is suitable. A tabletop exercise involves a discussion where the team goes over a scenario, and nothing gets touched, so it is a cheap and safe way to find gaps in roles and escalation. A simulation, on the other hand, introduces realistic events into an environment resembling production to test detection and hands-on response using real tools. If the question asks to test decisions without putting production systems at risk, then it is a tabletop exercise.

Practicing it

The way to master this is by shifting focus from memorizing the list to placing scenarios on it. Pick any incident question and, before looking at the options, state aloud which step the story is on and which one follows next. After repeating this a few dozen times, the wrong answers begin to seem clearly too early or too late.

When I was preparing for Security+, scenario questions were my weak spot until I started doing this. The free practice questions include incident response scenarios, the objectives page shows where 4.8 is located in Domain 4, and if you're aiming for the practical side of the exam, the free PBQ requires no account.

Originally published on secplusmastery.com.