DEVOPSdigest

Threat modeling has become an integral part of the software development process, providing developers with an opportunity to identify security threats and vulnerabilities and create logical remediation methods.

While threat modeling appears straightforward in concept, it features many variations and nuances in practice. The diversity of threats and vulnerabilities requires developers to evolve threat modeling practices to the current security landscape.

The ability to adjust to different threat environments is core to the concept of threat modeling. The process focuses on protecting a system in a risk-based way instead of simply following a standard checklist. Let's look more at threat modeling, how the practice started and how it continues to flourish today.

The Origins of Threat Modeling

In the mid-1990s, Microsoft engineers Praerit Garg and Loren Kohnfelder developed STRIDE, a mnemonic device for security threats that is seen as the first threat modeling process. STRIDE (which stands for: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege) works to remind developers of what threats a platform may face.

Since then the tools and models have improved and simplified threat modeling. Advancements in threat modeling include:

■ Data Flow Diagrams (DFD). These help visualize how data flows through a system, allowing developers to identify potential weak points in the security architecture.

■ OWASP PASTA. The Open Web Application Security Project's PASTA (process attack simulation and threat analysis) serves as a methodology that emphasizes identifying threat impacts earlier in the development process. It also recognizes that risks should be ranked based on their overall severity.

■ OWASP ASVA. ASVA (application security verification standard) is a checklist replacement for STRIDE. It goes beyond STRIDE and evolves to become more comprehensive.

Threat Modeling in Today's Environments

Today's threat modeling tools can automatically analyze infrastructure-as-code in a DevOps pipeline for threats and provide recommended remediation. As cyber-attacks continue to be on the rise, companies have begun to understand the importance of including security as part of their DevOps pipelines.

Too often, security was either left out of the development process or instituted later in later stages. The driving force was often speed, as DevOps environments pushed for quicker development times, leaving security as an afterthought.

Developers often lacked the proper skills to add security controls. Developer training has usually focused on application development and the ability to add functionality with security seen as a necessary — and often underdeveloped — evil that slowed execution.

With growing security threats, the practice of simply having security "bolted on" at the end does not work, especially in CI/CD pipelines. However, this can be challenging as security risks can arise during the integration stage until the DevOps model is fully implemented.

A Better Path Forward

Security practitioners continue to push security development left. The emergence of next-gen threat modeling and increased automated technologies during the development process will further add benefits.

When implemented correctly, threat modeling can create system-wide security improvements, knowledge sharing among teammates, proactive design guidance, and improved communication between stakeholders.

Threat modeling technologies continue to advance and move past the manual and outdated structures that developers long relied. Using automation, enhanced collaboration, and more robust libraries for threat model templates will improve the speed and scale of development.

As we continue forward, we will see a Github-ification of threat models. Developers will share threat models to improve overall development, allowing developers to create similar tools and the ability to communicate from a collective expertise.

Threat modeling has made tremendous strides in the past 25 years. As we move forward, continued advances will strengthen the process and bring a higher level of security to the DevOps process.