From the Blogosphere
Even If They Hacked It, So What? Why Threat Modeling Matters By @daedtech | @DevOpsSummit #DevOps
Eliminating waste is by far my favorite part of the agile approach to software
By: SmartBear Blog
Jan. 21, 2016 04:00 PM
Even If They Hacked It, So What? Why Threat Modeling Matters
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 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.
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.
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
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
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
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.
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week