5 incident response practices that keep enterprises from adapting to new threats

Security analysts within enterprises are living a nightmare that never ends. 24 hours a day, their organizations are being attacked by outside (and sometimes inside) perpetrators – hackers, hacktivists, competitors, disgruntled employees, etc. Attacks range in scope and sophistication, but are always there, haunting the security teams tasked with guarding against them.

To cope with this never-ending, ever-changing slew of threats, most organizations rely on established best practices to help them mitigate as many incidents as possible within the 24 hour or less window given to thwart most attacks. Yet, “established” and “best practice” by definition mean long periods of time were needed to develop them, most often after multiple encounters with a known threat. So how can enterprises expect to evolve at the same rapid pace as the cyber threat landscape by relying on practices that don’t adapt to real-time?

In short, they can’t. And even more alarming, most security teams know they are limited by standard security analytics and incident response methods. To rationalize these limitations, organizations measure themselves against their peers rather than against the threat landscape. Good enough security has become the standard in the hopes that there is a softer target out there that will satisfy attackers’ needs. But this attitude is leaving organizations more vulnerable than ever, and creating the following gaps in security posture:

1. Security teams are overwhelmed with tactical, reactive tasks, leaving little time to be strategic and preventative

Research by analyst firm ESG reports that when asked to identify their biggest security operations challenge, 35% of cybersecurity professionals said “keeping up with the volume of security alerts.” The report goes on to attribute this to the fact that “these organizations may not have enough security people or the right skills in place to separate the security alert wheat from the chaff, or the right processes to investigate and prioritize alerts in an efficient manner. Oh yeah, their technology likely needs tuning to eliminate some loose alerts while the alerts themselves need more enrichment, synthesis, and analysis to filter out some of the noise.”

2. Data streams get eliminated, and not always for the right reasons

Almost every point solution addressing a specific area of security architecture creates a data stream that is fed into a SIEM. Most SIEMs charge based on the number of streams, or the amount of data being ingested. Budget-conscience security teams often eliminate data streams deemed less important, or delay adding new data streams due to cost. This leaves the organization with blind spots.

3. Lack of correlation between events means attackers can A/B test to find weak spots

Most incident response platforms take SIEM data and create and prioritize incidents based on correlating factors. One factor often left out is historical data related to past threats, which means each incident is only a reflection of the current threat. This, combined with missing data streams means that hackers can attempt multiple tactics to find the weak spot without the organization connecting the dots between events and incidents.

4. Playbooks have good intentions, but are often used as a distraction

Most incident response platforms identify incidents and then trigger playbooks to mitigate and resolve the threat. Playbooks are made up of a series of tasks that are known to address specific incidents. While the playbooks guide the analyst in resolving the threat and workflows are automated, the actual tasks are still mostly manual. Also, this creates a standard response, which means hackers generally know in advance how organizations will respond to certain threats. Attackers then use this to their advantage by distracting security teams with known threats while initiating another that is likely to go undetected.

5. Threat analysis insights are siloed, and therefore not applied to future threats

Often times, analysts will generate insights based on incident mitigation and document findings that include unique insights and intelligence related to the incident. These findings are often put into Word documents and saved for reference. However, the findings are not generally shared broadly or accounted for within the incident response platform. This means that unless an analyst is specifically aware of the findings and knows where to find them, the intelligence does not get referenced during or applied to the next, similar threat.

To fill these gaps, security teams will need to adopt a new mindset in regards to security analytics and incident response practices. The first step is to put faith in technologies that do more of the work. Security analysts should be set up to do strategic analysis, instead of spending 70 percent of their time hunting in response to semi-qualified threats. And when I say that technology should be doing more of the work, I don’t mean in the sense of workflow orchestration, which only organizes the tasks for the analyst to still complete manually.

Advances in machine learning and applied sciences are making it possible to automate threat intelligence, make stronger connections between malicious events and resolve incidents faster, and with more accuracy by only requiring the analyst to step in further down the mitigation process.

The second shift must come in how organizations approach security data. SIEMs do a great job of ingesting security data and creating events, but lack the intelligence layer to make sense of the events and show the bigger picture. Incident response platforms are helpful at formalizing event data into incidents, but lack the ability to properly connect current incidents with historical data.

Enterprises will need to pursue technologies that act as a system of intelligence to provide a source of record for all security logic, add context to incident data based on incident relationships (past and present) and provide predictive security intelligence so analysts can focus on preventative measures rather than spending the majority of their time reacting to threats already in motion.

Finally, the biggest shift will be that enterprise security teams will have to accept that good enough security isn’t good enough anymore. While there will hopefully always be a softer target for attackers to breach, the goal of a security infrastructure should not be wholly reliant on this assumption. This will not be easy for many enterprises, since most security technology vendors stake their business on making it difficult to move away from their technologies, no matter how antiquated it becomes. Security teams should evaluate their technology stacks and see how they can make it more flexible and adaptive to address the threat landscape, rather than settling for simple being more secure than the next organization.