Application Threat Modeling

I have recently had the pleasure of helping a few organisations get to grips with threat modeling, helping them embed this process within their SDLC. Never an easy task but nonetheless a rewarding one. A few things stood out for me and like all security buzz words it feels people want to adopt the latest and greatest concepts without thinking about what is actually required to support, mature and actually make them effective in reality. The end goal is a well defined repeatable process.

So many articles relating to Threat Modeling which is great but what they forget to incorporate is the ‘real-world’ aspect of doing this effectively.

We all know it is a crucial part of the design phase that helps produce resilient software that can stand up to common and emerging web app attacks. Reducing the attack surface and identifying all the possible attack points and scenarios. It is safe to say that in todays world no code should be written without a threat modeling exercise being conducted first.

The benefits really are quite simple, identify the potential issues early on before bad code is written thus saving costs by not having to delay and fix bad code. Of course, there are other benefits such as building security unit tests early on, help the development team implement the right controls, help the operational teams to configure running services properly, Automating security testing and so forth.

All sounds amazing right? Well in the real world unfortunately it is not so easy and many challenges await. Some common challenges that you will likely encounter:

  • Business Support
  • Out-dated culture
  • Training needs
  • Demonstrating roi
  • Poorly implemented/immature SDLC

Also another big mistake that I have encountered is that organisations try to implement threat modeling without having some very basics in place. At very least you should probably meet the following criteria:

You have clearly defined security policies and standards – These documents must exists and must be enforced, again having the backing of the business to drive this really helps. Specific job training and induction should clearly demonstrate these policies and what is required from the role.

Aware of Compliance and Regulatory requirements – An awareness that these exists and that guidelines/best practice should be followed. These help with the appropriate prioritizations and security concepts.

A clearly defined SDLC – A fairly obvious one but you’d be surprised! The SDLC should be well understood and followed. Keep this updated and relevant it’s an iterative process.

Since we are talking about threat modeling it would seem appropriate that there is also a prerequisite to have a plan to act upon any threat modeling undertaken. It is not uncommon to see threat modeling work completed and then completely ignored. If threat modeling identifies significant issues then they must be addressed.

If your organisation cannot apply the above then they should not be adopting threat modeling. It just will not work. It is worth mentioning here also that not all software will require threat modeling, sometimes it just is not worth the effort due to the resources required. For new projects, most certainly for legacy applications probably not, however you can approach that differently and you may find this article interesting

I’m going to end this here are it really is just food for though really and a little oversight into what not to do. If you have all of the above in place you can then move on to the process and start to establish the security goals of that given project. You can use the 4 phases to get started :

  • Model the Application Architecture
  • Identify Threats
  • Identify, Prioritise and implement controls
  • Document and validate

look out for another post addressing the above 4 phases in more detail.

Leave a Reply

Your email address will not be published.