I’m slowly trying to introduce some security concepts such as
# What is Threat Modelling?
A threat model is essentially a structured representation of all the information that affects the security of an application. In essence, it is a view of the application and its environment through security glasses.
Threat modelling is a process for capturing, organising, and analysing all of this information. Threat modelling enables informed decision-making about application security risk. In addition to producing a model, typical threat modelling efforts also produce a prioritised list of security improvements to the concept, requirements, design, or implementation.
Although the overall implementation of the Rules Manager is an internal tool, it still has various routes into the application from third party sources (Charles River Development), REST API's via the Gateway and even from systems such as the Active Directory.
Most of the time, a threat model includes:
* A description / design / model of what you’re worried about
* A list of assumptions that can be checked or challenged in the future as the threat landscape changes
* A list of potential threats to the system
* A list of actions to be taken for each threat
* A way of validating the model and threats, and verification of success of actions taken
# Why
The inclusion of threat modelling in the SDLC can help
* Build a secure design
* Efficient investment of resources; appropriately prioritize security, development, and other tasks
* Bring Security and Development together to collaborate on a shared understanding, informing development of the system
* Identify threats and compliance requirements, and evaluate their risk
* Define and build required controls.
* Balance risks, controls, and usability
* Identify where building a control is unnecessary, based on acceptable risk
* Document threats and mitigation
* Ensure business requirements (or goals) are adequately protected in the face of a malicious actor, accidents, or other causes of impact
* Identification of security test cases / security test scenarios to test the security requirements
# 4 Questions
Most threat model methodologies answer one or more of the following questions in the technical steps which they follow:
### 1. What are we building?
As a starting point you need to define the scope of the Threat Model. To do that you need to understand the application you are building, examples of helpful techniques are:
* Architecture diagrams
* Dataflow transitions
* Data classifications
* You will also need to gather people from different roles with sufficient technical and risk awareness to agree on the framework to be used during the Threat Modelling exercise.
### 2. What can go wrong?
This is a "research" activity in which you want to find the main threats that apply to your application. There are many ways to approach the question, including brainstorming or using a structure to help think it through. Structures that can help include STRIDE, Kill Chains, CAPEC and others.
### 3. What are we going to do about that?
In this phase you turn your findings into specific actions.
### 4. Did we do a good enough job?
Finally, carry out a retrospective activity over the work you have done to check quality, feasibility, progress, and/or planning.
* The OWASP Cheat Sheet goes into more detail (https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html). For the Nexus Risk Management System, periodic reviews of the service will be documented in the various child pages.
A good resource that I’m treating as a bible is a series of articles by Tanya (shehackspurple)
I’m a newbie, but I’m trying to learn more about app security and try and think about these concepts as early as possible. I think if nothing is implemented, at least the awareness of security has been raised. It’s good to make the PO’s and BA’s think about the Non Functional aspects of the software. It raises the game for everyone IMO.
