Bug Bars and STRIDE-based Calibration

February 20, 2020 — Leave a comment

The previous article in the Threat Modeling vNext series has introduced the concept of Residual Risk and has discussed how selecting the correct mitigations is key to optimize it. We concluded observing that not all mitigations are equally important and that it is important to calibrate their evaluation referring to the actual concerns the organization has related to the assessed solution. This new article is focused on this topic and introduces a practical approach that although not as rigorous as others, still provides a lot of value, so much that it could be considered good enough for most purposes.

I have personally applied this approach multiple times. It is a qualitative evaluation of the risk, based on a Bug Bar and on a STRIDE-based calibration. I have introduced the concept of the Bug Bar already with a previous article in the series, therefore I am not going to describe it again here, but you may recall that a Bug Bar is a strict definition of each Severity level.

Instead, STRIDE is Microsoft’s own categorization of Threats. STRIDE is an acronym from the initials of

  • Spoofing, which identifies impersonation attacks;
  • Tampering, related to changing data maliciously;
  • Repudiation, when it is not possible to identify the author of some misdeed;
  • Information Disclosure, which occurs when confidentiality is violated;
  • Denial of Service, related to limiting or preventing legitimate use of the service;
  • Elevation of Privilege, which is about getting more rights than you should possibly have.

STRIDE-based calibration means that, before actually starting the Threat Modeling exercise, you would ask your counterparts (typically the stakeholders or the Architects) to order the STRIDE categories from the one representing the greatest concern for the solution at hand to the one representing the smallest concern.

It is very important to let them understand that you are not asking for guessing which category represents the highest risk for the solution: that would be discussed during the Threat Model. No, what you are really asking is what they care about the most, what they feel would cause the most damage.

While it is important to get the list ordered correctly – otherwise you would risk assigning the wrong priority to the identified threats – small errors do not typically mean big consequences, because the prioritization is done based on the severity of the Threat, which is assigned based on multiple factors including the Bug Bar. In other words, this process consists in the identification of a base severity, calculated by applying the Bug Bar, and then apply small adjustments due to the STRIDE-based calibration.

Another factor that would help getting it right is the consideration that not all categories in STRIDE are equal. For example, Information Disclosure, Tampering and Denial of Service are typical attacker goals and are associated to the famous security triad “CIA”, which stands for Confidentiality, Integrity and Availability (see https://en.wikipedia.org/wiki/Information_security). This means that you should expect those three to be right at the top of the STRIDE prioritized list provided to you as a result of the calibration, and you should really understand if there is any reason why it would not be true.

Let me give you a practical example. Let’s imagine that our Bug Bar is as follows…

CriticalCritical Severity. It is related to the most important issues, which could cause a catastrophic failure of the solution and critical damage to the involved counterparts.
HighHigh Severity. It is related to important issues that may cause major disruption and thus should be seriously considered.
MediumMedium Severity. It is related to issues that should represent some concern and thus should not be overlooked.
LowLow Severity. It is related to minor issues.
InfoInformational only. It is related to mitigated issues or to topics that are included for completeness.
An example of Bug Bar

… and that the STRIDE calibration has identified this ordered list:

  • Tampering
  • Information Disclosure
  • Spoofing
  • Elevation of Privilege
  • Denial of Service
  • Repudiation

You have asked the stakeholders why they feel Denial of Service being so low in the list and they have answered that it is because no strict SLA has been defined. That’s fair enough, and so be it.

Now, you identify the following two threats among the others:

  1. Data Transferred from the user to the solution may be tampered in transit by a malicious user.
  2. An attacker may perform a DDoS attack on the solution, causing it to become unavailable for legitimate users.

Based on the Bug Bar and on the characteristics of the solution (for example: what data it deals with, what is the business sensitivity and so on), you understand that both risks are High Severity, then you apply the STRIDE-based calibration and decide that the first issue is Critical, because it is clearly about Tampering; the second threat can instead be re-evaluated to Medium, considering that Denial of Service is a secondary concern.

At this point, I have to disclose that I am not a big fan of Threat Categories like Microsoft’s STRIDE, because I have seen too much energy wasted trying to get it right and very little return for the investment. Matter of fact, I have not used STRIDE besides for the STRIDE-based calibration approach for a couple of years, and I do not feel my work having been diminished by this in any way. But the STRIDE-based calibration still makes a lot of sense, because of its simplicity.

We have covered a lot for this week, but we have still a lot to do. Matter of fact, we have barely scratched the surface about Threat evaluation and we could expand the discussion to advanced topics like the Quantitative Risk Analysis, but for now we can call us satisfied.

Next week we will continue our introduction to Threat Modeling vNext with the evaluation of Mitigations.

No Comments

Be the first to start the conversation!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.