Threat Modeling

What is Threat Modeling?

A model depicting a software systems architecture that can help us to know 360 degrees of security threats. The main goal of Threat Modelling is to gain visibility of the threats, the mitigations and controls in place thereby accomplishing the “Know your threats” security engineering principle. A good threat model answers the below

1. What are we building?

2. What can go wrong?

3. What are we doing about it?

4. Are we doing a good job?

Pros

• Good ROI

• A holistic view of architecture and threats

Cons

• Time-consuming

• Skill gap

• heavily depends on who does the threat model until and unless an active running checklist is maintained

Choosing the right Threat Model Technique

Below is the list of Threat Models with their pros and cons. Choose according to the need of your company.

Major of the threat models fall under

1. risk-centric/attacker centric - Threat model focusing on Threat Actors

2. asset-centric- Threat model focusing on assets, crown jewels of the organisation

Selection of Threat Model

• Easily Adaptable - Easy to use and integrate, less time consuming

• Good ROI - is it worth it?

• Scalable - coverage/scale across company services

• Reliable - Adoption, documentation and community support

From the above-listed threat models, OWASP TM , RTM and PASTA look promising to adopt in a company. Out of 3, Owasp threat modeling seems to be a more promising approach to rely on and begin with in a company. PASTA can be considered in future cases as we mature the threat model in the company.

The above can vary according to the company’s environment and use case

Threat Modelling vs Design review

• Threat Modelling focuses on what threats we face and how we can mitigate them in earlier stages.

• Threat modelling does not need to be done in every feature until and unless there is a change in architecture.

• Design review is done on the developer’s architecture diagrams and not on security perspective/pov whereas threat modelling is done on security pov.

• Design review is done on HLD & LLD mostly on use case flow, database design, API design etc which happens for a new feature or change in an existing flow whereas the threat model focuses on a higher level overview of the entire service and does not focus on preciseness and in-depth.

• TM depicts the overall threat of the respective services.

What do we want to achieve through this?

• Know Your threats and their mitigation.

• Finding bugs in the system before the development and release phase of SSDLC and thus reducing the development costs.

• More visibility.

When to do a threat model?

Threat model need not be done for every feature/change. In the beginning stages, do a threat model for each service or a new changeover like a feature x. After a good threat model is achieved, the threat model is done on a needed basis when a new component is added or changed in the architecture

Bimonthly Threat Model Review

Each service Threat model will be reviewed on a bi-monthly basis for the beginning and then, if needed, the threat model will be reviewed half yearly. In this review, feedback for TM will be discussed and the improvements including critical questions in each threat model to facilitate a successful threat modelling at a company

Accountability & Responsibility

Accountability & Responsibility will include the following.

1. Owner & Facilitator will facilitate the threat model review and own decisions

2. Service Owners ( security partners) will execute the threat model along with developers for their respective services. They can be security champions as well.

Threat Modeling as code

1. ThreatSpec

2. ThreatAgile

3. DrawIO

Tools

1. Owasp Threat Dragon

2. Microsoft Threat Modeling Tool

3. PyTM

Communities & Newsletters

1. shostack.org

2. ThreatModelingConnect

Metrics

1. Number of Security Recommendations/requirements/bugs found from threat modelling

2. Number of Services following Threat Modeling

3. Number of threats mitigated/unmitigated