Threat Modeling’s Place in DevSecOps
Published September 30, 2020 WRITTEN BY MICHAEL SOLOMON Michael G. Solomon, PhD, CISSP, PMP, CISM, PenTest+, is a security, privacy, blockchain, and data science author, consultant, educator and speaker who specializes in leading organizations toward achieving and maintaining compliant and secure IT environments. Developers often pursue well-intentioned security efforts by focusing on writing secure code. But that’s just part of the puzzle. Instead of focusing only on the code, it’s just as critical to focus on the attacker. Understanding how attackers compromise controls changes the way developers think about security. A revealing question is: “How could an attacker use my code for malicious purposes?” Thinking in this way changes the whole development perspective. The general process of assessing vulnerabilities in software from an attacker’s point of view is commonly referred to as threat modeling. The main purpose of threat modeling is to assess an application and its surrounding environment to find as many vulnerabilities as possible before attackers do. Threat modeling isn’t new; mature development organizations have been threat modeling for a couple of decades. One of the earlier approaches to formal threat identification was the idea of “threat trees,” introduced by Edward Amoroso in 1994. A similar early view came from Bruce Schneier in the form of “attack trees.” Both approaches use conceptual diagrams to illustrate how a target might be attacked. Microsoft was an enthusiastic early adopter of formal application development threat modeling and introduced the STRIDE approach. A few years later an operations-centric approach, OCTAVE, was introduced. Today, threat modeling is finding renewed interest as organizations move toward DevSecOps approaches. Some may consider threat modeling an artifact from the ’90s, but the philosophy fits well into current development approaches. Introducing threat modeling to a DevOps team Traditionally, threat modeling is an application design activity. However, solutions are emerging that use testing and post-deployment behavior to feed threat modeling analysis. In short, threat modeling has moved from application design to include operations. That means DevSecOps can benefit at all phases from comprehensive threat modeling. Expand your thought boundaries Remember, DevSecOps is a culture, not an organization. It’s all about removing isolation and barriers that tend to compartmentalize activities and valuable information and reduce both efficiency and quality. Prior to DevOps or DevSecOps, most organizations created silos of process and information and protected the integrity of those islands. That’s not to say that silos were created exclusively with selfish intent; silos tend to be self-preserving and naturally occurring. But in reality, breaking down silos leads to better communication, higher product quality, and more longevity. Sharing tribal knowledge and using it to “sand down the rough edges” of a product or service makes the entire development process better and customers happier. This requires change, and while change may be good, it often isn’t fun. Resistance to change tends to be one of the most difficult barriers to clear in any project. You must convince the stakeholders that the proposed change is worth the effort. In short, you have to change the culture of the comfortable norms. Change for the sake of change doesn’t get you very much. But change to pursue growth can be satisfying and rewarding. It is the latter type of change that makes threat modeling a good fit for a DevSecOps organization. The two philosophies work well together. […]
