Developers are starting to embrace the idea that threat modeling is a best practice as part of the secure development lifecycle (SDLC). And if it is, it can no longer be seen as a project. It must evolve into a process.
A Project vs a Process
Projects and processes are very different. A project has a beginning, a middle and an end. It has tasks and due dates and deliverables. Projects have an air of finality about them. And when it comes to increasingly sophisticated and ever-changing cyber threats, that’s a problem. According to Deeptesh Bhattacharya at software outsouorcing firm HCL, “The key challenge is finding ways to adopt a security framework for designing robust enterprise applications, as it is becoming difficult to stay updated with ever changing attack surfaces and threats and vulnerabilities.”
A process on the other hand is a series of steps designed to be repeatable and ongoing. And when it comes to increasingly sophisticated and ever-changing cyber threats, ongoing is the only way to deal with them. Installing a server is a project, monitoring the server is an ongoing process. And so it must be with secure software development.
It makes perfect sense. Software development is no longer thought of as a project with a deadline, but rather it has a continuous life cycle of continuous improvement (i.e., SDLC). The problem comes when you try to cram a threat modeling project into an ongoing process of continuous improvement.
Evolving from a Threat Model to Threat Modeling
When it first began, threat modeling was a project and the deliverable was the threat model. You diagramed the system, modeled the threats and researched the mitigations. This may even have been done by a specialized threat modeling team. Then the threat model was handed off as a finished project to the development team so they could incorporate the mitigations into the software. In this manner threat modeling does not fit neatly into the CI/CD lifecycle.
This limitation is due, in part, to the open source tools being used for creating threat models today. They were and are project tools. Meant to produce a deliverable. Never meant to be part of a process.
Open Source Limitations
One of the most popular open source threat modeling tools is OWASP’s Threat Dragon. And while it is claimed to be part of a secure development lifecycle, it is still more of a project tool than a process tool.
According to a published review of Threat Dragon by Mr. Bhattacharya, it offers “no integration with CI/CD pipeline.” And while “There is cloud version which provides CI/CD integration, [it’s] only with GitHub projects.”
Capabilities of a Threat Modeling Process
For threat modeling to truly become a process and part of the software development lifecycle, it must have the ability to keep up with the pace of change. Not just changes in threats, but also changes in the architecture.
In cloud architectures where VMs and containers get spun up and decommissioned constantly, threat modeling as a delivered project no longer makes any sense. Not only must threat modeling be a process interwoven into the SDLC, it must have capabilities that keep up with the pace of change.
These capabilities include things like one-click auto-discovery, mapping and diagraming of cloud environments. It also includes the ability to instantly recommend mitigations rather than asking users to research them. And it includes the ability to continuously monitor the live environment in real-time for changes in the cloud environment and send alerts immediately when detected.
If you’re ready to evolve your threat modeling practice from a project to a processes, reach out to Threat Modeler to see how we easily can make that happen.
Schedule a demo today with our cybersecurity experts and fortify your operations!