Lowering The Poverty Line Of Incident Response

Home » Sled Meta Blog » Incident Response » Lowering The Poverty Line Of Incident Response

Over the years I’ve been part of monumental projects using several forms of technology, including SIEMs, in attempts to offset the talent gaps that plague the Information Security industry and shorten the “dwell” timeframe of attacks.  Taking a moment to define the anticipated goals and define the problem space, I find it necessary to state that properly launching a SIEM and similar technologies isn’t trivial and gaining a meaningful return on the investment is a significant challenge. Personally, I determine that return on investment to be a reduction in MTTD (Mean Time To Detection) and MTTR (Mean Time To Remediate).

The ultimate goal is revealing actionable intelligence that takes into consideration the true risk posed to the business and weights the alerts in that light.  This task cannot be achieved by leveraging and applying “threat intelligence” feeds as the primary form of correlation. Instead, it requires developing context around the core assets, networks, and layers of security controls that comprise the network.

In and of itself, this isn’t an easy problem to solve as businesses and their networks develop organically, as opposed to the more traditional networks created in the past.  This matters as demand for an urgent business needs drives the need for additional computing resources, leaving security as an afterthought.  This makes building contextual solutions around security problems a near impossible feat for most organizations.

Coincidentally, this is where SIEM implementations often fail. The concept of the SIEM is sound, but most implementations make decisions based on single, atomic events that are universally weighted.  This could be the match of an IP address or similar. This fails as security incidents are not singular, but more often contextual and long-playing.  Often I’ve been asked, “If we had signatures for Pass-The-Hash attack binaries and we used UAC, why were we breached? We had controls!”. 

Simply stated. This is a significant problem to solve.

The tough truth is the evolution of our networks and the way organizations communicate accelerate faster that the limited amount of resources the organization has to apply. So, just hire more professionals, right?

Here’s the harsh truth. Developing a proper Security Operations Center takes well over a year on average, and that’s just to nail down the basics.  Once developed, you will need a minimum of 8 well-trained engineers and a Sr. Security Architect to maintain the ability to respond 24/7/365, with ever-evolving breach detections. 

So, what’s the solution?  

In fairness, there isn’t a single one-shot answer for this.  However, I can offer the following advice that can greatly improve the security posture of an organization. 

Maintain a clear understanding that a threat is not just the presence of events, but also the absence of events. A phishing email with a malicious binary is certainly interesting, but so is the failed synchronization of an HA or failure of vMotion Snapshots.

Acknowledging that breaches can remain active for over 100 days, a platform that collects artifacts at the lowest level of ground truth and hold that evidence for hundreds of days, is becoming a requirement.

Threat Intelligence feeds are not the glue that binds together a security platform.  They are simply atomic indicators that can be applied to network flows. That’s not to say there’s no value in these sources of data, but a need to correlate those indicators with other sources.  Additionally, more Threat Feeds isn’t the answer.  It is far more valuable to choose the proper feeds for your environment and prevent as much overlap as possible.

Leveraging platforms, such as PacketSled, that apply multiple sources of enrichment to wire-level data, can provide greater confidence in incident relevance and the reduction of false-positives. For example, a Threat Intelligence match for an Apache attack methodology likely doesn’t represent a true threat when leveraged against a Windows environment.

We need to rely less on signatures and leaning more on User and Entity-based behavioral analytics. This isn’t an easily applied solution, but one that establishes dynamic baselines on observed behaviors with entities, allowing it to determine anomalies.  Anomalies could be determined as user accounts conducting database queries after midnight, which could not symbolize a threat, but an indicator worth additional investigation.

A means of properly prioritizing cases in a meaningful and actionable way. This is a tough problem, but one that will maximize the limited resources an organization has available. 

What’s the overall message in this?  Security is hard. It’s less the process of efficiently identifying the probable state of all enterprise platforms and users, but more so with identifying and understanding the applied risk of all possible operational states of systems and people. 

 

Reach out today and learn what we are doing to help you close the gaps and lower the poverty line in Incident Response.
in Incident Response, Security Research by Patrick Kelley Comments are off

© 2017 PacketSled, Inc.