The threat management process in the cybersecurity field is more an art than a science, despite the existence of multiple theoretical models that can be applied to determine whether or not a risk exists for organizations.

This reality makes the topic not be seen as viable by cybersecurity officers in organizations. When the opportunity arises to apply a scientific method to the problem, we enter terrain that appears to be more of an academic exercise than a formula for treating a real and present problem. This makes it look, in the minds of administrators, like just another project from the security people that nobody understands. The fault here definitely lies with us cybersecurity professionals, as we do not have the skills necessary to communicate complex problems to management levels.

However, the notion that it is an academic topic with no real-world applications could not be further from the truth. In fact, the lack of formalization of a threat management system makes it much more difficult to justify budgets for security improvement projects, since we have not taken the time to scientifically prove the existence of the risk that such projects would be mitigating. This basically describes the vicious circle in which more than one security officer finds himself at the moment.

To clarify some of the doubts about the threat management system or model that we can apply, I next expose what I have been able to learn in recent months on the subject. This is part of a more comprehensive topic that I addressed in a previous post (lack of processes in IT).

The Internet Storm Center podcasts are usually very good and do not last more than 5 minutes per daily summary. I suggest you listen to them on your way to work (https://isc.sans.edu/podcast.html). Listening to this podcast, I came across a discussion about Threat Modeling and whether it was worth going through all the effort of trying to apply a scientific model to such a complex problem as threats, vulnerabilities, bugs, and everything this means for organizations. Whether this was better than continuing with the trend of creating panic every time a new vulnerability is revealed, with the hope that this keeps us relevant when requesting budgets.

A recent example of what was described above is the recent flaw discovered in the implementation of some email clients when using PGP for email encryption.

In summary, an uncoordinated disclosure of a supposed vulnerability in PGP occurred, and when the analysis is done, it is discovered that the flaw is in the implementation of some email clients and their integration with PGP, not in the encryption method itself. However, this did not prevent the news from spreading, sowing fear, uncertainty, and doubt (FUD for short) across the entire Internet.

We have a responsibility in our positions where the world really listens to us as experts when we identify exposures that have impact on real world things.

Creating alarm and hype for issues that aren’t extremely critical or impactful hurts that credibility. #efail

— Dave Kennedy (ReL1K) (@HackingDave) May 14, 2018

All this in order to gain credibility or reputation in the global information security community. It even has a website and a logo. This is just the most recent example, without forgetting Meltdown and Spectre at the beginning of this year.

These same techniques are typically used internally within organizations to “sell” security, without understanding that what we are doing is damage to the security community in general by presenting ourselves as unprofessional, reaching conclusions without scientific support or verifiable economic reasoning.

For this, threat modeling or Threat Modeling exists. Truthfully, the process is not complex, just long. But the final result is a level of risk calculated based on the reality of the organization for which the analysis is performed. Unfortunately, this is something that does not apply equally to everyone, so its implementation is different for each organization (no silver bullet). But the methodology can be the same. What I have been able to see so far is that the components seem to be:

  1. Threat modeling
  2. Threat classification
  3. System inventory
  4. Vulnerability identification
  5. Threat mapping

Threat Modeling

The most famous model is STRIDE, and it is just a matter of being able to classify threats into standard categories. That is, a computer system is vulnerable to one of the following threats:

  1. [S]poofing Identity
  2. [T]ampering with data
  3. [R]epudiation
  4. [I]nformation Disclosure
  5. [D]enial of Service
  6. [E]levation of Privilege

Some of these threats can be directly related to criminal behaviors such as unauthorized access, system abuse, fraud, among others.

Once we have clear the categories of threats we want to handle in our model, then we can continue with their classification.

Threat Classification

Originally used by Microsoft, the DREAD threat assessment model is now part of OpenStack and provides 5 categories for classifying threats:

  1. [D]amage (Potential damage)
  2. [R]eproducibility (Ease of reproduction)
  3. [E]xploitability (Ease of exploitation)
  4. [A]ffected users (Affected users)
  5. [D]iscoverability (Ease of threat discovery)

System Inventory

I think this explains itself. However, we must emphasize that we are not talking about CMDBs or any other inventory that operations might have for system management purposes. Rather, we are talking about equipment inventories produced by active discovery using security tools.

The reason for not reusing operations inventories is that they are generally outdated and serve a different purpose. These inventories serve us to correlate what is found on the network versus what we believe we have connected to the network. However, it is important that the security inventory is conducted independently.

Vulnerability Identification

This is more familiar territory for security officers, as almost all organizations have tools or services that allow them to conduct vulnerability assessments of the systems (inventoried in the previous step).

This is important but does not represent an end in itself, as we are missing the most important step.

Vulnerability Mapping

Assuming we have the inventory as up-to-date as possible, we have been able to identify the vulnerabilities present in systems with a certain degree of confidence, and that these vulnerabilities have been tied to a specific previously classified threat (STRIDE/DREAD), then we can add a financial component to the formula and estimate losses in case the threat materializes. Effectively estimating the financial risk related to threat management.

The process may seem long or tedious, but the truth is that it is very easy to reproduce once you practice it. Let’s say with the 5 most critical systems in the organization. Like any exercise, once you practice enough, it is very easy to extend its applicability to all systems in the organization.

Now imagine being in a board meeting and being able to perform a calculation on the spot related to the appearance of a new vulnerability and what this means in financial terms. I think this is a much better way to get funds and/or attention than creating panic in our organizations.

Agree! Causing people to run around like their hair is on fire yields little benefit.

— Jim Nitterauer (@JNitterauer) May 14, 2018