written in front
Preparing for Threat Modeling
Form a virtual team
Four stages of structured thinking
Example of Internet of Vehicles Threat Modeling
1. What are we doing? Create a system model for vehicle registration functionality
2. What will go wrong? Identify functional threats
3. What should we do? Prioritize threats and select critical actions
4. Are we doing well enough? Assess the effectiveness of the threat modeling process
appendix
Threat Modeling Template
References
AWS teaches you how to do threat modeling
written in front
The recent "AWS re:Inforce 2022" introduced many security, identity, and compliance products and services. The author sorted out Amazon's relevant information and introduced step by step what to do in the threat modeling process.
Here I severely criticize some companies' so-called "lightweight threat modeling".
Because the essence of threat modeling is "brainstorming about threats between experienced security experts and business teams", automation, reuse, and standard processes are welcome, but threat modeling activities must be based on communication, collaboration and Human-led expertise-centric.
Preparing for Threat Modeling
Form a virtual team
Threat modeling needs to listen to a variety of different perspectives and experiences. The opinions of each team member need to be taken into account, and finally a trade-off between security, delivery, and business is achieved. It cannot be just security and technical participation, checklist, and stuck points are the bottlenecks that hinder the effectiveness of threat modeling. Specifically, five roles are required:
Threat modeling expert: is the leader of a threat modeling activity. He has rich experience and insight into the process of threat modeling and control discussion boundaries. The moderator, coach, and consultant should participate in the front line, and finally summarize the material documents. He usually works as an attacker at the same time. and defender roles.
Attacker: Discover design security flaws, similar to the sand table method, brainstorming from the perspective of attack.
Defender: Avoid over-design of security defense measures and design threat control measures.
Developer: The main module developer or system architect has a background in understanding how the current service is designed and implemented, and is responsible for clearly understanding threats and mitigation measures.
Product manager: Similar to a product manager, avoiding security measures that cause product requirements to be unfulfilled, and achieving a balance between security, efficiency, and experience.
The Four Phases of Threat Modeling
Answer four questions by trying structured thinking at different stages:
What are we doing?
Participants: All virtual team members
Deliver and design more secure software
what can go wrong
Actors: Attackers, Developers
STRIDE Mnemonic, Insider Risk, OWASPTop10, Data Security Risks, List of Threats Inside Your Organization
What are we going to do?
Participants: defenders, developers, product managers
Code control schemes, introduction of defense in depth, and security measures of cloud services are used to evaluate the improved scheme without affecting requirements.
Are we doing well enough?
Participants: Threat Modelers, Developers
Threat modeling is the analysis of risk, this judgment is good enough to distinguish between:
Threat modeling experts review threats as “complete enough” to endorse mitigations;
The developer delivers mitigation measures and conducts another code review;
Threat modeling experts evaluate the acceptance criteria, introduce security testing and project completion according to the results of threat modeling;
Threat modeling experts archive modeling results, update knowledge bases, integrate mitigation measures into platform-level security baselines, and deeply integrate with SDLC tools.
Registration Functional Threat Modeling Example
Next, take an Internet of Vehicles service solution on AWS as an example to answer how to create a system model and threat model, and evaluate the usefulness of the model. The Internet of Vehicles solution usually includes multiple modules such as IoT vehicles, drivers, vehicle registration, and telemetry data. This is a complex system, so it must be decomposed into functional and application service modules for modeling, rather than for the entire system at the beginning Create a threat model.
The example this time is split into the story dimension and simplified to "As a fleet manager, I want to register an existing IoT-connected vehicle to put it into use." In terms of specific scenario technical design, the fleet manager will Use a standard web browser to access the web portal, authenticate, and enable new vehicles to be registered into the system and put into service.
1. What are we doing? Create a system model for vehicle registration functionality
1.1. First, prepare to create a data flow diagram to represent the elements of the above vehicle registration function and the data flow between them.
The tools needed can be white paper, whiteboard, or draw.io or PlantUML. According to the above system design diagram, the system uses AWS Amplify to host front-end static resources, Amazon Cognito integration for identity verification, REST-based API provided by AWS Lambda and Amazon API Gateway, and back-end storage through DynamoDBTable and S3.
1.2. Draw system elements, data flow and trust boundaries
Between the elements, arrows are drawn to indicate that if the data flows through the vehicle registration function, the direction of the arrow is the direction of the data flow. For http and rpc requests, it means that a response must be returned to the caller, and there is no need to add a return arrow, storage and query Can be unidirectional.
1.3. Drawing trust boundaries
Determine which areas and groups of elements of the vehicle registration function can be considered equally trusted, into the same trust domain, draw dashed boxes around each area to show the unknowns of the trust boundary, and add labels to show the purpose of the trust domain, The completed vehicle registration function data flow diagram is drawn below.
2. What will go wrong? Identify functional threats
Start your threat modeling brainstorm, there is no wrong answer, the goal is to cover possible threats as completely as possible, without presupposing threats that might already be mitigated.
2.1 Using STRIDE-per-Element to find threats to vehicle registration functionality
Each element, namely human actors, external entities, processes, data stores and data flows can be mapped to a different STRIDE threat.
2.1.1 Threats from external entities Because it is a registration function, there is an external entity User. From the above STRIDE-per-Element chart, we can see that there will be threats of Spoofing (spoofing) and Repudiation (denial), which will not be detailed here. .
2.1.2 Threats to Process:
Spoofing: The identity spoofing of the process refers to each element connected to it. For example, when communicating with Amazon S3, it can pretend (spoof) the identity of Lambda and maliciously connect to the database.
Tampering: It is possible to tamper with a process if its code, configuration, or execution environment (such as memory space) is modified in unexpected ways. Consider how to tamper with the process in the vehicle registration function. For example, can I provide input to a Lambda function to modify the function's behavior?
Deny: Can a Lambda function delete a bucket object without generating an audit trail entry so that it is not attributed to the action?
Information disclosure: How does a Lambda function return a reference to the wrong S3 object?
Denial of service: Are very large objects causing problems with Lambda functions?
Privilege escalation: There is generally no difference between ordinary users and administrators in vehicle registration, and threats are ignored here.
2.1.3 Threats to data storage: Data storage may face risks of tampering, information leakage and denial of service.
Denial: If the system design does not store syslog, there should be no threat of denial. Denial: The system itself has no logging, so there is no threat of denial.
Leakage Leakage: How could a malicious person read data from a DynamoDB table, or from an object stored in an Amazon S3 bucket?
Denial of Service: How can a malicious person delete objects from an Amazon S3 bucket?
2.1.4 Data flow: When data flows through channels that may be maliciously damaged, such as shared networks and middlemen, the data may be modified during transmission.
Information Leakage: When sensitive data flows through a network that is not considered fully trusted, such as a shared network, that data may be leaked to unintended recipients.
Denial of Service: Traffic can also be the target of a denial of service threat, typically represented as a connection-affecting event such as a network isolation event or severe packet loss, preventing users from communicating with API Gateway.
2.2. Prioritize
After checking whether the threat is repeated or missed, the priority is divided into high, medium and low by estimating the mitigation cost compared with the impact. The impact of the threat * possibility = risk level. OWASP Risk Rating Methodology provides similar DREAD's risk judgment method.
3. What should we do? Prioritize threats and select mitigations
Focus risk mitigation resources on threats to specific services through some security design principles and best practices. Use some basic security services such as AWS IAM, CLoudWatch Log, CloudTrail, SecurityHub, KMS, encryption SDK, etc.
Failing that, the options are to mitigate the risk, accept the risk, or a combination of the two. If the risk cannot be reasonably mitigated due to the cost or complexity of mitigation, then accepting the risk is the only option. Regardless of the size of the risk, accepting the risk requires the review of the superior. Different managements have different attitudes towards security. .
4. Are we doing well enough? Assess the effectiveness of the threat modeling process
Threat modeling is a "security social activity" and ends with a consideration of the effectiveness of the threat modeling process for an organization by asking the following questions:
1. Do we know what we are doing? -- Are there appropriate resources, tools, processes, culture to perform threat modeling?
2. Do we know what can go wrong? --Is the number of threats found in line with expectations? Were more, the same, or fewer threats found than expected?
3. What did we do? --Are the identified threats adequately mitigated by the mitigation?
4. Are we executing well? -- Can the threat modeling process be improved? Can the security of the "vehicle registration function" be really improved? Will threat modeling be done for other functional modules in the future?
All in all, threat modeling is an investment — and in my opinion, a good one, because finding and mitigating threats during the design phase of a feature can reduce the relative cost of mitigation compared to catching threats later. Continuous implementation of threat modeling may also improve an organization's security posture over time.
appendix
Threat Modeling Template
1. Threat Hypothesis
| ID | describe |
|---|---|
| Assumption-1 | |
2. Threat Model
| priority | Threat ID | title | detail | potential threats | Selected Threat Measures | Are there link measures (yes/no) |
|---|---|---|---|---|---|---|
| threat user 1 | Attacker spoofs identity of legitimate user to API Gateway | An unauthenticated attacker can list, store, retrieve, or search documents by making requests to API Gateway. | ||||
| Threat-KMS-1 | The attacker forges the KMS identity lambda | Attackers can masquerade as KMS, for example by tampering with DNS, to trick Lambda into using it to encrypt/decrypt objects instead of real KMS | ||||
References:
https://www.youtube.com/watch?v=Yt0PhyEdZXU&ab_channel=AdamShostack
https://github.com/adamshostack/4QuestionFrame
https://www.youtube.com/watch?v=GuhIefIGeuA&ab_channel=AWSEvents https://github.com/michenriksen/drawio-threatmodeling
https://owasp.org/www-community/Application_Threat_Modeling
https://owasp.org/www-community/OWASP_Risk_Rating_Methodology