Welcome to the May edition of Threat Modeling Insider in 2022!
Yes, between our various Threat Modeling projects, we finally found the time to create the second edition of 2022. With a renewed editorial staff, from now on we do plan to publish every month, apart from the summer months. Ultimately, the goal of this newsletter is to share guest articles, white papers, curated articles, and tips on threat modeling that help you bootstrap or elevate your threat modeling knowledge and skills.
In this edition we have the utmost pleasure to feature Ken Van Wyck, a threat modeling practitioner, author, trainer and enthusiast, who has extensive security experience, dating back to the 1980s.
In the guest article Ken shows us how Threat Modeling can not only be a part of the design phase, but how it can also be valuable in every phase, up until incident response. Check it out!
Our complete line-up:
- Guest article: Threat Modeling Benefits Everyone in the Dev Pipeline, Ken Van Wyk;
- Curated content: Threat Modeling Medical Devices;
- Curated content: Mozilla Rapid Risk Assessment;
- Toreon Blog Post: Threat Modeling vs Pentesting;
- Toreon Tip: Continuous Threat Modeling.
Threat Modeling Benefits Everyone in the Dev Pipeline
Guest article by Ken van Wyk, (KRvW Associates)
Threat Modeling Benefits Everyone in the Dev Pipeline
If you’re solely using Threat Modeling as a process for reviewing a design, you’re missing out on many of its most helpful features. Indeed, the threat modeling process can be hugely beneficial to every activity in the development process, irrespective of whether you’re “old school” waterfall based or more modern DevSecOps, CICD, etc
I should caveat by saying I’m a huge advocate of threat modeling, and I have been since long before I ever called it “threat modeling”. I’ve reviewed designs of complex software systems for decades as a security subject matter expert who understands perhaps a thing or two about software development. Over the years, I’ve come to appreciate that threat modeling helps me navigate successfully through everything else along the way.
If you’re narrowly focused in your process view, such as one might be in a waterfall development lifecycle, you might think threat modeling is only helpful for assessing the security strengths and weaknesses in a system’s design. And, while that is indeed an important aspect of it, you’d be doing yourself and your team a disservice if that’s the only value you get from threat modeling.
It’s probably also only fair I mention here that I have long practiced a fairly lightweight take on threat modeling. That is: give me a small team of willing and knowledgeable developers, subject matter experts, and the most simple of tools — a whiteboard, a text editor, and a spreadsheet — and I’m happy. Sure, we can later get more involved in scoring and prioritizing the defects we encounter, which is fine, but the process itself can provide huge benefits without being overly burdensome. Likewise with the tools.
So, let’s explore here a few other aspects of threat modeling you may well be overlooking. I’ll describe them here in a “waterfall-like” sequence, but that shouldn’t stop you from applying this thinking to other SDLCs as well.
This has always been the core purpose of threat modeling, to critically assess a design and find architectural security defects prior to coding them and potentially building a system that is nigh on impossible to fix later on. By my thinking, that’s still the case.
In our threat model, we’ll look critically at a design and zoom into all the details. We’ll question assumptions. We’ll ensure we’re not leaving any security attributes of our design to luck. We’ll look at every aspect of a design, including how it starts up and how it shuts down, in addition to how it implements every use case, user story, or whatever you want to call its functioning. We’ll start by looking at the big picture and zoom into all the nooks and crannies.
We’ll also capture and document everything we find. Heck, I’ve encountered many a software project in which the threat model is the first design documentation ever collected in one place. That’s okay, and we should embrace that one of the secondary major benefits to threat modeling is that we certainly emerge with a vastly improved understanding of our own system.
Stick to all of this, but look further too.
What on earth does threat modeling have to do with code reviews? It helps us navigate what code to scrutenize in the extreme, and what code we can more or less just skim over — perhaps solely with a static analysis tool — and not worry too much about. How? Well, in our threat model, it’s pretty likely we’ve spotlighted the riskiest aspects of our system. These might include where the most sensitive of data is stored, administrative transactions, and things of that sort. That being the case, we should prioritize our code reviews to spend the most time on those portions of our code that can have the highest impact on the security, or insecurity, of our system.
By way of example, I did a threat model of a consumer facing smart phone application a few years back. In it, the threat modeling team noted the code would store payment information l cally on the client device, and the developer had opted to bypass the keychain mechanisms provided by the three platforms on which they’d be deploying the application. This was justified for co de portability, as (say) Apple’s keychain API is quite different than that in Android.
So, we did line by line manual code reviews of the homegrown keychain storage code. We ensured they were complying with their own corporate standards as well as industry best practices. In all, we scrutinized with a metaphorical magnifying glass about 300 lines of code (out of some 50,000 actual LOC in the entire code base). It saved us time and we knew we were assessing that which mattered most, and it was the threat model that drove us there.
Security and Validation Testing
Similarly, we let the threat model point us to the functionality in a system that needs most to be tested. These will likely overlap somewhat with the code that should be reviewed and scrutenized the most, but not necessarily 1:1.
For example, if we require especially strong access control to protect a highly sensitive functional aspect of our system, we should spend a lot of time testing that access control. That should include risk-based testing as well as validation testing of the code being tested. Let’s watch how it actually behaves and make sure it is performing as we need it to.
Again, it’s the threat model that should help us navigate through our testing. QA testers often speak of their test code “coverage”. Well, coverage is important, but I really want to ensure my riskiest code functionality is being tested the most rigorously.
You’re probably seeing the pattern here. Since we’ve done a threat model of our system, let’s benefit from that in our deployment testing. For example, if our most sensitive data stores require strong encryption from a volume level all the way up to a data level, let’s look at the deployed environment to ensure those controls are in place. Is our data server configured with disk volume encryption enabled? How are the keys managed? Who has access to the keys? And so on.
In all my years of conducting threat model reviews, two words I almost never hear are *incident response*. As someone who has spent decades in the incident response trenches, I find this to be tragic, and in multiple ways.
For one thing, if you’re not inviting your incident responders to your threat modeling sessions, you’re missing out on operational expertise you cannot learn elsewhere — not from penetration testing, movies, etc. There is simply no substitute for experience, and that’s where it likely resides in your organization. Invite them and let them provide input and opinions based on hard-learned experience.
Secondly, when you’re staring at the riskiest pieces of your system’s design and/or code, you should be ensuring the incident responders will be getting all the audit log telemetry to figure out what is going on in your software during an actual security breach. That *use case* is tragically overlooked far too often.
**When** your software is breached, your incident responders will need to gather all the logs, network flow data, and whatever other forensic data inputs they can find. Using that vast data set, they’re going to have to figure out what bad thing happened, usually after the fact.
How will you know they’ll have all the data they need unless that is designed into the system? Start with the threat model. Consider all the bad things that might happen to the system, and ensure you’re logging those actions so the incident response team will be able to make sense of it — in a manner that is adequate for being introduced into a court of law, even.
That’s a tall order that won’t happen by accident. Include them in your threat modeling and planning, in general.
Bring it All Together
Threat modeling is a great process for helping us look critically at the security of a system we’re building. It’s also enormously helpful as a navigation aid to guide us through the other steps in our development lifecycle process if we choose to use it wisely. When we do, we’ll be spending the most effort on the things that matter most, and that’s as it should be.
Guest article by Ken van Wyk, (KRvW Associates)
Curated threat modeling content
Threat Modeling Medical Devices
Software has been assisting medical teams over many years now. In TMI 10 we already wrote a whitepaper about threat modeling medical devices. Finally, the FDA deemed threat modeling to be a vital part in the design phase of medical devices. An FDA-funded playbook developed by MITRE was released last year with the aim of improving device makers’ approaches to these critical models.
Rapid Risk Assessment
As threat modeling fans, it would be an ideal world for us if we would always have the time to execute a full threat model. However, in the real world that time is not always available. A valid alternative approach, as an initial step or a quick exercise, is the Mozilla Rapid Risk Assessment.
Toreon blog post: Threat Modeling vs Pentesting
The question is not, do we need threat modeling or Pentesting. The question is when to use which.
This is the third post in our series about Threat Modeling. The series is meant to provide basic information about the practice of Threat Modeling, why we love it and how it can make your organization more secure. Check out our previous post here: 9 benefits of Threat Modeling.
Tip: Continuous Threat Modeling
Yes, it is possible to enable development teams to perform threat modeling, even with minimal initial security knowledge and lesser dependency on security experts. To help these development teams, Autodesk developed Continuous Threat Modeling, a non-exhaustive checklist, covering the fundamentals of secure development, for quick, convenient consumption. Ultimately, this should lead the teams to ask further security-relevant questions and find appropriate guidance.
We aim to make this a community-driven newsletter and welcome your input or feedback. If you have content or pointers for the next edition, please share them with us.
Book your seat in our Threat Modeling Practitioner course
If creating or updating a threat model is essential to your line of work, then this course is for you. Our threat modeling practitioner training targets software developers, architects, product managers, incident responders, and security professionals.