Due to missing asset information, incident response is often challenging

Incident investigations often lead to dead ends, as asset information is often missing, including asset ownership and overall relevancy. In combination, these issues make it challenging for responders to determine what to do when they validate a compromise. 

First, it is difficult to comprehensively identify all available log sources for an asset with no associated context. Yes, analysts can and often do refer to the standard security appliances they know they have, to “check their traps” (web proxy, firewall, endpoint detection and response, intrusion prevention and detection systems, etc.). However, without understanding what the asset is and how important it is to the business, they may miss some of the most critical sources for validation.

Consider a SIEM alert or notification of a known bad IP address establishing a TCP connection with an enterprise IT asset. Say that the asset is actually an application server and the attack vector is on the application. Without immediately having the asset information available, the analyst would not know to reach out to the application team for the corresponding application logs where the attack would have been evident. Additionally, CRIE enrichment would have made the application’s criticality evident, garnering immediate attention versus sitting idle while the analyst works in chronological order. 

The other question that Level 2 analysts try to answer is whether or not the activity noted in the finding is normal or expected behavior. It can be exceedingly difficult for SOC analysts to understand what is normal or expected for enterprise traffic, especially when considering an individual asset or cluster of assets in isolation. Yes, they can look at historical patterns in network traffic, but that is a manual, time-consuming effort and still doesn’t account for unexpected traffic deviations (such as the introduction of new assets, maintenance windows, new business processes, etc.).

The evolution of machine learning in threat detection technologies has helped in this regard. But even so, machine learning requires time to learn behavior patterns, and lack of context can incorrectly train the algorithms, incorrectly influencing the data science and resulting in false positives that require systematic tuning. Comprehensive CRIE enrichments can alleviate some of this burden. Analysts reviewing the alerts can quickly determine what may be normal or expected traffic for an asset, or even help to determine whether the exploit was, in fact, correctly targeting the asset.

Consider the application from the previous example. If the CRIE data included vulnerability information for the asset, the analyst may have been able to quickly determine if there was a likelihood of compromise, even before sourcing the application logs from the I&O team.

These analysts, also known as L3s, are responsible for reviewing the investigation findings and qualifying the true-positive nature of the incident, validating the event categorization, confirming the incident severity level and escalating to the incident response team for containment and resolution. They require high-fidelity information to refer the event to the incident response (IR) team. Without asset context, the alert from the previous example would have just been a TCP connection from a known bad IP address on an enterprise asset, with no additional information. The SOC would have likely recommended, through due diligence, an escalation because of the established TCP connection. However, none of the additional information would have likely been collected, at least not without significant delays to the L3 for qualification.

The L3s also have the responsibility of establishing and validating incident severity, which helps prioritize the IR team’s workload, as well as establish the appropriate metrics for executive reporting and, in some cases, compliance requirements. Not having CRIE enrichment can, and often does, adversely affect SOC analysts and ultimately, the organization. If analysts do not know that the asset is hosting a vulnerable, businesscritical application, this will affect how they escalate the event and assess its severity. Collectively, this can cause a snowball effect, as the IR team will likely not prioritize the incident in accordance with its significance, as per the L3’s recommendation.

Through the investigative process, SOC analysts can (at times) source the relevant information about an asset and its risk. However, the time it takes to get the information is typically longer than the business would tolerate for their most critical assets, and that is the underlying issue.

There is also an unintended consequence to not enriching with CRIE: improper metric measurements. Some metrics have become commonplace within modern SOCs, such as mean time to detect (MTTD), mean time to contain (MTTC) and mean time to resolve (MTTR). Service-level objectives and/or agreements (SLO/SLAs) are measured against these metrics for the identification of adherence or violations to policy. 

Without asset context readily available, the probability of SLO/SLA violations can increase exponentially. As an example, an organization with an MTTR of 24 hours for a critical asset may very well violate their SLAs if it isn’t known that the asset is critical. In this case, the IR team may not receive the incident until Day 2, 3 or longer. The same can be said for MTTD and MTTC; essentially, if it’s not immediately evident, the alert will sit in the queue waiting for its turn to be worked, and the performance measurements will follow suit.

Many organizations today leverage a variation of hybrid SOC deployment models, where the provider is responsible for a portion or all of the detection, investigation or response. However, they should still be held accountable for reporting these metrics and ensuring adherence to the organizationally defined SLAs; the impetus remains the same regarding the utilization of CRIEs. (For more information, see Quick Answer: What Key Questions Should I Ask When Selecting an MDR Provider?).