As I mentioned in my previous column, even organizations that have mature IR functions can be caught off guard due to lack of preparation. In today’s world, the tactics of adversaries evolve constantly and companies must implement effective IR processes by assessing risks and creating plans that include contingencies and account for the broad impact of a major incident.
In this article, I’ll cover the “response” phase of the IR lifecycle. NIST 800-61 guidelines outline this in two phases: Detection & Analysis and Containment, Eradication & Recovery, but for our purposes, I’ll cover them as one broad phase that includes the entire response process.
Responding to an incident can require extreme time-sensitivity and when tensions are running high, it’s easy to miss something important along the way. Be sure not to overlook the following steps when responding to an incident.
1. Establish a Baseline. In order to effectively detect anomalies, you need to know what “normal” looks like within your environment. While you might have gained a general sense of what constitutes ordinary network traffic during your preparation phase, you should still take the time to quantify it and ensure that this baseline is broadly understood across your security team for use in the response phase. Understanding your baseline makes it possible to tune your SIEM to generate less false positives over time and help your analysts catch more dangerous incidents. When setting your baseline, consider:
● What are the standard types and volumes of traffic in your environment?
● What is getting blocked by your firewall, and what is getting through?
● What are the standard IP locations for traffic leaving your network? Is it normal for traffic to go to China, or to the Middle East?
● Who is connecting to your system, and what are their normal patterns for activity? If someone from the accounting department logs in at 2:00 in the morning, is that a regular occurrence or is it cause for alarm?
2. Optimally Leverage Security Tools. There are so many security tools on the market that it’s easy to load up on software but neglect the careful configuration and maintenance that is required for the tools to provide value. SIEM tuning is one such overlooked step. Default SIEM rules will err on the side of flagging every potential incident, which can result in as many as 10 false positives for every true positive. In order to cut down on noise and keep your analysts focused on the alerts that matter, you should tune your SIEM every two or three months to reflect your unique needs and patterns of network traffic. Along these same lines, patching and updating existing tools should be a no-brainer, but as we’ve seen in many prominent cybersecurity incidents, organizations continue to overlook this step. Having tools in place that aren’t properly maintained gives you the illusion of security while exposing you to malware and other potential attacks.
3. Correlate Incidents. Because so many IR analysts face a steady stream of alerts—many of them false positives—they tend to look at each one as an isolated event. Correlating existing incidents with previous incidents that share the same qualities can help you uncover dangerous patterns. For example, analysts will generally consider a scanning incident to be low priority or a false positive, and might close the incident without further investigation. However, a scanning incident could also be part of the identification stage of a much larger attack. Searching SIEM data to find related incidents will help the analyst understand the larger picture and take the right action.
4. Automate Repetitive Tasks. In the past few years, automation and orchestration has grown rapidly, and today is an essential component of IR. While it’s true that not everything needs to be automated, too many organizations still underestimate the time-savings to be had by eliminating repetitive tasks. For example, it might only take an analyst one or two minutes to switch systems to look up a file reputation and copy the information into an incident record, but in an enterprise SOC, this might happen one hundred times or more in a day! Analysts know too well—and managers might not realize—the smallest tasks quickly add up to wasted hours when they’re this frequent. If a task doesn’t need an analyst’s input, you should consider automating it.
5. Preserve Evidence. New regulations are making it more important than ever to preserve evidence during serious incidents, no matter what industry you’re in. Unfortunately, in the rush to prevent damage and close the incident, it’s easy to look at evidence gathering as a post-incident activity. Instead, companies should build procedures that gather and document evidence as the response process unfolds. This way, there is no need to search retroactively for data, plus you will be prepared if the incident turns out to be more serious than you initially thought. If you wait until after the incident is closed to get started, you’ll likely end up unready for potential legal or regulatory proceedings.
Stay tuned! In the next, and final, article in this series, I’ll cover the final phase: post-incident activity.
