Freigeben über

Using Threat Models Beyond the Design Stage

  • Artikel

Threat Modeling is no longer the obscure magic is used to be. With the creation of tools like the Threat Analysis and Modeling tool from the ACE Team, Threat Modeling is now easier to implement, faster and more comprehensive. Threat Modeling  is the cornerstone of any good Secure Development Lifecycle.  One of the reasons it became such an important part of the process is because it provides visibility of the potential threats to an application, and how to defend against them before you start writing code.  Many teams that implement Threat Modeling, create their threat models, get their list of countermeasures that they have to put into the code and then go make a system.  People don’t realize just how valuable a threat model can be to the team, beyond the development stage.  Another huge benefit of Threat Modeling is how it can help other teams during later phases of the development life cycle.  Testing, Deployment and Incident Response are some of the areas that gain huge benefits from threat models. 

Testing teams are often focused on feature tests, performance tests and acceptance testing.  More and more they are checking for basic security vulnerabilities as part of the normal course of testing.  A Threat Model is a very suitable guide to assist the security testing process.  Not only does it increase the security awareness of the test team, but it will help the testers create tests to ensure that the countermeasures identified in the threat model were put in place correctly.  After all, if you don’t test the countermeasure, how can you be sure you got it right?

The TAM tool can also be used to create work items in TFS for the testers to do exactly that.  For each countermeasure work item that the tool generates for the developers to implement, TAM generates a corresponding test for the testers to execute to verify the countermeasure.  This makes creating a test plan for the application much more comprehensive and valuable.

Beyond testing is the deployment phase.  During deployment a threat model can greatly improve the deployment teams awareness of the security profile of the application, it’s attack surface, and the potential security hot spots of the application such as trust boundaries and critical data storage areas.  All of this information helps the deployment team increase their ability to deploy the application correctly, and give it the proper attention it deserves.  This will increase the efficiency of deployment, and any potential incident response activities.

As much as we would like to believe that applications survive well on their own after they are deployed, there is always something that comes up.  We would all like to think that our applications are hack-proof and that they will never suffer a security incident.  But we don’t know what we don’t know, and can’t be sure that some new attack won’t be created.  In these situations, we need to be able to respond quickly and effectively to these sorts of incidents.  With a good application threat model responding to security incidents is much more efficient.

With a good threat modeling practice in place, when a new attack type appears the security team examines the attack, scrutinizes it, formulates appropriate defenses, and generates awareness of the attack.  They can update the Attack Library in the TAM tool, and instruct teams to re-generate their threats to see if their application is subject to the new threat or not.  This will very quickly tell you if you have to start getting your emergency patching process rolling, or if you are safe from this new type of attack. This may not seem like much but consider what this provides in the bigger picture.

With the click of a button, in the case of the TAM tool, you will instantly know if you have to patch your application immediately, or if you aren’t affected by the attack.  With the Enterprise version of TAM, you can even see if applications you are dependent on are subject to the new attack or not.  If you are, the threat modeling process will notify you, provide you the countermeasure you need to implement and provide the test you need to ensure the countermeasure is implemented correctly It will also create updated reports so that the entire team is aware of the issues, their responsibilities and compliance requirements very quickly.  What this all means is that your patching cycles are much shorter, the application is maintained in a secure manner, which all results in increased customer satisfaction and loyalty. 

Ultimately, you can say that good Threat Modeling practices = more customer satisfaction and loyalty.  After all, isn’t that what we’re really after?

Comments