Incident response playbooks, where to start?

Incident response playbooks, where to start?

What goes on in your mind when you think about “Incident Response Playbooks”?

Reading this, your background will most likely fit in one of two categories:

1. You are a manager for a while now and really dig deep into processes, ensuring a corporate quality standard. You made sure to have written documents available about every scenario you and your news reader have been able to think of. Your playbooks will align to those scenarios (top-to-bottom).
2. You are a technical person or affiliated to, so you did what us techies do: staring at logs for some weeks and making a list of every log entry appearing suspect (or comes climbing out a cyber ventilator, definitely sus:)). You put those into a nice Excel file (egrep/cut/piped the crap out of the log files) and took them as “to be categorized” (bottom-to-top).

Whatever category sounds more appealing to you, both approaches needs to translate into an incident response playbook worthy of the name.

Personally, I like the top-to-bottom approach. It is not recommendable to start with the limitations of the platform, stick to your best practice and close the gaps in between by improving the detection as well as respond capabilities of your favorite platform.

As a result:

• Awareness of gaps. Maybe your process isn’t really doable, that happens. That could be resolved by improving on the technology side or updating your processes focusing on the “doable” factor.
• You save a lot of work. As the flow feature of many modern SOAR or Incident Response platforms is already pretty close to the swim-lane designs you have put in your processes – translating those into playbooks is rather fast and easy.
• You know your repeatable work (Sisyphus adios). Let’s be honest, many response playbooks look the same for 30% of the tasks. Those 30% consisting mostly of dismantling and enrichment as well as some queries to your active directory or other internal platforms. These parts can be standardized and reused as a part of all incident response playbooks.

What do you really need?

First of all, you need categories. There is no need for a single response playbook for every single event. Most events can be clustered under the same category and one response plan to that category will be more than enough.

Many Events x one Incident type x One Playbook
n x 1 x 1

In practice the response to for example malware is consistent and repetitive. This opens an opportunity to automate and save time as well as eliminate human error. Therefore generate time to focus on those odd and slippery malware, because hackers and their instruments evolve fast as well. Don’t hate the player, love your playbook.

It is commonly accepted to differentiate about 10 to 14 distinctive categories. My personal favorites are:

• Malware. Maybe the most common type, seeing the awareness as well as its detection has been the focus for years on end and built-in into almost every appliance. As an additional note, in this category you will also find Command & Control and everything related to malware, so you don’t need another playbook.
• Phishing. Since “I love you” a general public awareness of Phishing was established and helped greatly with the most unpredictable factor in IT, the user. Still some baits smell like that burger with fries at 3 p.m. we all have bitten into at least once, but no worries the playbook is here to help. As emails are established to be the core of our daily communication, Phishing and Spam make up the second category based on their sheer quantity. You might also create a category Spear Phishing or even Whaling, depending on your approach. As those attack types are sophisticated and targeted they can be more harmful than the usual Phishing attacks. Another solid approach would be to branch out into those categories later on during investigation and distinguish them from the standard phishing response.
• DOS/DDOS attacks. Denial of Service is a common category too. Especially if you run services or your own servers, you will respond to these types of attack every so often. This category also includes API exhaustion and will react in the same way as DOS/DDOS attacks. Keep in mind we talk about response not detection, many detection use cases can be linked to one response playbook (n:1).
• Data Leakage. When humans are involved, human error is a factor to be reckoned with. Data can always be copied to the wrong location or in worst case be stolen. Keep in mind that the alerts in this category could start with access to pastebin/ghostbin/“whatever”-bin site or to shared storage (Google Drive, Dropbox etc). The response should look in these cases simple but has plenty of room to grow.
• Account Activity/Authentication. A vague one, but a category that is undeniable useful. Many companies use several categories for e.g. brute force passwords, access from unknown location and login after failure. But if you look into the details, the playbooks respond the same. So it makes sense to have a standard approach to all these activities.
• Advanced Persistent Threat (APT). Sophisticated attacks require an individual response. It is recommendable to escalate such findings directly to your CERT (Cyber Emergency Response Team) / CIRT (Cyber Incident Response Team) or at least to a Tier III analyst of your team. The enrichment might look very different, as any exposure of indicators could lead to a change of strategy from the attacker.
• Malicious Network Activity. Basically a category for “DNS”, shellshock like attempts or simply a DNS server doing VNC sharing and similar. All those activities will follow the same playbook for around 80%, so I recommend to keep them combined as long as you can.
• Suspicious Activity. We have seen quite often that the author of an use case describes his detection rule with “Possible XYZ” or that the alert of a rule can lead towards false positives or cross category detections. This is the category for all of those mentioned responses.
  This can also be your generic playbook which you use to do some basic investigation before putting the event in its final category.

That’s it for today, please leave a 👏 and be excellent to each other