If you’ve worked with me, then there’s a good chance you’ll probably be aware that my biggest passion in the workplace is security. It’s a good feeling when you pre-empt a security issue during planning, or spot a potential hole during code-review. Next to mentoring, I’d go as far as to say it’s the most satisfaction a developer can get!
Another fact you may know about me is that I enjoy watching other people; and the best thing about being able to embed in different companies for a few months (or weeks) at a time is that I get see how other people tackle familiar challenges, and I can subsequently reflect upon what can be learnt or improved. This covers a whole plethora of everyday topics; everything from systems architecture, code composition and design, team and workflow management..
Interestingly - if you give two teams an identical problem of medium complexity, it’s rare to see two identical solutions. Yet for all the creativity and ingenuity that’s abundant in our industry, there’s a rather sad recurring feeling that your average Dev/Ops team becomes a lot more linear when it comes to security concerns.
Threat modeling, and why aren’t you doing it?
One of my more recent postings saw me slot-in to a development team working on a finance/payment gateway. As expected, they were technically sound - perhaps with an element of design/architecture obfuscation - and largely “on the ball”.
However there was still a lingering discomfort during stand-up meetings every morning; as regular as clockwork the same individual would simply utter “I’m doing security”.. and the meeting would move on.
Now from a management/team-cohesion point of view, this is clearly not good enough - the lack of specificity means that other members of the team are left in the dark; for all they know their colleague is going to stand in the lobby checking passes all day! Yet this wasn’t my main source of discomfort.
See, “security” simply doesn’t work this way.
Having dedicated security tasks in your development team - especially ones that span for days on the end - is a sign that your overall approach to security is poor. Security isn’t a feature, and it’s not something you can “layer over the top” half-way through. Security is a process and an approach in itself.
If you’re relying upon individual development tickets to provide security to your product, then how do you answer issues that are at a higher level? Perhaps those that you find at an architectural or conceptual level?
This is best illustrated by the concept of Threat modeling.
The Threat Model
Formulaically browsing code and making modifications at the source level is pretty superficial, and security should begin before even a single line of code has been written. Security should begin with the thought process behind every line of code written; enter Threat modeling.
Threat modeling is largely the process of answering the “who, what, why and when” about a product. It may start off by simply sitting down and determining what assets you’re protecting, which actors have exposure to which functionality, what entry points will provide a first layer of defence, who needs to do/s what, and what overall attack surface an adversary will see.
With this information you can build scenarios, ultimately allowing you to make better informed decisions about all manner of topics; including system architecture, platform choices, ACL design, user flow.. etc
That may sound a bit confusing, right? Perhaps it even sounds like one of those buzzwords or phases, soon to be consigned to the scrapheap of “*eXtreme Programming” and other “bullshit bingo” entries? Well, consider an example of two teams:
Team A is your standard development team; they loosely follow an Agile methodology and they have domain specific requirements and knowledge injected via a Business Analyst.
The BA produces requirements which are discussed in the team, they’re estimated, prioritised, and then added to a backlog.
Team B are an identical team; same talent, same product and same company.
They differ in process though, and prior to requirements being added to the backlog, they do a rudimentary threat modeling session where they determine who needs access to the functionality, which privileged assets it interacts with, how it affects the overall attack vector of the product, and other simple but important questions.
It’s immediately obvious to see the difference in both output, and ultimately attitude, that Team B will gain from their awareness of associated threats. Not to mention Team B will almost certainly have better defined requirements, purely by virtue of the threat modeling requiring a good understanding of the desired end-product!
Suddenly the advantages to good security seem to permeate throughout the whole development lifecycle, don’t they?
One of my best purchases of the last year was this book - Threat modeling, By Adam Shostack - and I genuinely can’t recommend it enough.
For Web Developers, there’s good entry on the OWASP Wiki. It should go without saying, but OWASP is an all-round excellent resource for everyone involved in Web Application Security.