Better Web Apps Security With Threat Risk Modelling

Prevention is the best form of cure! This rule also applies when assessing a web application in terms of security risks or any potential to be hacked. Rather than adopt an ad-hoc approach, it’s better to plan out a structured assessment to identify and prioritise the important risks and threats. Such an assessment is known as threat risk modelling.
The appropriate time for this type of assessment is when you are in the initial stages of designing the application, even before starting to develop it. This will help save time and effort by identifying risky features that facilitate hacking as well as preventing wasted development effort on particular controls that are of little use to combat real risks.
There are different methods to complete threat risk modelling, each with their own benefits. So adopt a method that you find useful, but also one that follows the following principles.

How important is a security review

Threat risk modelling generally starts with a set of objectives, rather than a single one, to help assess the priority of the review, how much effort is required and to identify the important application(s) that should be covered by the review. To help identify an appropriate set of security objectives, you could consider the following categories:

1. Financial – assess the level of potential financial risk if an application is hacked. For example, an online payments application has a greater financial risk than a brochure type website with ‘static’ content on a company’s products or services
2. Identity – is a customer’s or staff’s identity at risk from being stolen. With certain applications, a user may be required to prove their identity in order to access particular services. In such situations, the application must provide sufficient protection so that this information cannot be compromised in any way
3. Privacy and regulatory commitments – given the type of data used by the web application, varying levels of protection are warranted. For example, public comments on a blog are open for everybody to read, whereas personal data, as defined by the Data Protection Commissioner require greater protection to ensure that this information is secure. In addition, Regulatory requirements can influence what information is to be accepted via a web application. For example, Money Laundering regulations require that various forms of identification are presented, when making particular financial applications, so consideration needs to be given as to how this is handled using an web application – whether by hard copy via a related paper application or via a scanned upload
4. Reputational risk – what would be the damage to your organisation if this web application was found to be hacked. The greater the reputational risk, the greater the need to focus on securing the application
5. Application availability requirements – when an application is hacked, it generally needs to be taken off-line for a period of time to correct any damage caused by the hacker. To that end, if there is a service level agreement associated with the application that customers expect to be met or is required in order to provide a crucial public service, then this should lead to a great security prevention effort. This also relates to reputational risk, when a user wishes to access an online application only to find that it is offline due to a security breach, the user may move to a competitor for that service

Time for some deep analysis

With the objectives agreed and the important application(s) identified, it is then time to investigate each application in detail to list the features/functions that merit a threat analysis. It is best to start progressively reviewing each application from the top-down, starting with it’s architecture. After reviewing the architecture to identify potential areas of risk, move on to identify the functions and data flows associated with these areas of risk.
This analysis of the related functions and data flows involves reviewing;

• What data is entered and viewed by a user
• How data is sourced and displayed
• All related authentication and authorisation functions that are completed within each function and data flow
• The relevant design decisions and assumptions made by the application architects and developers

To correct the vulnerabilities, identify the threats

Knowing the detail of your application, you can then compile a set of likely threats which could occur based on current known threats. You can document these threats either by graphing them or by making a simple list. An example of a typical threat graph, taken from the OWASP guide is shown below.

From the graph or list of likely threats, the important weaknesses in the application can be identified. Once the specific weaknesses are known, remedies as shown in the green boxes in the threat graph can be designed and developed into an updated application.
In a follow-on article, I will discuss other elements of threat analysis, including the importance of understanding the context of threats, the type of hacker that you need to combat and different classification schemes that assist in prioritising threats based on their likely impact and context. Please share your comments below.