[BreachExchange] Threat modeling: What’s all the buzz about?

[Audrey McNeil]

https://www.helpnetsecurity.com/2018/06/21/threat-modeling/

Keen observers will have noted an uptick in activity around threat modeling
within the information security community recently with new tools being
released and strategies and methodologies being discussed on social media;
culminating in a week-long threat modeling track at the Open Security
Summit(formally OWASP Summit).

What is threat modeling?

In order to answer this question I will refer to the recently updated OWASP
application threat modeling page:

Threat modelling works to identify, communicate, and understand threats and
mitigations within the context of protecting something of value.

This is achieved by addressing the four following questions:

1. What are we building? Architecture / Data flow / Data classification.

2. What can go wrong? Main threats that apply to your application.

3. What are we going to do about that? Actions to take in response to this.

4. Did we do a good enough job? Retrospective analysis of the above.

Why is threat modeling gaining momentum now?

Never before has so much been spent on cyber security and yet despite this
we have seen an exponential growth in data breaches with the number of
cyber incidents doubling last year. This forces business and security to
ask a painful question: Are we doing something wrong?

Security has become an siloed appendage in the development life cycle

Historically security has been an independent activity which takes place at
the end of the development life cycle through methods such as pentesting
and auditing. This has become increasingly untenable as the speed of
development has increased aided by the DevOps movement unifying software
development (Dev) and software operations (Ops) together. Compounding this
the number of applications has grown significantly in our Software-driven
economy and microservices architecture adds an additional multiplier.

With a major tenet of DevOps being automation and increased deployment
frequency, appending security to the end of this process has created a
bottleneck. Throwing the application “over the wall” to an increasingly
siloed and comparatively small security team (BSIMM 8 study gives 1.6
appsec professionals per 100 developers) to perform time intensive testing
just before deployment is simply not working.

And slowing down the the development life cycle is just one problem caused
as a by-product of security being an “appendage” at the end of the process.

The other is if security is not involved from the inception of the
development cycle – the design phase – security is not baked-in from the
beginning.

Research has found it takes 5 hours work to fix & detect defects in the
coding/development stage, 5 – 7 times longer in the final testing phase and
10 – 15 times longer in production.

This research found that early and ongoing security testing cuts the time
to production by as much as 25%.

So, counter to what might be intuitively thought, building security early
and continuously into the software development life cycle is both cheaper
and faster.

In terms of security being siloed, we have become known as the “department
of no”. Perceived as always telling people what they cannot do and impeding
business. Although Development and Operations may be fusing together,
security still sits aloof. After all, who wants to communicate with people
always saying “no”.

Threat modeling as a solution

Threat modeling is all about secure design. Finding and fixing threats
early when they are cheaper and easier to remedy. As iterative changes are
made in design, the appropriate area of the threat model is re-appraised as
a “living document” which helps prioritise investment and unblock the
security bottleneck at the end of the pipeline. This has the additional
benefit of bringing predictability to the business in terms of delivery and
consistency.

And for those security activities that must take place at the end of the
cycle, threat modeling does not replace them, but rather facilitates
pentesters, auditors & reviewers by informing them of the assets in play,
controls already in place, attack surfaces, data-flows, trust-zones
boundaries and accepted risks. This all whilst reducing the design flaws
allowing them to focus on other potential security weaknesses.

At the heart of threat modeling is collaboration. It is about bringing all
stakeholders together to communicate a shared understanding of what we are
building, what could go wrong and what we can do about it. All of this
whilst considering issues such as compliance, risks, usability and others
not strictly related to security but important to other stakeholders.

Threat modeling facilitates dialogue and allows everybody the opportunity
to challenge assumptions and learn from each other in a blame-free
environment. It puts security knowledge into the hands of our
cross-discipline partners and educates us of the constraints & demands on
them.

Conclusion

There is no silver bullet in security, but we are missing a vital
ingredient without threat modeling.

Threat modeling most certainly passes the effort / reward test and has a
true ROI. The threat modelling process can become in itself the much-needed
medium of integration & communication. Using this method we have an
opportunity to turn around our backwards approach of detecting and fixing
problems at the end of the process and architect security in the design
phase at the beginning of the process and break many of the negative cycles
we currently find ourselves in.

It is never too late to begin threat modeling, we can start small, with the
projects we have at hand now, even if they are already in production.

It’s time for us as security to glue together with DevOps and become
DevSecOps and advocate for the Agile/DevOps shift left testing approach to
include security through the medium of threat modeling.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20180625/54cd511b/attachment.html>