In the world of digital forensics and incident response (DFIR), speed is everything.

While costs of slow performance can be hard to assess in other professions, the consequences of sluggish IR are perfectly visible and devastating.

If you’re new to DFIR (or could use a review), here are five reasons why speed is critical for the incident responder  

1. Slow Incident Response Means More Stolen Data

Whether it’s company IP or personal identification information (such as Social Security numbers and credit cards), many cyber attacks are associated with stealing data.

The longer it takes security operations center (SOC) analysts and incident responders to detect, locate, and flush out an attack, the more time intruders have to detect, locate, and extract sensitive or valuable data.

Because an organization’s information is its most valuable asset, an uncontained attack poses an existential threat.

Stolen IP—leaked publically or directly shared with competitors—could destroy a firm’s competitive advantage and market position.

Stolen personal data—like the 2018 hack of 30 million Facebook user accounts—can deal hefty blows, reputational and regulatory.

2. Slow Incident Response Means an Entrenched Intruder

After breaking into a network, an intruder will often fight to maintain access through a number of entrenchment techniques.

While every corporate network is unique, they each have their dark corners: an endpoint (or space within one) into which the security team has little visibility.

If given time, an intruder can scope the network, identify blind spots, and create persistent mechanisms—intruder strategies for preserving network access (entrenchment). Two of the most common persistent mechanisms are backdoor installation and password theft.

The longer it takes to remediate an incident, the more time an intruder has to create an array of access points, and the less likely it becomes that all of the persistent mechanisms will be found during an investigation.

This can make cleanup almost impossible, indefinitely exposing the organization to intrusion.

3. Slow Incident Response Means an Alerted Intruder

Sluggish investigations run the risk of tipping off intruders, giving them time to cover their tracks and lay low. Taking an endpoint offline, reformatting it, or changing a password are among the IR activities that intruders could detect.

Once aware, they have three options.

The first option is to wipe their digital prints and flee. The quality of a DFIR team’s reconstruction of an incident relies on evidence, and most intruders who have the luxury of deleting their trail will do so.

Along with crippling an investigation, this exit strategy can result in the ruin of vast amounts of valuable enterprise data.

The second option is playing possum. If a DFIR team digs into an endpoint and learns an intruder’s key traits— where and when they log in—it will often monitor for that signal. But if an intruder plays possum, lying low and not logging in, then the value of that signal dies.

The final option is simple: smash and grab. An alerted attacker could be provoked into doing as much damage as possible as quickly as possible, be it stealing or destroying data.

In any case, an alerted intruder is the last thing an incident response team wants.

4. Slow Incident Response Means Disappearing Evidence

Evidence of an attack can exist in many places, and each place has a different lifespan.

Some evidence is stored in files and can survive for long periods of time and resist reboots.

Other evidence is only in memory and becomes lost when the computer restarts. This includes command lists, passwords, and hostnames that the intruder used during an incident.

Evidence can also be stored in unused regions of memory and disk that will get overwritten as the computer runs and needs to create new files and processes. Once overwritten, that evidence is gone.

Regardless of where the evidence is stored, its lifespan is limited. And the longer an investigation continues, the more likely the evidence will expire before a DFIR team can discover it.

5. Slow Incident Response Means a Dangerously Large Backlog

Incident responders field cybersecurity alerts from a variety of sources: security information and event management systems (SIEMS); host-based intrusion detection systems (IDS); network-based IDS; and intrusion prevention systems (IPS).

In order to effectively allocate a response, the incoming stream of alerts is generally triaged into six categories: baseline; low; medium; high; severe; and emergency. Afterward, incidents need to be investigated and closed according to the risk they pose, and at a faster rate than they are generated.

If not, a backlog begins to accumulate.

This isn’t particularly dangerous if the backlog is composed of lower priority alerts (such as baseline and low ), which are, generally speaking, the bulk of any organization’s cybersecurity incidents.

But if a high-priority alert (such as high or severe) makes its way into the pile, it opens an organization to all the dangers shown above, from more stolen data to an entrenched intruder.

Solutions to Slow IR

With the dangers in view, it’s clear that the effectiveness of IR depends largely on its speed. But how can an organization’s cybersecurity department speed up its response time?

To accelerate IR, the time required for each phase of an investigation has to be reduced. There are several phases in the IR process:

  • Detecting the incident (this is when the alert is generated)
  • Getting access to endpoint and network data to start the investigation
  • Analyzing the data to answer investigation questions
  • Scoping the incident and identify other endpoints that are involved
  • Remediating the incident.

We’ll cover how to speed up each of these milestones over the next few weeks.

Until then, consider a free trial Cyber Triage. It’s DFIR automation software that speeds up the entire IR process, from detection to remediation. Click here to start today.