How to Leverage Threat Modeling Findings to Enhance Security Across the SDLC

Kuldeep Kumar

Threat Modeling of a software or one of its components or even a single feature can lead to a lot of important gaps / findings. These outcomes are very useful by themselves but can also be utilized during different phases of the SDLC to further improve security posture and planning with intelligent capturing and processing. This blog expresses how we can go about doing this.

Table of Content

  1. Findings of Threat Modeling
  2. Capturing and Processing of Findings
  3. Why do this ?
  4. Where to utilize outcomes of Threat Modeling ?
  5. Conclusion

Findings of Threat Modeling

Threat modeling works to identify, understand and communicate threats and gaps within the context of protecting something of value. Outcomes are existing gaps in the system.

Capturing and Processing of Findings

We need to make sure that below conditions are fulfilled in the mentioned way or similar other way.

  • Findings must be stored in a single place like jira or some bug tracking system so that they can be accumulated and analyzed with ease.
  • Metadata – Findings must have metadata like below
    1. Finding Category & subcategory – You can create your own customized categories or you can start with one from CWE here – https://cwe.mitre.org/data/definitions/1000.html 
    2. Software product name and component or service name of the software in which finding is observed.
    3. Finding’s Severity level and if possible risk level as well.
  • It should be possible to pull the findings along with metadata to see the distribution of category and subcategory and other metadata for analysis.

Why do this ?

This data can be used to make data informed decisions (which is obviously more beneficial) about areas like security training, pentest, security tests, planning etc.

Where to utilize outcomes of Threat Modeling ?

  • Security Trainings
    • Plan for security training for developers and security engineers based on the category of findings found in threat modeling with most risk.
  • Security Testing
    • Plan to write automated test cases for capturing the category and/or subcategory of a class of threats which are found to be highest risk.
  • Security Tooling
    • Tooling can be chosen or tuned to capture the most vulnerable or weak areas.
  • Penetration Testing
    • Several kinds of pentests can be planned based on this data.
      • Pentest to make sure that those Threat model findings are fixed.
      • Pentest only for high risk components of the software.
      • Pentest for software components with repeatedly high risk findings.
  • Security planning and Strategy
    • Product security plans can be created keeping in mind the category of findings which are repeated and most risky software and/or components across the company.
  • Requirements Gathering
    • Choose to collaborate with product managers or product owners early on the product or components which have repeatedly high risk findings. This is especially when you do not have enough resources and have to pick the most risky ones.
  • Architectural Changes
    • Pick and choose and Initiate major architectural or strategic initiatives based on the areas or category which is widespread across the company.

Conclusion

While threat modeling in itself is a very beneficial exercise, if outcomes from it are stored in a certain way that they can be processed they are really useful for improving product security at various levels.

Happy to hear your comments, questions and feedback on my linkedin handle.

Related Posts