Current challenges with threat modeling
We need to give a lot more thought to make our applications and systems secure and robust. Many security teams use data flow diagrams as a means to generate security requirements for identifying threats.
Unfortunately, developers cannot easily integrate data flow diagrams into their workflows because of its complexity. In fact, data flow diagrams weren’t originally designed for risk management. So we are still using legacy threat modeling processes to build security in modern systems. It doesn’t fit; and it’s not the right tool for application security.
There are some well-known challenges with threat modeling methodologies today.
You aren’t given enough time to draw diagrams for threat identification.
To make this valuable, the analysis is limited to a small part of the overall system.
The diagrams created are rarely kept up-to-date because of the speed at which we’re moving and changing.
The feedback loop isn’t strong enough.
The disconnect between security and DevOps
In DevOps, our intent is to create a Minimum Viable Product (MVP).
We want to conduct threat modeling as part of this MVP, but find ourselves slowing down since we must think about multiple attack scenarios, potential threats, and possible mitigations.
Unfortunately, the rest of our DevOps teams can’t wait for this information because they need to meet a release deadline. This is the first problem we face. To mitigate this risk, many teams rely on late-cycle penetration testing or a DAST scan. Therefore, security testing gets pushed to the right of the SDLC, whereas in DevOps we’re trying to shift security to the left. Therein lies the current tension between these two teams.
The second problem we face is not taking into account the different perspectives on risk and security. Security experts already know about security risks. Development teams are becoming more aware of the Ops risks but they are not aware of risks to other teams. What’s missing here is alignment and collaboration. We don’t make the right stakeholders aware of a problem or that something of the ordinary has occurred. So how can others possibly fix it? How can others be aware of the bigger implication? Relationships and involving more stakeholders is something we’re still hugely missing.
The third disconnect between Security and DevOps is model versioning. In functional testing, we have inputs to our tests, we have code for our tests, and we have the expected and actual output. That becomes part of our documentation. So why aren’t we doing the same thing with threat modeling? This information is not perpetually stored somewhere in a repository so we can conduct version control. We can represent our threat models as JSON or something similar. We also have a wealth of information and stats from our monitoring tools but we are not using them effectively.
It’s no longer just about the horizontal shift-left testing across DevOps pipelines.
Now we have to shift vertically up (shift-up) in the organization to the business teams. We’re going to have different people at different levels that are going to extract value about risk from a threat model.
This broadens the scope of what a team or an individual conducting threat modeling provides as an input. We can map cross-functional elements of a threat model to concrete requirements that a development team can execute. The definition of threat model has expanded. It’s not just about data flows, but now incorporates concepts like risk.
Balancing speed and risk
We need to balance both speed and risk. It’s not either this or that.
This is not going to come nice and tidy; it’s not perfect. Information has to come from all the stakeholders. We will discover risks we had not considered previously because it was never articulated. We didn’t think that certain scenarios could occur.
Sometimes we will find more risk, have to add a bit more time, a bit more money, and slow down slightly because it maybe something new. In this sense, threat modeling is about a cross-functional approach that integrates risk, security, and development perspectives.
If you want to learn about the right threat modeling approach for your organization, download our threat modeling whitepaper now.
About Security Compass
Security Compass, a leading provider of cybersecurity solutions, enables organizations to shift left and build secure applications by design, integrated directly with existing DevSecOps tools and workflows. Its flagship product, SD Elements, allows organizations to balance the need to accelerate software time-to-market while managing risk by automating significant portions of proactive manual processes for security and compliance. SD Elements is the world’s first Balanced Development Automation platform. Security Compass is the trusted solution provider to leading financial and technology organizations, the U.S. Department of Defense, government agencies, and renowned global brands across multiple industries. The company is headquartered in Toronto, with offices in the U.S. and India. For more information, please visit https://www.securitycompass.com/