Eliminating waste is by far my favorite part of the agile approach to software.
In a world where the entirety of a piece of software is designed up front, I might ship and learn only after the fact that nobody ever uses the software's WhizBang feature.
That's brutal — the entire development team spent three months on that. But in an iterative world where we ship every week or two, we'd have shipped a small slice of that feature, seen that it wasn't getting used, and pivoted to something that provided more value to the users.
The same concept can also be applied to the security of your software. This doesn’t mean you’ll implement security and ditch it after two weeks if no one tries to break in, or that you should wait until something bad happens to implement security functionality.
But it does mean you should assess threats from a likelihood and impact perspective and then prioritize them accordingly. And, like delivering features, you should do this as close to the start of the project as possible.
This is where threat modeling comes in.
What is threat modeling?
Threat modeling involves being deliberate about identifying who would want to attack the system you are building and how those people would go about conducting the attack. Significantly, as Margaret Rouse points out, it is also about determining “where the most effort should be applied to keep a system secure."
Threat modeling isn't just a brief brainstorming session followed by items hastily added to a team's backlog. Teams define entire processes around it, such as this one described by Microsoft, with varying levels of formalism. The key is to identify all manner of threats and then to tie them to business significance ― and thus, priority. Implementing counter-measures then becomes a first class feature for the team.
Some obvious examples come to mind.
If you run an E-Commerce site, financially motivated thieves will want to game the payment system to get free things. Perhaps politically motivated people would want to get administrative access to publicly vandalize the site with some kind of message. Or perhaps one user would want to target another, gaining inappropriate access to see what that person buys and sells.
But there are also less obvious examples that are equally important. If the site is storing personal information, which operational or IT administrative employees have access to it? Would it be possible for them to record that information and retain it, even after leaving the company? What would happen if they did?
It’s not just your employees, either.
Do you have an agency that you're subcontracting operational work to, who, in turn, might be subcontracting it even further? What sort of access do those folks have, and what could they do with it? If your relationship turned sour, could they try to hold your operations hostage somehow?
It is by answering these questions that you start to understand what could happen and how to prioritize counter-measures. And you also gain a sense for how likely a threat is, how important it is to protect pieces of your infrastructure, and if a threat really even matters.
As strange as it may sound— not all threats are equally important.
Security in a Vacuum
Software developers are conscientious people that take pride in their work and knowledge. In a vacuum, this can lead to situations where they make decisions on the basis of doing "the right thing" as a matter of principle rather than profit. They might say to themselves, "what kind of programmer would I be if I didn't create a login for our site and salt and encrypt the passwords being stored to the database?" This would obviously be followed by implementing such a scheme.
But what if the application consisted only of publicly-available functionality and content, such as a simple web-based calculator? Should the developers have done "the right thing" or should they have just skipped implementing signup/login altogether?
Testers are similarly conscientious people that take pride in their work and knowledge ― and who can also slip up in the same way. "What kind of tester would I be if I didn't test a scenario where the user doesn't actually enter a password?" They might test this scenario and submit a defect, noting that users could bypass signup and get straight to the content by leaving the password field blank. But if all of the content is publicly available, who cares?
Left to their own devices, these folks will run with "the right thing" due to their sense of professionalism and previous battle scars. That is why threat modeling is so important ― it moves decisions about security from happening in ad-hoc fashion at the individual level to deliberate fashion at the team or project level.
Threat Modeling for Business Value
In the example above of creating a spurious login page, nobody ever stopped to ask, "If they hacked it, so what?" If a hacker were able to spoof an existing user and log in, they would…do what, exactly? Use the calculator? Who cares?
If threat modeling had been performed, and those questions had been asked, creation of a login page would either have been deprioritized or, more likely, jettisoned altogether. It would not have come across a developer's desk as something to implement in the first place, and a developer would be unlikely to take it upon herself to do it as gold plating. After all, the team would already have been through the threat modeling process and thus, all aware that 'unauthorized' access to the calculator is a non-issue.
Instead, the team might have come away understanding that distributed denial of service attacks (DDos) were a threat to the calculator's core business. They would then be able to plan high availability and remediation of threat as properties of the system from the beginning. In this fashion, the team is working not just on the highest value user features but also on the highest value security features as well.
Assumption of Control
With both user features and security properties of the system, it's important to prioritize the work with the highest ‘bang for the buck’ factor. But there's an additional component to the specific value of threat modeling.
The attack vectors for a piece of software or a system are conceptually infinite, as the black hat hackers of the world are constantly dreaming up creative new ways to ruin your day. What's not infinite is the time and resources of the team ― those are often highly constrained.
Right out of the gate you face a tall order. The only hope of keeping up is to identify the most damaging, likely threats and design your system in a way that mitigates these.
In a world where attacks on your application are a constant way of life, threat modeling gives you the best fighting chance to sleep easily, knowing that you've got a good strategy for preventing the worst attacks and that you've spent your money wisely.
Has your team implemented threat modeling? What impact has it had? Let us know in the comments below.