Defining Incident Scope
Why do so many security teams talk about incident response (IR) without first determining incident scope?
Incident scope is the result of all investigative activities that kick off an incident response action. It’s the point where an analyst feels comfortable that all affected computers, servers, accounts, and associated services that are part of a single threat’s activities inside your network have been identified. Sometimes it’s an alert that led an analyst to look for follow-on activities, and other times it’s the result of investigative work that linked a series of previously unrelated alerts from different systems. For many enterprises with structured process, this is investigation & fusion/correlation that happens during Tier 2 of SOC workflow.
In many cases, an incident is limited to a single computer. But taking that mindset by default, not running a sufficient investigation around each alert, means threat presence may still exist after the alerted host is triaged.
What if the scope of an incident is not clearly determined prior to an incident response action?
When a threat is targeting a specific enterprise, they’ll take any available path in to gain an initial foothold. They probably didn’t land exactly where they wanted to, which means internal reconnaissance is initiated to find what they’re looking for. It usually starts with scraping credentials, allowing the attacker to start “living off the land” by abusing native operating system functionality. This process can take hours, days, weeks, or longer.
If a threat is borrowed in your network, it means you have something of value that they want. If it’s that important to them, expect they’ve developed ways to persist for an extended period of time. Cleaning a single infection could tip them off that you’re on their trail, forcing them to find other ways to maintain a presence until they find what they want.
How can security teams do better?
One of the deficiencies we’ve witnessed in enterprise security is the ability to quickly aggregate the relevant data necessary to make an assessment as to the complexity of a threat’s activities. The volume of alerts is overwhelming well-resourced teams, destroying any hope of productive work and holistic results.
In an attempt to keep pace, many teams focus on the quantitative work of alert triage as opposed to the qualitative work of validating unique threat groups inside a network. Team performance is typically measured based on the number of alerts handled, but this doesn’t translate to effectiveness (more on the broken state of security metrics another time).
Aggregating the right data to make better decisions is crucial to getting in front of an incident. If an analyst is forced to query data from different places, then manually align it to tell the narrative, you’re giving the threat time to evolve. Evaluate what questions you’re trying to answer -- quickly -- and ensure the underlying data necessary to make decisions is aligned and easily accessible.
Treating alerts like a break-fix action, reacting without investigating only gives the illusion of security.