The Blindspot of the Detection & Response Market

The blog post “Back to Basics - The Forgotten Goal” discussed the purpose of Business Risk Awareness and how it should be integrated when designing detection and response procedures. That discussion started with a simple mission statement for security - Ensuring a security situation will not impact the business. 

One way we can evaluate the readiness of our detection and response procedures is by trying to answer the top three questions of an active incident response process:

Incident Response Top Priorities

What Happened?

This question aims to help the incident responder gain containment of the situation. Understanding what happened, the responder will uncover the persistence and propagation mechanisms leveraged by the adversary. Different incident responders will follow different paths to reveal the Tactics, Techniques, and Procedures (TTPs). This investigation will detail the attack process from patient-zero until the present.

Why Do We Care?

By initiating an incident response process, it’s evident that we care. But if we take a few steps back, we can try to answer this question from multiple perspectives. One will evaluate the business process at risk. Does this finding affect a critical/valuable business process? Will a revenue process be hurt? A different perspective will determine if there is any data loss, which means that a liability issue is emerging that requires specific legal actions. In the end, the goal of answering the “Why Do We Care” question is to understand the level of urgency and attention this incident requires

What to do?

Understanding what happened and why it’s important to the organization allows us to set up an action plan. The answer to this question has two goals: (1) understanding the steps necessary to return the system to an operational state and reduce any additional revenue effect (2) mitigating steps to remove any residue of the attack and hardening actions to improve the organization's security posture for future resistance.

Cybersecurity Framework

Now that we know the top priorities for incident response, it could be argued that answering the question “do we have the right data?” and the previous questions is a vital sign for a healthy cybersecurity program.

In 2014 the National Institute Of Standards And Technology (NIST) was guided by the Cybersecurity Enhancement Act, among other things, to define a cybersecurity framework. NIST published the Cybersecurity Framework (CSF) 1.0  in 2014, a revised version 1.1  in 2018, and working these days on version 2.0. 

NIST leveraged existing standards, guidelines, and practices to create a framework that uses business drivers to guide cybersecurity activities. Even though the framework was designed to address critical infrastructure risks, organizations in any sector can leverage the steps and guidelines of the CSF.

The framework consists of 3 parts - Framework Core, Implementation Tiers, and Framework Profiles. The Framework Core material into five Functions:

Identify - "Develop the organizational understanding to manage cybersecurity risk to systems, assets, data, and capabilities."
Protect - "Develop and implement the appropriate safeguards to ensure delivery of critical infrastructure services."
Detect - "Develop and implement the appropriate activities to identify the occurrence of a cybersecurity event."
Respond - "Develop and implement the appropriate activities to take action regarding a detected cybersecurity incident."
Recover - "Develop and implement the appropriate activities to maintain plans for resilience and to restore any capabilities or services that were impaired due to a cybersecurity incident."

EDR Capabilities VS. CSF Functions

By design, the CSF should be able to answer any cybersecurity-related question, specifically the three incident response questions - What happened, Why do we care, and What to do. By evaluating the EDR's ability to cover CSF, we could understand its ability to answer the original three questions.

It is expected that the green CSF Functions will be Protect and Detect. Endpoint telemetry collection, threat detection, and auto-response (block/terminate a process operation) are the bread and butter of EDR. With the neverending creation of new attack vectors, technologies to be exploited, and many other factors, there will always be a need to continue and innovate. But from the perspective of the CSF, those two Functions are covered. And with good detection in place, we can provide the incident responder with the data to answer the “What happened?” question.

EDR is not a one-stop-shop for all cybersecurity; therefore, one could argue that Recover should be red in this case. Recovery steps include a rollback of system and data, hardening, and other activities that are out of the scope of EDR. In some cases, solutions like SOAR (Security Orchestration, Automation and Response) can lead the effort. Still, it will be outside the EDR's responsibility, and therefore, the red color on Recover.

In CSF, Respond talks about the different actions required to take in dealing with cybersecurity incidents. Those actions facilitate the process of understanding the threat (“What Happen?”), incident containment and future planning for threat eradication and system recovery (“What to do?”). The incident response process requires multiple tools to handle containment, threat eradication, and recovery. And even though many vendors provide tools to take local actions and artifact extraction, the process is manual and with minimal to no guidance. This is the main reason why Respond is yellow. The market acknowledges and provides help for this Function, but there is still lots of work to be done.

The Blindspot

We started with three questions that reflect the goal of an incident response process - What happened? Why do we care? What to do? We talked about NIST CSF, and its five Core Functions - Identify, Protect, Detect, Respond, and Recover. We ended with mapping EDR capabilities to the CSF Functions.

At this point, we understand how to answer two of the three questions and how the current EDR market’s capabilities help us.

The third unanswered question is, “Why do we care?”. This question points us to the center of the prioritization challenge in the EDR market. We think we found something bad, but this reflects on a security situation, not a business risk. Understanding the risk associated with this detection will dictate the level of urgency and leadership attention required to address this finding. The fact we found something with malicious intent doesn’t mean we need to enter DEFCON1 , just like a low confidence detection should not be ignored completely.

As stated before, the “Why do we care?” question aims to refine the urgency and attention levels to the situation. The way to answer this question is to understand what can happen to the business due to the detection - service availability issue, data loss, data breach, gaining higher privileged accounts, liability associated with this issue, and other issues.

The first Function of the CSF is Identify. The goal of this function is to understand the organization, and understanding an organization requires understanding its risks, being aware of its assets, and the corresponding business relations.

The ability to answer this question is the EDR market’s blindspot. Deep knowledge of the attack surface, new technologies and their corresponding attack vectors helps us detect malicious intent. Still, in the end, our prioritization mechanism solely depends on the threat author's feeling towards the threat’s importance with some combination of confidence in the detection.

Business Risk Awareness

Security providers need to add Business Awareness to Detection & Response. Even though one can understand the detection in Detection & Response as business understanding alongside threat detection, perhaps it’s time to double down on the need to have business meaning before detecting threats.

Instead of thinking about two steps - Detection and Response - we need to break the paradigm into a complete awareness cycle, the Business Risk Awareness cycle.

Business Awareness

The Business Awareness step aims to identify the different business components and their state. Examples are business crown jewels tagging, risk assessment, asset awareness (e.g., detection, role assignment, criticality, management), interactive visualizations, and more. Each capability can be discussed in more detail. Still, from a high level, the goal is to know your organization, its risks, assets, and processes.

It is essential to highlight that assets can represent machines (laptops, servers, cloud elements), user accounts, or digital elements (E.g., files, emails).

Risk Mapping

The Risk Mapping step aims to take risks and assets from the previous step and connect them into one graph. The result will be an interactive map of the organization, the different relations between assets, and the paths the organization’s crown jewels could be accessed, emphasizing risk vectors.

Probability Assignment

In this step, we’ll take the risk map and try to place risk probabilities. The idea is to create a weighted connected graph representing the probability of an attack taking a specific route.
The probability assessment includes the detection part of Detection and Response. Still, it expands its scope. It provides threat detection but also best practices monitoring, anomaly detection, and more techniques to evaluate the risk states of nodes and edges.

Risk Mitigation

The goal of this step is to take actions to reduce the overall organizational risk. Because business risks now drive us, we can monetize the meaning of each risk path. This way, our decision mechanism won’t depend solely on the threat author's ability to detect an atomic security situation. Instead, we can consider the business meaning that each detection could influence. This will help reduce the urgency behind “high severity detection” and raise the awareness of “low severity detection,” which leads the way to the high-cost risks.

Moreover, looking at the entire path of the risk can help us locate critical areas for mitigation. Because exploitation of risk requires multiple steps, mitigating a more straightforward issue that breaks the risk connectivity might make more sense instead of dealing with higher severity issues that do not dramatically reduce the total risk path probability.

Like Probability Assignment includes the detection part in Detection and Response, the response concept is included in this part. Risk Mitigation actions can be as simple as software updates, account configuration, and even an incident response process. All of those are actions to deal and mitigate risks.

Conclusion

The EDR market is over-fixated with the desire for Threat Detection and Alert Fatigue. Still, the security world and customers desire a more complete business-driven actions and prioritization mechanism. The business's bottom line is its revenue, profits, and future growth. Explaining security needs by clarifying how the business's bottom line can be impacted is the way to ensure security is one of the organization's top priorities.