Threat modeling: The foundation for a devsecops culture

Threat modeling: The foundation for a devsecops culture

IF YOU WORK IN THE REALM OF SOFTWARE, YOU MAY HAVE HEARD OF THE TERM THREAT MODELING, BUT WHAT IS IT?

 

What Is Threat Modeling?

To put it simply, threat modeling is the process of identifying potential threats and security mitigations to protect something of high importance i.e., intellectual property or confidential documentation and then prioritising those threats accordingly.

Why is it important?
For a number of reasons, one in particular being the education of the development team, important for building a DevSecOps culture in the enterprise. It’s vital for security teams to better protect their apps and this can be achieved through the art of continuous threat modeling of apps.

 

Threat modeling unites the security architect, the operations/infrastructure team and lead developers, all of whom contribute to the document referred to as a threat model. It’s a culture of communication and collaboration, helping teams build an understanding of each others roles, objectives and pain points. While this alone isn’t enough to implement DevSecOps, it will impact the software development 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 onto 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 is 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 is 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.

Share on facebook
Share
Share on twitter
Share
Share on linkedin
Share

Reader Interactions