Threat modelling is used in support of application development.
Implement threat modelling to evaluate the security risks associated with the software. Train the development team on risk-based assessment methodologies, conduct thorough assessments of high-risk areas, review vulnerability reports, and apply data classification to prioritize risks. This approach enables a proactive identification and mitigation of potential threats, supporting secure software development from the outset.
Performing basic threat modeling is an essential activity for identifying, evaluating, and managing system threats, architectural design flaws, and necessary security mitigations. Typically integrated during the design phase or as part of a broader security assessment, threat modeling is a collaborative process involving product owners, architects, security champions, and security testers. At this foundational maturity level, the primary goal is to increase security awareness and establish a unified understanding of system security among team members. For high-risk applications, apply an ad-hoc approach to threat modeling, utilizing simple and practical frameworks such as STRIDE to identify potential risks. To ensure efficiency, avoid long, exhaustive workshops and focus on high-relevance threats. Conduct threat modeling iteratively to align with agile and incremental development processes. For updates or additions to existing applications, target the analysis specifically on the newly added functionalities rather than the entire system. Use pre-existing diagrams as a starting point, annotating them during collaborative sessions to document discussions and decisions. For initial exercises, use straightforward tools such as whiteboards, smartboards, or even pen and paper to create actionable and practical outcomes. The objective is to foster security awareness and produce clear, actionable insights that can be readily implemented by the team.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-03-01-01-01 | Identify high-risk applications or features | Select applications or newly added features with high-risk characteristics as the focus for threat modeling efforts. | Preparation | Product owners, Architects, Security champions |
| SSS-02-03-01-01-02 | Perform iterative threat modeling sessions | Use short, iterative threat modeling workshops to identify and evaluate threats related to specific features or architectural changes. | Preparation | Product owners, Development teams, Security team |
| SSS-02-03-01-01-03 | Use simple threat checklists | Leverage basic checklists like STRIDE to identify threats without diving into overly detailed or less relevant items. | Preparation | Architects, Security champions |
| SSS-02-03-01-01-04 | Annotate existing system diagrams | Use existing architecture or data flow diagrams to identify threat surfaces and document findings during workshops. | Preparation | Architects, Security team |
| SSS-02-03-01-01-05 | Persist and share threat modeling outcomes | Document the results of the threat modeling exercise, including identified threats, their mitigations, and any agreed-upon actions for future reference and tracking. | Preparation | Security team, Development leads |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1238) NIST Secure Software Development Framework (PW.1.1) OWASP SAMM: Software Assurance Maturity Model (D-TA-1-B) |
Ensure the software design meets all security requirements and addresses identified risks by conducting design reviews. Engage qualified personnel who were not involved in the original design or use automated processes in the toolchain to verify security compliance. Assess the design against risk models, address any identified issues, make adjustments to the design or risk responses as needed, and document the findings of each review. This review process helps reinforce secure design and mitigates risks early in development.
Verify that the solution architecture systematically addresses all identified security and compliance requirements. For each interface within the application, review the list of security and compliance requirements and evaluate the architecture to confirm their integration. Conduct interaction or data flow analyses to ensure comprehensive coverage of these requirements across different components, and provide detailed insights into the design-level features that fulfill each requirement. This analysis should encompass both internal interfaces, such as those between tiers, and external interfaces, including those forming the application's attack surface. Validate and document key design decisions, especially when they diverge from established shared security solutions within the organization. Continuously update findings throughout the development lifecycle, reflecting any design changes or newly identified gaps. Highlight and document requirements that remain unmet or ambiguously addressed during the design stage as formal assessment findings. This iterative review process ensures that the architecture evolves securely, minimizing risks and maintaining compliance with organizational standards.
| ID | Operation | Description | Phase | Agent |
|---|---|---|---|---|
| SSS-02-03-02-01-01 | Map security and compliance requirements to architecture | Review the solution architecture and map all security and compliance requirements to the corresponding design components and interfaces. | Preparation | Architects, Security team, Compliance officers |
| SSS-02-03-02-01-02 | Perform interface-level analysis | Analyze internal and external interfaces for compliance with security requirements. Evaluate data flows and interactions across components to ensure alignment. | Preparation | Architects, Security team |
| SSS-02-03-02-01-03 | Validate key design decisions | Identify and review significant design decisions, especially deviations from organizational security standards, ensuring their security implications are well understood. | Development | Architects, Development leads |
| SSS-02-03-02-01-04 | Document design features addressing requirements | Elaborate and document how the architectural design meets each security and compliance requirement, highlighting key features and mechanisms. | Development | Architects, Compliance officers |
| SSS-02-03-02-01-05 | Update findings during development cycles | Periodically review and update the analysis to reflect changes made during development. Record any gaps or unaddressed requirements for further assessment. | Deployment | Architects, Security team |
| Industry framework | Academic work | Real-world case |
|---|---|---|
|
Information Security Manual (ISM-1238) NIST Secure Software Development Framework (PW.2.1) OWASP SAMM: Software Assurance Maturity Model (V-AA-2-A) |