Threat modeling: The foundation for a devsecops culture

The Education of Threat Modeling

In software development, threat modeling is a great way to bring awareness to the development team where current threats to applications are concerned. Don’t be surprised if you receive pushback from architects and developers , they just want to better understand why threat hunting is important.

Use it as an opportunity to teach them. More often than not, they are asking not to be argumentative but because they have a lack of understanding as to why for instance encrypting internal communication into the application layer matters. The aim is to get them to base future decisions on the idea that communication should be encrypted by default to reduce risk to the business as a result of your teachings, be humbled.

Threat modeling almost always leads to discussion, discussions lead to an exchange of knowledge and knowledge leads to better results for all.

The Benefits

Improved application security posture is the main benefit, achieved once the impact of a threat on an application has been identified and resolved through security controls and mitigations. This forces the implementation of security in the design phase of the SDLC by injecting security by design principles into the application architecture, thus reducing threats and vulnerabilities before code has even been produced, minimising defect and remediation costs.

Threat modeling is a way of proactively defending against future security incidents. Many security leaders and personnel get caught up in a reactive security cycle, responding to isolate and patch the issue only after a security incident has occurred.
This brings me to another key benefit of threat modeling, its ability to resolve vulnerabilities before they even occur. This reduces testing and development time, which ultimately saves on costs. Application security testing is reactive, whereby code is developed and deployed in a test environment before security testing is conducted to identify vulnerabilities. Significant development and operational time are required to fix and patch these vulnerabilities.

The Challenges

AppSec can and should be automated for the most part (with the exception of what’s at the start and end of a process). Even though tools exist to help visualise and document the process, threat modeling is still a very manual course dependent on human understanding of the architecture. White hackers or “ethical hackers” are required to hack in and identify threats and vulnerabilities created by not-so-ethical hackers. This is an additional cost, but one that is necessary.

Many battle with the fact that threat modeling is not an automated process, but as threats are mitigated, new ones are found and with this in mind, automation is a challenge.

A DevSecOps Culture

Threat modeling delivers increased value through consistent and repetitive execution. This creates secure design patterns as they begin to emerge in ways that can be documented and leveraged by application development teams, contributing to the establishment of a proactive DevSecOps culture.

Design patterns serve as the basis for standard, repeatable application security requirements for the enterprise. For instance, all data in transit should be encrypted via HTTPS, and all internal apps leveraged for single sign-on (SSO) authentication. Standard design patterns and requirements developed from threat modeling can go a long way in reducing risk to an organisation, removing variety and complexity in security architectures that often lead to breaches.