Threat modelling
Intro to threat modelling
Last updated
Intro to threat modelling
Last updated
Threat modelling is a critical process in application security, providing a structured and repeatable method to assess and improve the security posture of a system. It involves analysing a system from an adversarial perspective to identify potential threats and determine appropriate responses. By integrating threat modelling into the early stages of the Software Development Life Cycle (SDLC), developers can ensure security is built into the system from the design phase, rather than retrofitted after deployment. This proactive approach not only enhances security but also fosters a deeper understanding of the system’s architecture and potential vulnerabilities.
According to the Threat Model Manifesto, the threat modelling process should answer the following four questions:
What are we working on?
What can go wrong?
What are we going to do about it?
Did we do a good enough job?
Ideally, threat modelling is applied as soon as an architecture has been established. Threat modelling is an activity best executed while creating the structure of systems (architecture) and especially, to discover what security elements, features, requirements and constraints should be designed (implementation specification).
Data flow diagrams (DFDs) are arguably the most common approach. DFDs visualise systems and interactions with data and other entities. This part is done using tools like OWASP's Threat Dragon or Microsoft' Threat Modelling Tool or using general purpose diagramming solutions such as draw.io. OWASP provide a codified solution called OWASP pytm:
What can go wrong?
A common framework to answer this question is STRIDE. You need to identify and rank threats with the system context.
Threat Category Violates Examples Spoofing Authenticity An attacker steals the authentication token of a legitimate user and uses it to impersonate the user. Tampering Integrity An attacker abuses the application to perform unintended updates to a database. Repudiation Non-repudiability An attacker manipulates logs to cover their actions. Information Disclosure Confidentiality An attacker extract data from a database containing user account info. Denial of Service Availability An attacker locks a legitimate user out of their account by performing many failed authentication attempts. Elevation of Privileges Authorization An attacker tampers with a JWT to change their role.
What are we going to do about it?
Responses could be to:
Mitigate
Eliminate (module/feature)
Transfer (responsibility)
Accept
A couple of examples from Microsoft and Safecode:
Taken from Safecode's whitepaper on Threat Modelling:
Person to device communication channel: threat of access by unprivileged users, use devices that have at least minimum capabilities for authenticating users, non default credentials.
Device to service communication channel: The surge in connected devices poses a significant challenge. Unlike traditional IAM systems that focus on people, IoT ecosystems involve numerous devices. These devices not only transmit data but also accept control commands. Ensuring mutual authentication between devices and cloud services becomes crucial. Unfortunately, many existing IAM solutions lack scalability to handle this device influx, posing a confirmed threat. Assigning unique identifiers to devices and linking them to users during setup is essential. Incorporating these identifiers before user setup ensures successful authentication. Symmetric or asymmetric algorithms can be used for device authentication.
Computer to service communication channel: employing username/password-based authentication is a familiar practice, akin to current web-based services. By applying similar techniques to our IoT design, we can enhance security. However, it’s crucial to take specific precautions: restrict simple passwords, limit incorrect password attempts, and provide secure interfaces for password recovery. These provisions effectively reduce the threat of compromised accounts in IoT systems.
etc.
Assemble the right team - It's a team sport. Use diverse skill sets such as business people, developers, appsec, and adversary persona (i.e. red team).
Consistent approach - Use frameworks, reduce effort, reuse templates.
Align to the software delivery methodology - Integrate TM into Agile or other tools the SDLC uses.
Use existing tools - documentation, wiki, issue tracking, language, comms, etc. Reduce friction and change.
Decompose workload - ...into smaller steps. Increase tracking and progress, improve detail. Issues with a single threat model does not become launch blocking for the entire workload, but rather just for the individual feature.
Distribute ownership - central person or department responsible for creation of threat models doesn’t work in the long run. Ensure scalability.
Identify entry points - make sure that you’re applying the entry points that are specific to the workload feature, in additional to the native endpoints for services, as part of your threat model.
Come up with threats - What can go wrong?
Evaluate mitigations - identify security controls.
Decide when enough is enough - Risk-based apetite considering likelihood and impact. Prioritise risks.
Threat modelling should be cyclical, and the model you produce should be reviewed as your system or the threats facing it changes.
Having identified the most valuable sources of logging data, you should now be in a position to begin the engineering process, to get these information sources plumbed into your SOC services.
