Threat Modelling Web Applications_Part_1: Introduction

The introduction would generally explain what threat modeling is. However, it takes more than a few lines to do that. In fact one may start understanding in parts by  the end of numerous such exercises, how it works.

Let’s answer the question of ‘Why’ Threat modeling is required in the first place.

Today a sizable number of testers perform vulnerability assessments and penetration testing for a wide variety of web applications. As it is, the benefits of a good Penetration test are guaranteed:

• ·         Dynamic but comprehensive assessment of application
• ·         Precise findings
• ·         Tells the likelihood of system 0wnage
• ·         Accurate fixes[since we have tools to tell us the exact interface and parameter affected]
• ·         Ability to test and retest quickly

Now let’s look carefully at each point above. A threat modeling or thorough design review can give us all the benefits from above plus the ones below:

• ·         Great reduction in cost! The cost of fixing issues after development is considerable
• ·         Avoids any confusion from standalone fixes or recurrence of issues
• ·         Makes the application robust by design
• ·         Finds any security issues first hand- yes long before they are born

Application end to end

A design review takes into consideration every single entity that interacts, provides for or is connected to the application. This way it completes all the circles and is the real end to end assessment. It treats the application like a system with its own ecology and then finds what could go wrong. It is not limited to what’s visible to the user from front end but explores possibility of issues from back-end, components, channels, etc…

Accurate findings

What makes a finding ‘concrete’ is evidence. A threat should also be accompanied by its own set of ‘soft evidence’. Except for few cases one can often cite the client to show what has indicated existence of a threat. Like how two decently secure systems being put together in a certain way can uncover a potential flaw leading to insecurity.

Note: You may generally notice this for existing designs

Likelihood of system 0wnage

The likelihood of exploiting any threats to an application can be rightly judged, when one has a bird’s eye view of the design, components and channels. This often leads to different severities for the same issues in different scenarios.

Use of Use-Cases

A use case is a visual representation of the workflow/functional scenario and involves the concerned components and actors. It helps to understand the context better and enhances the chance of quick threat identification for the same.

In ideal cases, we recommend referring to use cases. However, in a practical scenario, with time constraints for review, an experienced security engineer may skip use cases. This is normally the case for a complex design changes that needs to be deployed quickly. In such a scenario it is essential to prioritize some cases/workflows over others, in the given context.

Still before we start discussing the elements of design review[Threat Modelling] in the following posts, a short definition below with respect to web application review:

‘Threat modeling is an art of finding security flaws in and around a web application given its environment, purpose and context leading to direct or indirect compromise or loss to business.’

Note: 

The reader is expected to possess basic understanding of how web applications work and offensive attack techniques that could be used to subvert the same.

 In the future posts, I shall touch upon many aspects of Threat modeling and design review. The reader should keep in mind that these just list some checkpoints in the context of threat modeling web applications and are not exhaustive in any way.