A Brief Introduction to Threat Analysis

December 2013

The purpose of this blog piece is to introduce the concept of threat analysis, what it is and why it's a good idea, while at the same time presenting a simple and effective way to try it yourself.  It is part of a blog series on the development approach at Nexor.

It is now an all too familiar scenario, yet another news story comes out regarding a high-profile successful hack of a website, application or device. For old legacy software and devices it isn't really surprising, but for anything created recently why is this still happening?
In order to answer this, it is worth considering two further questions:

1. Why did the attacker do it?

2. How did the attacker do it?

Let's take an imaginary web application to explore this further. The application allows people to buy and sell items via a website and has the following capabilities:

• Create users of the system. A user has at least a username, password, address, phone number and credit card information

• Allow sellers to upload photos and other details of the item to sell

• Allow users to submit bids for items, and pay for them if accepted by the seller

Starting with the first question, what might an attacker want with this application?

1. The user data is of high value in the wrong hands, so getting at the information stored within the application database would be very nice

2. Even better, instead of a one-off attack, why not insert a piece of malware onto the system that secretly notifies the attacker of all new user details as they are created

3. A rival company is not happy about the success of the website and would really like to discredit it and put it out of action

A useful way to visualise this is by using a mind map with the application in the centre and the above reasons as subtopics:

We have some reasons, but now for the second question, how might the attacker go about it? I'll extend the previous mind map by adding the answers as further subtopics of the reasons:

Although the examples are simplified and a little contrived for the purposes of this blog, what we have actually done here is begin the process of performing a threat analysis. We analysed an application from the perspective of the attacker with the goal being to understand:

• What the attacker wants to achieve - the attacker's objectives

• How the attacker will achieve it - the attacker's methods

Armed with this knowledge it is now possible to identify ways to defend against the attacker's methods, and this will produce a list of attack mitigations. Finally, these mitigations can be turned into testable requirements for the application.

NEXOR use threat analysis techniques at various stages of product development. The first time it is used is at the requirements stage when no design exists, only an idea of what is required. The outcome will be further requirements and will directly feed into the design process. Once a design is beginning to take shape and more detail is known about the architecture of the product a threat analysis approach similar to the Microsoft SDL (Design phase) can be used to help identify issues with the design.
There are two important points to note here, the first is that this all occurs before any code has been written. There are plenty of tools to help find problems with source code (and you should definitely use them), but leaving threat analysis until the coding phase is far too late as security is extremely difficult to bolt on as an afterthought. Secondly, threat analysis makes you look at your application in a whole new light and in ways that you would never normally do, and will lead to a much more robust and secure solution.

For completeness, some possible mitigations for the above attacker methods are now added to the mind map:

This shows that for one attacker method, there may be multiple mitigations, and some may be related to mitigations for other attacker methods. The "Use an appropriate firewall" mitigation is an example of one that is not directly part of the application, but the surrounding environment. This sort of mitigation is not uncommon.

A perceived negative impact of threat analysis is that it is too hard, takes too long and can cost too much as a result. While it is certainly true that threat analysis can take time to do properly, and can also lead to extra design and implementation effort being required, hopefully, this blog has shown that it isn't too difficult to get going, and once you've tried it a few times it will get easier. Also, what is the cost to the organisation when an attacker targets your application and successfully steals the entire contents of the database?

Do you use threat analysis techniques? If so, did it prove useful? If not, why not?

REQUEST A CALLBACK

  If you would like to talk to us directly, you can request a callback.  We value your privacy >

Be the first to know about developments in secure information exchange

We value your privacy Find out more >