Security & Threat Modelling training course

OVERVIEW

One of the first steps in an Application Security programme is to perform Threat Models (which are models of an Application’s security profile, with the objective of proactively exposing potential security design flaws and vulnerabilities ).

But what should ‘Threat Modeling’ look like in an organisation like yours? Who should be involved? What should be the objectives? How should it be organised? When should it be done? What are the most common threats and attack vectors that should be considered? How do Threats evolve and change over time?

This hands-on practical session is designed to answer those questions by performing multiple Threat Models on typical inhouse Applications, and enabling a discussion between participants on the best way to execute them.

It is key that all key players in an Application Development workflow know what questions to ask (or should be asked), and more importantly, what is the ‘mesurable difference’ between teams that have performed Threat Models vs teams that have pushed products/services into production without evaluating its security profile and risks

 

Threat Modelling – Getting Started

How to get started

Who should be involved?

• An experienced threat modeler should guide the automated threat modeler software. An externally hired expert should oversee the first threat model process run for an organization.
• The Subject Matters Experts on the application are: lead developers, application architects, DevOps experts, people who know the business.

Define an approach.

• Many approaches exist, pick one. This can be done with an expert threat modeler or find an expert threat modeler to fit your chosen approach.

Define a proper scope: start small and encapsulated. Enumerate the components:

• Client SW
• Compiled binaries
• Exposed API endpoints
• Data stores
• External content providers

Create a DFD or any diagram that shows the data flows

• Data flows
• Transport layer
• Authentication
• Add trust boundaries and/or “what if” scenarios

 

 

Threat Modelling – Cheat Sheet

This Working Session aims to produce an overview of how to integrate threat modelling into an Agile/DevOps/Continuous Integration (ADCI) process. Keep in mind that a proper lightweight process should be easily repeatable with few moving parts (ie. steps). It should be flexible enough to be used with various taxonomies and libraries. The focus of this session should be on creating that process. This process will be supported and complimented by prescriptive threat modeling guidance via the Threat Modeling Cheat Sheets being developed.

What

• Define what components and steps are needed for a proper lightweight process. We should work on a definition (a “MVP” threat model) that does not include over-processing or over-variation. The process framework will drive the specific discussion points below.
• Make the framework flexible enough to accept many different base artefacts (e.g. - RACI, DFDs, lists etc.) for ADCI environments.
• Define and refine the “incremental threat modelling” concept to enable integration with ADCI iterational approaches.
• Add steps describing how to start threat modelling on an existing project/codebase without the need to cover everything (similar to introducing tests to legacy software). Build on the “10,000 ft view” model of encapsulation.
• Create a set of top-level application component patterns to speed up analysis. These asset libraries can be used to complement other libraries that may get plugged into the lightweight process. Keep this pattern library to a manageable set of elements (shoot for around 10).
• Review threat model taxonomies (eg. CIA, STRIDE, CWE, CAPEC, etc.) and decide which one(s) fit best for a lightweight process.
• Create an adaptable threat library based on current OWASP and MITRE content, and align this process with the lightweight taxonomy (or taxonomies). Keep this library to a manageable set of elements (shoot for around 10).
• Define the schema definitions for a migitations/countermeasures/controls library, again keeping the definitions top-level and flexible to enable speedy use. These definitions should leverage other OWASP content (e.g. ASVS, cheat sheets, SKF mitigation guidance, etc.) Keep this library to a manageable set of elements (shoot for around 15).
• Content from Cheat Sheets will parrallel efforts depicted by this lightweight threat modeling process.

Outcomes

• Defined: Lightweight threat modelling process with artefacts for ADCI environments
• Created: “How to” guide for ADCI environments
• Created: application component patterns library
• Created: adaptable threat library
• Created: countermeasures library schema definition
• Key process activities that tie to cheat sheet guidance