Incident Response and the Need for Speed

This blog was originally published on Vectra.ai

When a cyberattack occurs, most aspects of the threat are not under the control of a targeted organization. These range from who is targeting them, what is the motivation, where and when the attack occurs, how well-equipped and skilled that attacker might be, and most critically, the persistence of the attacker to achieve the ultimate goal.

The only thing under the control of an organization is how quickly they can detect and respond to an attack.

Cutting short attacker time and access to critical assets is a paramount risk mitigation investment. The less time an attacker has access to resources, the less likely the damage or impact to the organization.

Reducing access time also increases attackers’ costs and forces them to develop new techniques and ways to adapt to reach their goals. The longer it takes an attack to succeed, the lower the return on investment to the attacker.

That is why mature incident response process provides the benefit of faster response to reduce the amount of time an attacker has access to organization resources.

Incident response metrics: Measuring risk across time

Everything in a mature incident response plan should be oriented toward limiting the time and access cybercriminals have during an attack. The way incident response is measured should directly correlate with that requirement.

Time is an effective criterion for quantitatively measuring and communicating the value of an investment in people, process, and technology as a form of business risk mitigation.

At an organizational level, dwell-time – the duration a threat actor has in an environment until detected and removed – can be measured accurately in a thorough investigation.

After an initial infection, all breaches follow the same blueprint of attackers gaining privileged access, extending the compromise across the network, and stealing or destroying data. This provides a clear understanding of where cybercriminals spend their time in the attack lifecycle.

Dwell-time provides a high-level metric that is quantifiable and can be leveraged to calculate the effectiveness of a security strategy and overall posture. Many organizations now track industry dwell-time benchmarks published in reports that can be used as a meaningful baseline to measure against.

To measure people, process and technology in a security operations group, time metrics based on visibility, tool efficacy, and team performance work well for simple measurements. These include three key areas of time.

Time to detect. The time it takes to become aware a problem exists in an environment and an alert is raised. While often the most cited metric, detecting an incident is not the same as knowing what is important.

This metric helps with understanding the scope of the attack surface and how quickly detection tools and threat hunters can find a problem.

Time to know/acknowledge. The time between an alert being raised and when an analyst acknowledges that alert as a risk and begins an investigation. Where time-to-detect provides threat awareness, time-to-know is central to risk awareness.

Most SOCs are overwhelmed with alerts and struggle with assigning priority and severity to incidents. This means time is wasted investigating false alarms. Time-to-know gives insights into tool efficacy to prioritize threats with meaningful data in the context of risk.

Time to respond/remediate. This helps with understanding team performance and how well they are limiting the time attackers have access to the environment.

The core goal of incident response is to reduce attacker dwell-time as a form of risk mitigation but organizations must first define the level of risk to be mitigated. It is important to consider incident response maturity and capabilities in relation to threats relevant to the business and the scope of impact these threats can create. Business risk awareness requirements define metrics and security spend to achieve appropriate response times.