Cybersecurity threats are rising fast, leading enterprises that build applications to look more closely at security measures built on precautionary principles, including threat modeling, which has become core to ensuring applications can withstand future attacks.
However, a recent study from Security Compass found just 25% of organizations surveyed conduct threat modeling during the early phases of software development—requirements gathering and design—before proceeding with application development.
Moreover, less than 10% said their organizations perform threat modeling on 90% or more of the applications they develop, and more than half of organizations face challenges in automating and integrating their threat modeling activities.
“The traditional threat model is time-consuming, often taking days to complete,” said Security Compass CEO Rohit Sethi. “The list of threats, countermeasures and diagrammatic representation can quickly be rendered obsolete given the pace of modern software development.”
Moreover, the “STRIDE” method of determining threats is error-prone and can easily leave out evolving attacks, he added. That method does not incorporate the increasing burden of regulatory compliance, such as data protection laws, that also need to be factored into software design, he said.
“Perhaps more importantly, a good threat model requires security expertise that is in short supply at nearly every organization,” he noted. “This leads many organizations to either focus threat modeling on a smaller number of important applications and create threat models without using them to inform secure design, perform modeling simply as a compliance exercise or abandon the effort entirely.”
Sethi said if organizations really want to achieve the goals of their threat modeling initiatives, they need to balance the business needs of faster application development with the goals of risk management.
Automating Threat Modeling
“Doing this effectively, at scale, requires automation,” he explained. “Large parts of threat modeling can be automated.”
For example, defining a list of well-known “threats” in software design doesn’t necessarily require manual analysis; we already know that certain technologies, features and programming languages are susceptible to well-known software security weaknesses documented in the MITRE Common Weakness Enumeration (CWE).
“It is possible to automate linking the technical attributes of software to potential threats and corresponding countermeasures,” he said, adding that automation doesn’t need to be expensive.
While robust commercial tools aren’t free, Sethi said the total cost of ownership (TCO) is substantially cheaper than the alternative of hiring more security professionals to do manual work, having developers spend precious engineering cycles on security defects or the cost and distraction of dealing with regulators and lawsuits as a consequence of not following industry-accepted best practices.
Sethi said organizations would also need to lean on threat modeling processes and tools to address the increasing burden of regulatory compliance on software development, explaining that existing governance, risk and compliance (GRC) programs are simply not optimized for software development.
He said it’s instructive to look at the successes of the United States Department of Defense, which recently pioneered continuous authority to operate (ATO) as a model for how companies will integrate secure-by-design processes that tie into DevSecOps.
“We are also seeing a trend where organizations are looking to abstract security concerns away from software developers by seamlessly embedding appropriate controls in frameworks, containers, microservices and other infrastructure components,” Sethi said.
This means tracking which controls are being implemented at which component and making sure there are no material gaps; these will be a key benefit of threat modeling in the future.
More Maturity, Better Situational Awareness
Chris Morales, CISO at Netenrich, said that while threat modeling has always been important, few organizations practice it, because it takes a level of understanding about how attacks function and relate to the attack surface that few individuals have the time or knowledge to perform.
“That has changed with time as security is maturing; more people better understand attacks, and we have adopted common taxonomies like MITRE ATT&CK and evolved methods like Microsoft STRIDE,” he said.
Morales pointed out how threat modeling has expanded to look at the entire enterprise attack surface of users, assets and connections.
“It provides a quantitative method for risk management by assessing how an organization would fare against real threats before there is a problem,” he said, conceding that threat modeling is a time-consuming process.
“We need to move to operational models that allow for a lightweight form of modeling to understand current security posture against threats in the wild actively targeting an organization’s resources,” Morales said.
That means automating as much as possible to enable constant output that provides situational awareness to all parts of the organization—not just the SecOps or DevOps team.