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
Fundamentals
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.
Design Review
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.
Code Review
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.
Deployment Testing
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.
Incident Response
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)
