“56% of breaches took months or longer to discover” was one takeaway from the recent Verizon DBIR 2019. Unfortunately, this is not earth shattering news. The current state of time to detect and respond being unacceptable across the industry, regardless of who you ask.

In many cases it represents a reality that security teams need to face and prepare for. While we often look at the depth of discovery, or ability to detect, as a measure of security, we tend to ignore the element of time- retention.

One of the great Gartner blogs by Anton Chuvakin where he brings a valid point (and remains strong even 6 years after published) is “if a detection lag period is longer than an evidence retention period, which one do you improve? do you store data for a longer period or do you improve your detection capabilities?”.

“ARE WE BREACHED?”

Detection is critical, whether in real-time, enforcing preventative controls against known malware, or uncovering advanced adversaries with unknown TTPs and zero-days. However something else comes to mind reading’s Anton’s blog. The number of times security teams needed the data to complete a compromise investigation, start-to-finish across the entire organization, was simply not there. Let me repeat that, the data wasn’t there.

There’s an impression in the general public and senior management that there is a screen somewhere that is either red or green, showing if a breach has occurred. The fact of the matter is that breaches and impact have to be calculated, and it’s an imperfect science with poor data to work with. Security teams are accountable to provide clarity to these questions: “Are we breached?”, “Are we impacted?”. However where clear answers are vital, security teams are (too) often left with open-ended questions. Why is that?

Let’s walkthrough each of the data sources most often available and used by security teams during an investigation (assuming detection occurred), and their implications on the incident response process — specifically focusing on “months or longer”.

While Security Information and Event Management (SIEM) systems provides security analysts rich set of functionality, one of the main drivers for SIEM deployment and management remain compliance mandates. As of such, data retention best practices are being driven from what’s required vs. what’s needed. Both in terms of data collected and its respective retention period. PCI DSS is a good example for a mandate vs. detection, investigation, and response required. In the case of SIEM systems, there are two aspects to consider: metadata available for query vs. data archived in cold storage (or simply deprecated…), and the time it takes a security analyst to hunt through each.

systems provides security analysts rich set of functionality, one of the main drivers for SIEM deployment and management remain compliance mandates. As of such, data retention best practices are being driven from what’s required vs. what’s needed. Both in terms of data collected and its respective retention period. PCI DSS is a good example for a mandate vs. detection, investigation, and response required. In the case of SIEM systems, there are two aspects to consider: metadata available for query vs. data archived in cold storage (or simply deprecated…), and the time it takes a security analyst to hunt through each. With Network Threat Analytics (NTA) & Network Forensics , which the value added during incident response is clear, capturing and storing full packet capture is expensive and therefore limited to 2–4 weeks (of only inbound/outbound, excluding east/west) worth of raw data and best cases a couple of additional weeks of metadata. In this case, regulations are not playing a role (yet) but impact on machine power to process petabytes of data and as mentioned cost are an Achilles heel.

& , which the value added during incident response is clear, capturing and storing full packet capture is expensive and therefore limited to 2–4 weeks (of only inbound/outbound, excluding east/west) worth of raw data and best cases a couple of additional weeks of metadata. In this case, regulations are not playing a role (yet) but impact on machine power to process petabytes of data and as mentioned cost are an Achilles heel. Cloud-delivered applications (SaaS) of any type whether SIEM, NTA, EDR, UEBA, etc. has it plusses and minuses as well. No need to mention the (lack of) management and deployment pain aspects involved, however the cost of data has shifted to the application side and there is no appetite to “start buying boxes” and pay for all of that data stored. and yet again, we are back again to “months or longer” of time period where data is simply not there.

WRONG DATA — OVERFLOW. RIGHT DATA — MISSING.

React fast with high precision is what expected from security teams during a potential breach investigation. However, reality proves that security analysts are bombarded with long, manual, and time-consuming tasks preventing a speedy response. One of those major roadblocks is data does not exist or limited data is only available in cold storage making, yet again, the task at hand hunting and correlating siloed data points almost impossible.

Problem starts with either having the (right) data or obtaining access to archived data, but that is only half of the battle. Let’s for a moment assume we have years worth of data available at our disposal, would that be sufficient of would that be, again, only a good starting point? Having had the “pleasure” of sifting through raw, non-indexed data trying to find that needle-in-a-crater™, I considered myself very lucky if I was able to find exactly what I was after, but most times that was close to a mission impossible.

Let’s use a concrete example. A new large scale adversary tool was detected. At that point, security teams across the globe are asking themselves, as well as being asked by their executives, if they are impacted by this new tool. In this case, doing CTRL+F for the C2 IP, executable hash file, or baddomain.com will not do the trick. A more sophisticated way of hunting for TTPs is required to uncover any bread crumbs left by that adversary tool and in case relevant, identify how widespread the attack is across the organization. In this case, query history data with the purpose of identifying attacker TTPs is critical.

Forward-to-the-past with future-proof intelligence

In Back to the Future, Marty McFly was a pioneer applying future-proof intelligence during history time, he could not make any changes without “future repercussions”, the exact opposite (Forward to the Past?!) is what security teams need in today’s world. Going back in time, without any limits, applying today’s available TTPs & IOCs intelligence and uncovering the attacker “tells” regardless of the specific TTP, the specific machine, or the specific time frame.

Circling back to our initial point that with mega data breaches as the norm, as much as we don’t like it, we are tasked more often with solving the question of “Are we impacted by this new breach? I need an answer ASAP”.

Equipping teams with the right data at the right time with all the then-current and now known context is the name of the game. This is about targeted surgical recall with the ability to replay the world as it was then with what we now know with the benefit of future knowledge.