Back to Basics - The Forgotten Goal of Security
Introduction
When thinking about modern security, lots of terms jump to one's mind - Adversary, Nation-State Threat Actor, APT (Advanced Persistent Threat), SOC (Security Operation Center), Detection, IOC (Indicator of Compromise), and many more.
Looking deeper into these terms, we can find a common narrative: the Attack. Who is the attacker, what are the TTP (Tactics, Techniques, and Procedures) used, how to detect in the future, etc.
But focusing only on those terms uncovers a crucial missing element - The Victim. With modern security, the vast majority of effort goes towards the aggressor, its motivation, its way of operation, and how to detect its moves. Still, the meaning of defending against it is not to stop the attack, is not to prevent the attack, it is to make sure the business is not impacted. Not being impacted doesn't mean there is no attack. It means the business' bottom line will
Don't get this wrong. We all agree that no attack is better than "suffering the least" because, well, there is no attack. The point I'm raising here is to evaluate the amount of effort that we spent on detecting and responding to an attack compared to the effort that goes to understand if such an attack actually will impact the business' bottom line. If we could know that a specific vector of attack is not risky enough to the business's bottom line, then its response might be completely different. But the fact is that every IOC observed in the SOC is handled with the same sense of urgency, even when accurate and valid detections can't affect the business.
The Goal of Security
So as an organization, what is the goal of security to me? Like with other pillars of the business, such as Marketing/Sales/HR/etc., the goal is to help the business thrive. This means that the purpose of security from the business perspective is to make sure that security threats will not impact the operation of the business. In more security-related terms, the goal is to reduce the risk of potential exploited threats to an acceptable level.
The Security Cycle
The organization is a living thing, with change of personnel, introduction, and retirement of technologies, and others, identifying the organization's risks, understanding their impact on the business, and finding the ways to reduce those impacts, is a never-ending process.
This cycle consists of four main stages:
Risks Identify
This stage aims to have a clear understanding of the business's leading processes, identify the Crown Jewels, and the meaning of impacting any of them. This work results in a threat modeling exercise that reflect the business processes flow in the systems, identifies critical areas for business operation, and highlights risks and their impact on the business in case they are exploited.
Because the goal here is to uncover any potential risk to the business, it is essential to identify any asset that can impact the business when referring to Crown Jewels. The actual impact can cause risk in different disciplines for the organization, like operational and brand, and therefore, the Crown Jewels can appear in many kinds of assets.
Such assets can vary from servers/desktops/laptops which hold sensitive information or are crucial to the business operations, to user accounts with broad privileges or unique privileges, pieces of data (like files with sensitive information, organization root/CA certificate, website files) and important systems (like the access management, HR, security system consoles and others).
Attack Vector Identify
Once we have identified risks, critical entities, and the business operation flows, we can start the fun game of "what if?". This exercise pinpoints where things can go wrong and understand their effect on the different risks.
The result of this stage is a forest of potential attack graphs that lead from external and internal entry points to the organization's crown jewels.
Probability Assignment
Now that we have risks and the different ways we could trigger them, comes the evaluation step. For each step in the attack forest, we want to highlight multiple dimensions like the likelihood of happening, distance from the crown jewel, ways to monitor and/or mitigate, and the complexity and cost of different mitigations.
At the end of this stage, we will have a forest of attack graphs, ending with prioritized risks, the many ways to trigger them, and multiple properties per step to leverage as a prioritization mechanism for selecting the next steps.
Reduce Risk Level
The last step tries to answer "What to do?". The goal here is to select the minimal set of actions to reduce our initial risks to an acceptable level. An acceptable level does not mean the risk is gone; it means that the impact of the risk when all mitigation actions are in place will not harm the business operation, or the cost of such a hit will be tolerable.
Mitigation actions can be a procedure, recovery plan, monitoring, placement of perimeter defense externally and internally, and many others.
Repeat
As we started, processes, technology, and business targets are constantly evolving, updated, and changing, which requires a neverending circle of monitoring and evaluating if some stage needs to be refired and continue the cycle.
Risk Driven Detection & Response
An exciting thing to point out is that there are no specific mentions of any security tools, technology, or processes in the discussion of The Security Cycle. This emphasizes that the core of security is one, and if so, the value of any security tool, technology, or process must directly impact the cure goal - To reduce business risk levels.
Our SOC faces many challenges, and a lot of the effort spent is on better detection, reducing False Positives (FP), faster triage, and more. But even if we reach a point where our FP rate is low, and triage of our noise takes seconds, the detection severity definition falls on the rule author's shoulders. In many cases, this author has an insufficient understanding of the business, its processes, and its risks.
Back in the early 2000s, when CVSS (Common Vulnerability Scoring System) was released, understanding that the same security issue should be considered differently when it exists in two different locations in the org was a true eye-opening moment. Until that moment, when a new vulnerability was introduced, the severity of it was determined by the threat researcher. This practice was the cause that the same vulnerability detection in two different vendors could raise different severity alerts. CVSS introduced a new way to think about scoring. At the core of it, there are 3 dimensions:
- Base - defined by characteristics of the vulnerability (e.g., does authentication required, is it remotely accessible)
- Temporal - defined by characteristics that may change over time (e.g., is a POC exists, does patch exists)
- Environmental - defined by characteristics that impact the organization (e.g., numbers of impacted assets, potential damage)
CVSS created a standard way to align security meaning and, thus, have one security score. And still, the fact that an unrelated piece of information, the environment, impacts the severity of the vulnerability was mindblowing. What I’m suggesting here is to do the same. We need to leverage the business risk models and apply them as a critical component when prioritizing the detection and response work. A TP in one system is not the same as in another if one system is not essential for business operations, but the other is. Compromising one device or user with no access to any critical information or rights is entirely different from compromising the machine or user of the domain administrator.
Conclusion
As security vendors and practitioners, we should realize that our Kung-Fu is strong only as of the impact and value we can provide to our customers/organizations and their goals. We should not operate in a vacuum and aim to integrate business understanding into any aspect of our products.