1988—I was introduced to writing software during summer break from college, working in a physics lab for a professor. That makes it 26 years I have been doing this—the last 20 professionally. Holy cow, how did that happen?
In all that time I can think of three really fundamental lessons I have learned about writing good software: write tests first, work with someone else and talk about your model.
I think that TDD (Test Driven Development) is an incredible way to satisfy the first and Pair Programming is great for the second but I still see, to this day, a rush to code and get stuff done with minimal talk about the design of the code.
Maybe it’s different in your organization, but what I observe is that we all love to write code so much that we want to dive in. Now, I’m not saying we’re reckless or don’t do design, but – after we brainstorm and decide on a design – we might have one person write it up for review and then we all get started.
I believe this works pretty well for delivering software quickly in an Agile world. Where I think this fails is in the security aspect of our software. By not talking about the software design and reviewing it from a security perspective, we miss important things about the failure modes of our software in general and the security issues in our software.
In my experience, I’ve found it very beneficial to have Threat Modeling exercises at both the beginning and the end of a project. The benefits of this process have been immediately visible to me as I have facilitated these exercises and I see teams having fun attacking their design for weaknesses and failure modes. The other great output is that we address the issues we identify in early development and raise visibility of any accepted risk to the business (sometimes that invaluable feature is also risky).
So what is threat modeling? Well, I learned it from reading various sources over the years, but primarily I have derived the practice I teach teams from Adam Shostack’s book Threat Modeling: Designing for Security.
This is a great reference on the subject and I think the most important thing it has to say is, essentially: just do it. Start today, there is no perfect way to do it, so just do it and your software will be better for having undertaken this exercise. In that light, I want to provide insight into how to run a threat modeling exercise.
When I threat model with a team, I work through a pretty simple script:
1. I give them an overview of the concept; introduce STRIDE to help identify threats; and the META acronym for how to resolve issues: META stands for Mitigate, Eliminate, Transfer and Accept.
2. Then we do a Data Flow Diagram of their system. I get the team to try and tell me about how the data flows through their system, where it comes from, and where it ends up – one thing I almost always point out is that most teams miss user inputs that come from configuration files and tend to trust the data from there in different ways from UI based user input.
3. Once the team agrees on the diagram, we identify the places where trust boundaries are. A new addition to our technique that a colleague of mine introduced is to identify the risks of the system being compromised and what is worth protecting. This helps focus the activity, identify where trust boundaries are, and gives the team a better sense of what is at risk when their system gets compromised.
4. Now comes the fun part: Iterate over the trust boundaries in your system and use STRIDE to help brainstorm risks to the data and the system. Record each potential issue and move on.
Don’t spend a lot of time on feasibility or practicality; that comes later. And don’t insist that each issue be categorized by STRIDE: it is a mechanism to help spur thoughts, and there is no value in the process we use for knowing which category an issue belongs to. The fact that an issue exists is good enough.
5. Now comes the hard part: Iterate over the list of issues and discuss them in depth (I usually do this a day or two after the brainstorming).
Now is when the team decides to Mitigate an issue, Eliminate it (i.e. by removing a feature or functionality), Transfer it (e.g. the OS is responsible for enforcing ACLs on the configuration files), or Accept it.
This is the META acronym I referred to earlier. Our teams update the backlog, negotiate with product management in the case of removing functionality, or communicate to product management about accepted risk. This conversation is incredibly important for businesses so that they can make informed decisions about the security of the software they ship and investments into the security of the products.
6. Hold a brief retrospective so the team can re-validate the data flow diagram and refine how they want the process to work for them next time around.
I highly recommend that you read Adam Shostack’s book – it’s full of more important details and helpful hints about the process. Read others too, but what is most important is to just start Threat Modeling now.
It will enhance your security posture, reduce your bug count, improve communication within teams about design and provide the business with visibility into the risks associated with the software.
How is that not the most important thing you can do in today’s breach filled world?
- The Ever Expanding Trust Boundary: To Infinity and Beyond
- Is Third-Party Risk Software Worth It?
- Threat Mitigation and the 20 Critical Security Controls
- Why You Should Care About the Apple Backdoor
The Executive’s Guide to the Top 20 Critical Security Controls
Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].
Image courtesy of ShutterStock