"Abstraction is the elimination of the irrelevant and the amplification of the essential"
- Robert C. Martin
Why Now? Security is a Mainstream Concern.
Non-specialists are adopting security tools like VPNs, mobile security apps, and techniques listed on great sites like securitycheckli.st, but they are also asking the direct questions that I think we as security analysts tend to talk around because the answers are business factors outside of our direct technical domain.
A recent HN thread, called "Ask HN: Do All VPNs suck?" showed how a non-specialist poster recognized that he had to decide to trust his VPN provider over whatever network he was connected to, and it wasn't clear what made it any more trustworthy than his ISP. When one commenter recommended he create a "threat model," The poster followed up with the comment and question "Sounds expensive and complicated. What's a valid 'threat model'?"
A threat model is the rationale for securing something in the first place. Whether you use a structured one or just your intuition, there is a reason why you would take the trouble to add security to something. The threat model is a tool to describe why. In security, that's where we tend to stop short and focus on the technical issues we understand instead of listening to the real risks people percieve about their businesses and personal lives.
Who Needs Them? Product Teams.
Threat models are rare even in enterprise environments because as a tool, historically, they have been overpowered for most jobs. But to build secure products and make high quality security decisions, and to get everyone working toward the same goals, there is literally no better solution than a consistent view of the threats you need to solve for.
What Changed? Technology Matured.
Security in most orgs today still has assumptions similar to what project- and product- managers had before cloud collaboration tools changed how they worked. Tools like Jira and Trello massively accelerated how teams do project management, and Aha.io made the art of product roadmapping manageable. Both of these roles were disrupted by building something useful for the teams they served, which released much of their domain knowledge and methods via better collaboration tools. Useful working threat models would have the same impact on security, and they do not need to be expensive or complicated. The technology for doing them has also changed.
What is Your Solution? A SaaS Collaboration Tool for Security.
To test the applicability of a collaborative threat modelling tool, I've applied it to a couple of small scale scenarios that generalize well to much more complex situations. Today, I use it daily for much more sophisticated institutional enterprise consulting, but if this were viable, it would work on a small scale as well as a large one.
So, let's talk about your browser history. That's something most people can relate to wanting to protect. What do you need to know about the security of your browser history on your phone? Who is interested in it and why, and what are you doing (or not doing) to protect it today?
The following threat model deck was generated automatically by the tool I developed. The TL;DR is (as per the gap analysis it produced), I have a bunch of ways to prevent my browser history from being stolen, but found in the model I don't have any meaningful way to detect if it happens. or a way to respond when it actually occurs.
Browser History Quick Threat/Risk Assessment (this demo has limited interactivity, but the model it generated is complete.)
Knowing this now, I can either find new security features, products, and services to solve those specific needs, or make better decisions about how to manage the likelihood and impact of those scenarios. Based on the actors on my radar, I can take concrete steps to avoid some bad things that might have happened otherwise (e.g. ultimately I installed that snoopy conference app on a tethered burner device instead). Maybe I switch my technology from Android to iOS and re-run these scenarios. Without a threat model I wouldn't know what the actual scope of a given security product was, and whether it covered and fit what I really needed to protect. These answers might not apply to your specific situation, but a system for reasoning about them can.
There are several techs out there that provide "mobile security" that might protect my browser history, and this quick threat model is an example of an easy framework for evaluating them against a real need to protect it. Your situation will be different and the modelling tool helps you create relevant scenarios like the ones in the deck. Most people don't know about technical vulnerabilities, but they do know who (and what) they are worried about. The collaborative aspect of the tool means you can use the knowledge and experience of your whole team to get a fuller picture of technologies and controls, and update the model as you learn.
Nobody suspects their e-reader. The next simple threat model was for an e-reader I've been thinking about buying (a Kindle Paperwhite). The real question was, given how most products work these days, do I really want yet another device that can surveil me? If I did have one, would it matter? In the security field, you tend to keep track your techs because you are more likely to deal with things like malware, hackers who want to raise their profile by causing you trouble, or having to explain to authorities what your gear is for. Someone outside the field will have a different threat model but this was the one I used for buying a Kindle.
The e-reader seems like a simple device with limited functionality that you wouldn't intuitively apply a threat model to. However, that's what makes it a good test case. Just like how you can use other collaboration tools to plan everything from a kids' birthday party to a SaaS product, this approach to security was designed for complex solutions, but as you can see from the deck, it applies down to the level of simple everyday things.
E-Reader Quick Threat/Risk Assessment (again, same limited demo, but model complete.)
TL;DR: The result was that I could protect some of my usage and reading habits from some people, but there wasn't much I could do about being profiled by the platform, and there was no clear way to detect the negative scenarios, or to respond to them if they played out. I will probably still get a Kindle, but now I will only use a prepaid credit card with a low limit on it, and be mindful of what kinds of books or documents I put on it based on peoples recommendations, because I have little way of knowing about or responding to the consequences of someone rifling its contents. This may seem like common sense, but it's the clarity from the model that makes it seem obvious, as it's not what most people would have intuitited without one.
Is This Really That Simple? Yes.
All the complexity is taken care of on the back end in a graph database, but to understand the essential information in the generated deck, or to do a threat model of your own (though I recommend signing up!), you just need to answer the following 5'ish questions:
- What is the actual thing we're protecting and how serious are the relative conseqeunces if it's compromised? (high/med/low)
- Who are we protecting it from, how serious are they, why do they want it, and how likely is it they will succeed based on all the dependencies and protections in place now?
- What are we doing to protect it today? e.g. passwords, encryption, VPNs etc.
- What technologies can I think of that it depends on? e.g. the "attack surface" in the logical security model slide.
- What are the a gaps in the kinds of controls I have, and which ones are TBD if I want them.
The tool lets you update the deck collaboratively with a project team to add the tech dependencies, controls and scenarios as you find them. When there is a hole in the model, it's obvious, and someone on the team can point it out using the same lexicon as everyone else.
For example, one reviewer asked me why I didn't just add an anonymous registration email to the controls for the Kindle. I added it in a few seconds and it rebalanced the priority of all the threats in the live deck on the platform.
In practice, the platorm generates user stories for security features, documents for compliance, dashboards for completeness, and a clear, focused scope for vulnerability assessments.
If these models put your security analysis processes in a new perspective, or you'd like to use the tool that created them, you should get in touch!
But wait, this doesn't show me how I'm compliant....
As a security pro, I was interested in what the necessary conditions were for a general solution to the problem of product security. If it were possible, what would it look like? I found that any "best-possible" solution would need to leverage and reflect the knowledge of everyone who had a stake in its final outcome. The result was something we hadn't really tried in security, yet an approach that has succeeded and already revolutionized other functional areas like development, operations, and product management; it was collaboration. Most security problems, whether they were vulnerabilities or design errors, were the effect of how teams organized and communicated risk. The solutions we've tried were the effect of assumptions about the review/approve role of security that are just no longer true on iterative projects that are producing most new software today. We need to get upstream of implementation to fix it, and collborating on practical, useful threat models is the best way to do that.
Compliance is a target that has ceased to be a useful measure. For the small-medium teams who now build the vast majority of all new tools and products, compliance is a poor substitute for the good design that modern collaboration tools enable. With a working threat model and actually designing and developing to it, the information you need for a compliance assessment is reduced from a 3-lb. document by someone without direct project expertise (which nobody reads), to a short dynamic cloud based slide deck that reflects the current consensus of the entire team and provides a concrete model for what you decide is important.
These threat models rank threats relative to each other so that technologists can make quality decisions about what to implement to meet the needs they reveal. Quantitative models are useful for pricing and transferring risk away and they fall basically in the logical domain of compliance. They are not useful to anyone who actually has to build the controls to mitigate it. A prioritized set of threat scenarios with clear opportunities for improvement is everything operators need to make decisions about how to respond. The next great collaboration platform that changes how we approach a problem won't be built because it helps people, "reduce this red to an amber," or a "reduce this five to a four." A useful threat model that takes hours instead of weeks, and that reflects both business operations and technical reality, will produce products that are trustworthy, and for a change, better.