DevSecOps and the importance of threat modeling [Q&A]

In the past security has been something that was added only at the end of the development process. But as release cycles have accelerated this is no longer a viable approach.

DevSecOps (development, security and operations) is all about automating the integration of security at every phase of the software development lifecycle.

It's still a relatively new idea though, so we spoke to Archie Agarwal, founder and CEO of ThreatModeler, to find out about the current state of DevSecOps and its role in managing threats.

BN: What are your thoughts on the current state of DevOps/DevSecOps?

AA: It is hard enough to find DevOps expertise, let alone introduce security expertise into a DevOps practice. And while traditional organizational structures have begun to experience successes in integrating code scanning and open source security into DevOps tooling and software lifecycles, certain security activities, such as threat modeling, are hold-outs. They've not enjoyed the tool support that provides the speed and automation necessary to participate in DevOps practices.

Organizations increasingly acknowledge that threat modeling and secure design need to be baked into the DevOps lifecycle, not just code scanning. They go a step further: securing design needs to be part of the process the moment engineers commit or share code. Security risks arise especially during pull/merge requests, which reflect the integration stage, and so threat modeling makes a great addition to coding workflows.

BN: What are some ways you expect DevOps/DevSecOps to change in the short and long terms?

AA: As DevOps practices look to incorporate security activities beyond source code scanning and open source security, they wonder what other activities could be practically added to engineering platforms and which simply require too much manual effort to be effective at scale.

Organizations are trying to get beyond low-hanging fruit, like 'storing secrets in public repos' and alleviate impactful business risks like authorization flaws or sensitive data exfiltration.

In the short term, we see organizations trying different security activities within their DevOps pipelines, such as dynamic testing or threat modeling. Additionally, we expect teams will increasingly rely on infrastructure as a Code (IaC) to deploy and manage application environments. IaC provides significant cost reduction, an increase in speed of deployments, and the opportunity to use threat modeling platforms to automatically discover, diagram, and find risks within architectures being developed.

What won't change in the long term is the need to provide pipelines with automated security activities.

BN: How has threat modeling evolved over time?

AA: Threat modeling has significantly changed over the years, mainly from a do-it-yourself model to a one-click threat modeling solution. The beginning of threat modeling started in the 1990s with STRIDE, which was a framework used to prepare architects to design for threats. STRIDE stands for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Since then, data flow diagrams (DFD) came into play, facilitating engineers to develop simple diagrams to direct security unit testing. Building from there, OWASP's PASTA (process attack simulation and threat analysis) took diagramming and adversarial analysis a step further by providing a valuable process-based approach to threat modeling. Next OWASP introduced ASVS (Application security verification standard) which essentially is like a manual mouse trap for threat modeling.

Today we have built ThreatModeler, an enterprise-scale threat modeling, and collaboration tool, that combines many of the aspects of tools that came before us -- but in as close to a one-click threat modeling as there is. Threat modeling can now discover and monitor cloud environments automatically, generate the visual diagrams, and recommend mitigation controls on its own within the DevOps pipeline. The future of threat modeling is a self-service model where developers do their own threat modeling with a high degree of automation, - with no security expertise required.

BN: What gaps did you recognize in traditional threat modeling and how did that inspire you to start ThreatModeler?

AA: ThreatModeler was created to address the shortcomings of data flow diagrams, bring threat modeling capabilities in-house, and make it scalable. Traditional threat modeling suffered from paralyzing complexity and an inability to develop comprehensive visibility of the attack surfaces.

I wanted organizations to be able to design security from the start and within the cadence of DevOps workflows. Additionally, I thought it was the ideal next progression in the threat modeling evolution to get rid of manually created inconsistent and incomplete diagrams and instead be able to automatically convert IaC to diagrams and then into threat models. Since ThreatModeler was launched in 2013 as a commercial product, our offerings have significantly grown and automated the process of threat modeling, facilitating compliance.

When we started threat modeling was only considered important to the most mature security initiatives. The vast majority of organizations didn't aspire to achieve this maturity and remained content using Microsoft’s free tooling. In 2015, organizations began to see the limitations of free tooling at enterprise-scale. We made a pivot to an enterprise version and transitioned from a desktop tool to a SaaS web-based collaborative tool built for the enterprise.

BN: How can security teams and developers better work together to protect IT infrastructures?

AA: Organizations might deal with pushback from both the engineering and security teams because, in a DevSecOps model, we are really asking both teams to adjust their traditional workflows to incorporate what was previously the other’s responsibilities. Security can help engineering by using tools to continually update development repositories with diagrams and threat models that reflect the current state of development: attack surfaces, risks, and security controls. DevOps and Engineering can help by committing to orchestration using IaC, and to integrating threat modeling into their SCM workflows: evaluating and securing design in the context of the risks threat modeling identifies,

BN: Can you explain the value of threat modeling as a process instead of just a project?

AA: Organizations that get the most value out of threat modeling view it not as a point-in-time activity, but instead as a capability. Maturing organizations distribute the activities that constitute a threat modeling capability throughout their software lifecycle, pairing each threat modeling technique with its functional equivalent continuously. When infrastructure or cloud configuration changes the threat modeling tool monitors these changes and updates the diagram's attack surfaces, resources, and assets. With the help of defect discovery activities like pen testing and scanning code, potential attack vectors are added. Each activity feeds into an ongoing and comprehensive process. If your threat model does not evolve with your code, then it's immediately out of date and less useful. Without updating it to include discovered defects, it will miss key attack vectors and outcomes.

BN: Why do you still need pen testing when threat modeling can show you the vulnerabilities before you start the work of building an app or migrating to the cloud?

AA: Pen testing provides a point in time view of security posture, specifically identifying the vulnerabilities in networks, applications and access privileges for internal and external account users. It can be a valuable addition to a threat modeling capability allowing DevSecOps teams to discover and augment their model with the additional vulnerabilities or bugs that allow adversaries to open and actualize new attack vectors. Once understood, organizations use threat modeling to identify the risk of these attack vectors and remediate any flaws.

Pen testing is a natural companion to threat modeling continually feeding it new attack vectors to consider in attack modeling and secure design activities.

Likewise, threat modeling informs penetration testing, allowing organizations to save time, money, and resources by focusing on those motivated adversaries, the assets they value most, and the attack surfaces to which they have access.

Image credit: jaizanuar/depositphotos.com