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.
