Written by Laurent Dupont

Threat Modeling Insider Newsletter

37th Edition – September 2024

Welcome!

By the time this newsletter lands in your inbox, we’ll be at ThreatModCon San Francisco! As a result, this month’s edition won’t feature a Toreon article. But don’t worry—we’ve packed this issue full of exciting Threat Modeling content!

Our guest article, penned by Mohamed Abo El-Kheir, explores the friction often encountered during DevSecOps adoption and highlights how Threat Modeling can be the key to overcoming these challenges.

Make sure to stay tuned for next month’s edition, where we’ll share insights and highlights from ThreatModCon.

But that’s not all! Let’s dive into what else we have in store for this month’s edition:

Welcome!

y the time this newsletter lands in your inbox, we’ll be at ThreatModCon San Francisco! As a result, this month’s edition won’t feature a Toreon article. But don’t worry—we’ve packed this issue full of exciting Threat Modeling content!

Our guest article, penned by Mohamed Abo El-Kheir, explores the friction often encountered during DevSecOps adoption and highlights how Threat Modeling can be the key to overcoming these challenges.

Make sure to stay tuned for next month’s edition, where we’ll share insights and highlights from ThreatModCon.

But that’s not all! Let’s dive into what else we have in store for this month’s edition:

On this edition

Guest article
Threat Modeling Is What Puts “Sec” in “DevSecOps”, written by Mohamed Abo El-Kheir

Curated content
Putting Threat Modeling into practice: A guide for business leaders, written by Scott Wheeler

Curated content
How the New EU Regulatory Landscape Will Impact Software Security, written by Nuno Teodoro

Curated content
Threat Modeling with ATT&CK v1.0.0

Tips & tricks
Crypto-Gram Newsletter

Training update
An update on our upcoming training sessions.

Guest article

Threat Modeling Is What Puts “Sec” in “DevSecOps”

Written by Mohamed Abo El-Kheir

“DevSecOps” has become a popular topic, with the promise of embedding security within the process and tools used by the development team. However, in real life “DevSecOps” adoption is meeting a lot of friction, and in this article, I will share my view about one of the main reasons for this friction, and why I believe “Threat modeling” is the solution.

The Story of DevOps

We can’t tell the “DevSecOps” story, without starting with “DevOps”. I am sure you are tired of hearing the “DevOps” story, so let me give you my version of how I came across “DevOps” instead. Around 2010, I worked as an operations engineer, supporting a web application. At this time, we had a weekly deployment window which was 2-hour downtime per environment. The deployment and the testing were manual, so it typically took a full day for us to deploy a new version.

That is when we discovered “DevOps”, we created an automated job for deployment and eliminated downtime, we also automated testing, and created Dashboards and alerts. Suddenly, the deployment process was a few mouse clicks, and we had the rest of the day to focus on other tasks.

This takes me then to the definition of “DevOps” I prefer:

“DevOps” is a set of tools, processes, and culture to make software delivery:

Fast
Efficient
Reliable

The reason I am telling this story, and I like this definition is that it makes it very clear what problem “DevOps” solves. “DevOps” is all about Speed and Efficiency, through DevOps many organizations became able to do multiple deployments per day or more, not just 1 deployment per week as it used to be.

However, with speed the likelihood of issues increases, and this is where the third goal of “DevOps” which is “Reliability” comes in. Reliability includes many things, like “Stability” (not breaking existing functionality), “Performance”, and of course “Security” which is our main focus for this article. “Stability” was covered by unit tests and integration tests to verify new code changes are not breaking existing functionality. Also for “Performance” latency load tests were added, as well as monitoring performance metrics such as CPU and memory utilization to ensure new code was not causing performance degradation.

How about “Security”? Well, for a long time as DevOps adoption ramped up, “Security” was never part of the equation. In other words, while DevOps was successful in breaking the wall between “Dev” and “Ops”, “Security” remained in its own Silo.

DevSecOps vs DevOps

Fast forward a few years, and now the security team come up with “DevSecOps” to break from their silo. Now, the thing to note here is that the problem security teams were trying to solve is the fact that software delivery has become much faster, and security teams have become the bottleneck with their tools and processes that can’t match “DevOps” speed. In other words, the problem “DevSecOps” was trying to solve was somewhat different from the initial problem “DevOps” was meant to solve which revolves around speed and efficiency.

As you may already know, once security teams started adding their security tools such as SAST, DAST, and SCA scanners within the DevOps pipeline to achieve the goals of “DevSecOps”, the initial goals of “DevOps” were compromised, as these tools were generating a lot of false positives/low importance findings which were disrupting the SDLC and having significant hits on speed and efficiency, the main goals of “DevOps”.

As a result, instead of “DevSecOps” breaking the virtual wall between Security and DevOps teams, it added to the friction because of the contradicting goals of security vs speed and efficiency. While many improvements have been introduced to reduce the speed and efficiency hit such as “Shifting-Left”, the truth remains that “DevSecOps” still has a significant effect on speed and efficiency.

The Security vs Speed and Efficiency Tradeoff

While we can’t deny the effect “DevSecOps” has on speed and efficiency, we as security teams still defended it with the argument that the value you get from verifying the security of your application makes this a good tradeoff to take.

Theoretically of course this is true, it is ok to sacrifice a bit of speed and efficiency to ensure security. However, this takes us to the second problem with “DevSecOps”. Let me explain this problem with an example:

The vulnerability CVE-2023–38646 was discovered around July 2023 affecting Metabase (a popular open-source business intelligence tool) which had a devastating impact on pre-auth RCE (Remote Code Execution). One of the main causes of this vulnerability was a line of code a developer removed by mistake in a Pull Request, this line of code cleared the temporary setup token used during initialization of the application after the setup is done. Removing this line of code, meant that an attacker could get this setup token after setup and use it to bypass authentication.

How is that related to “DevSecOps”? Think about all the tools security teams have been adding to the SDLC like SAST, DAST, and SCA, and ask yourself, would any of these tools have detected this issue before being pushed to the main branch? The answer is no, simply because this is a business logic issue very specific to Metabase. The truth is this is just one of many examples of critical vulnerabilities that are related to application-specific business logic which tools can’t discover.

This is a very clear security blindspot for “DevSecOps”, one that makes the tradeoff argument less convincing, as you are sacrificing speed and efficiency for incomplete coverage for security.

What does “Security” mean?

The problem with the above approach (let’s call it tool-based “DevSecOps”) is that it doesn’t start with a clear definition of what security means, or more accurately it lets the tools define that for us. That is a problem because while security tools can detect known issues and missing best practices, they can’t understand the context of the application, or define security. This leads to a lot of time lost on false positives/low-importance findings, as well as critical issues missed.

So, how do we define “Security”? Let’s start with the dictionary definition:

The state of being free from danger or threat.

The keyword here is “threat”, you can’t say whether your application is secure unless you know the things it needs to be secure from, the “threats”. And this is the very goal of “Threat modeling”.

Let’s take the 4 famous questions “Threat Modeling” aims to answer:

What are we working on?
What can go wrong?
What are we going to do about it?
Did we do a good job?

The first question focuses on the “Scope” of what is being built. The second question focuses on “Threats”. The third question focuses on “Mitigations”.

For example, for the Metabase application mentioned above a threat would be something like this:

Threat: The setup token being available after initialization would allow an attacker with network access to bypass authentication.

And its corresponding Mitigation would be:

Mitigation: The setup token is always cleared once the initialization is complete.

As you can see, “Threat modeling” defines what “Secure” means for any application by defining what it needs to be secure from “The Threats”, and what needs to be always true to remain secure “The Mitigations”. This allows us to take an informed approach to how to deploy “DevSecOps” as we are going to see shortly.

Cover your mitigations with tests

What completes the connection between “Threat Modeling” and “DevSecOps” is the 4th question “Did we do a good job?”, this includes multiple things:

Did we catch all the important threats?
Do we have good mitigations?

It also includes:

Are the mitigations working as expected now and in the future?

And this is where “DevSecOps” comes in, because now with a clear definition of the things that always need to be true to be secure “The Mitigations”, our goal becomes covering all of these with proper tests and tools to make sure they are working as expected, and they don’t break by future code changes.

For example, the Metabase threat and mitigation mentioned above would be covered by a test like:

Test: Write an integration test that simulates the setup process and verifies that once the process is complete the setup token is no longer accessible.

Note that this test would have blocked the pipeline for the pull request that removed the line of code causing the vulnerability. Note also, that we didn’t have to use a security tool for this, we can just use whatever the developers are using to write their “stability” integration tests.

Let’s take a couple more examples:

For a threat related to unauthorized access, which is mitigated by authentication and authorization, we should have unit or integration tests covering authentication and authorization.
For a threat related to SQL injection, which is mitigated by the use of parameterized queries, we should cover this with a SAST tool that supports the language and library we are using for SQL. Note that in this case, we will not block all SAST findings, just the ones related to our mitigation.

The “Threat Modeling” based DevSecOps process

For this to work efficiently, we ideally need to perform “Threat Modeling” during the design phase of any project, and one of the outcomes of “Threat Modeling” would be the testing plan to cover the mitigations. Then, we need to verify that these tests have been implemented before deploying the project to production.

Mitigation Coverage as a metric

In this approach, instead of starting with the tools when creating our “DevSecOps” plan, we start with the mitigations and create a test plan to cover these mitigations with the right tools, and we can use a metric like “Mitigation coverage” which refers to the percentage of mitigations covered by tests, to give us a much better indication of our security that the number of findings generated by security tools.

This process achieves much better integration between security and development teams because it gives a clear definition and expectations regarding what needs to be true to be “Secure”, and these expectations are agreed on during the design phase. Also, the developers now are only being blocked when a test related to a mitigation fails, which is much more reasonable than blocking for scan findings. I would argue then, that this approach is what truly breaks that virtual wall between security and development teams, and fulfills the promise of “DevSecOps”.

Where do we go from here?

“Threat modeling” defines security, and this makes it much easier and much more efficient to have proper coverage for security within your DevOps goal without affecting speed and efficiency. However, Integrating “Threat Modeling” in your organization’s SDLC is a long-term project that needs a lot of time and effort, so let me suggest some short-term goals to push things in the right direction:

Start training your developers on “Threat Modeling”.
Start “Threat Modeling” a few projects as a pilot to show the value.
Make testing requirements one of the outputs of the “Threat Modeling” process.
Even if you are not performing “Threat Modeling” yet, start with requiring tests for the common mitigations. e.g. Authentication, Authorization, and Input validation.
Add your SAST, DAST, bug bounty, pentest, .. etc findings to your threat models, and write tests to cover their fixes.
Based on the mitigations commonly coming up in your threat models, choose the right tools that can cover these mitigations.

CURATED CONTENT

Handpicked for you

Putting Threat Modeling into practice: A guide for business leaders

How the new EU Regulatory Landscape Will Impact Software Security

Threat modeling helps identify risks to a business’s systems and resources, providing insights into potential cyberattacks before they happen. This proactive approach reduces the chance of a breach. However, building effective threat models is often difficult, even for organizations with strong cybersecurity resources, due to the complexity involved.

Despite these challenges, businesses can still enhance their threat modeling efforts. By overcoming these obstacles, leaders can better protect their organizations against cyber threats.

This blog goes over some tips for enabling successful threat modeling initiatives.

The EU has rolled out new, stricter cybersecurity laws that will reshape how businesses approach secure software development and product security. With the introduction of DORA, NIS2, and the Cyber Resilience Act (CRA), organizations must now meet higher standards for cyber resilience and operational security across their entire ecosystem.

Wondering how these changes will impact your business and what steps you should take to ensure compliance? This blog breaks down the key requirements and their implications, helping you stay prepared in the evolving cybersecurity landscape.

Threat Modeling with ATT&CK v1.0.0

Enhance your threat modeling with Threat Modeling with ATT&CK—a strategic approach that integrates MITRE ATT&CK®, the trusted framework for security teams, into threat modeling practices. This integration helps security professionals better understand adversary behaviors and focus their defenses on specific threats to their systems.

Developed by the MITRE Engenuity Center for Threat-Informed Defense, this initiative aims to advance threat-informed defense worldwide.

TIPS & TRICKS

Crypto Gram Newsletter

Looking for expert insights on cybersecurity and privacy? Subscribe to Crypto-Gram, a free monthly digest of Bruce Schneier’s popular “Schneier on Security” blog. Get the latest updates, tips, and analysis straight to your inbox and stay ahead in the ever-changing world of security. Don’t miss out – it’s free, and it’s packed with value!

Upcoming trainings & events

Book a seat in our upcoming trainings & events

Agile Whiteboard Hacking a.k.a. Hands-on Threat Modeling, in-person, hosted by HITB, Abu Dhabi

25-26 November 2024

Threat Modeling Practitioner training, hybrid online, hosted by DPI

Cohort starting on 6 Dec 2024

Agile Whiteboard Hacking a.k.a. Hands-on Threat Modeling, in-person, hosted by Black Hat Europe, London

Next training dates:
9-10 December 2024

Agile Whiteboard Hacking a.k.a. Hands-on Threat Modeling, in-person, hosted by NDC Security, Oslo

9-10 December 2024

Threat Modeling Practitioner training, hybrid online, hosted by DPI

Cohort starting on 6 Dec 2024

Agile Whiteboard Hacking a.k.a. Hands-on Threat Modeling, in-person, hosted by Black Hat Europe, London

Next training dates:
9-10 December 2024

Agile Whiteboard Hacking a.k.a. Hands-on Threat Modeling, in-person, hosted by NDC Security, Oslo

9-10 December 2024

Threat Modeling Insider Newsletter

Welcome!

Welcome!

On this edition

Guest article

Threat Modeling Is What Puts “Sec” in “DevSecOps”

Written by Mohamed Abo El-Kheir

The Story of DevOps

DevSecOps vs DevOps

The Security vs Speed and Efficiency Tradeoff

What does “Security” mean?

Cover your mitigations with tests

The “Threat Modeling” based DevSecOps process

Mitigation Coverage as a metric

Where do we go from here?

CURATED CONTENT

Handpicked for you

Putting Threat Modeling into practice: A guide for business leaders

How the new EU Regulatory Landscape Will Impact Software Security

Threat Modeling with ATT&CK v1.0.0

TIPS & TRICKS

Crypto Gram Newsletter

Upcoming trainings & events

Book a seat in our upcoming trainings & events

Threat Modeling Insider Newsletter

Delivering the latest Threat Modeling articles and tips straight to your mailbox.

TOREON OFFICE

NAVIGATION

KMO PORTEFEUILLE

TOREON NEWSLETTER

OTHER NEWSLETTERS