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.
Anticipate conflict
If you’re new to the DevSecOps approach, it isn’t really that different from the physical product development process. Consider the process of designing a new and improved saddle for a bicycle. Why would anyone need a new saddle in the first place? It makes sense to talk to the cyclists, but also to the bicycle sales and repair shop personnel to learn what they encounter on a daily basis. Then, learn from manufacturing what has worked in the past and what hasn’t. Forming a design team that includes designers, manufacturers, and sales and repair personnel helps to result in a better product — one that works and meets a need.
DevSecOps is very similar to this example. All parties can learn from one another and work toward the greater good. That doesn’t mean everything is happy and easy. In some cases, differing perspectives result in conflict. Conflict has gotten a reputation as being a bad thing, but conflict that is handled well is healthy. Conflict avoids having an entire team blindly pursuing a dead end.
Resolving conflict early is always better than having to deal with it when the mitigation costs are higher. Many times, bringing disparate personnel together results in discoveries that sound like, “Oh, I never thought about that.” That’s the value of bringing operations personnel, along with security personnel, into the software development process.
Focus on more than functionality
Threat modeling focuses on more than just functionality. It considers how that functionality can be used in a malicious manner. Traditional testing evaluates how well functionality aligns with design goals. Although comprehensive testing includes edge cases and should explore tolerance to out-of-bounds input, there is generally little focus on functional misuse. Threat modeling focuses on creative ways attackers can misuse software. The result is a richer assessment process that produces better code.
Operations can provide valuable input here. Who is better to conjecture how software may be misused than those who are responsible for supporting the deployed product? Trained security personnel may know about many types of malicious use, but operations probably sees some creative situations that no one considered during design. That’s the whole intent of DevSecOps: bringing everyone with relevant input to the table.
The DevSecOps workflow stitches all the pieces of the software development process together into a single thread. This continuity helps to trace flaws, including security-related ones, back to the design decision. The ability to determine the provenance of a flaw can be very valuable to process improvement. Understanding how design decisions impact the final product helps the team to stop doing things that negatively impact the products and to do more of the stuff that turns out well.
Threat modeling can inspire esprit de corps
The traditional development model is that development activities flow downstream, eventually to operations. Once a product has been “operationalized,” feedback will be collected and then returned to development. Operations only influences the next version of a software product.
DevOps and DevSecOps include operations in the development process. That means operations and security both affect the current version of the software product. Instead of fixing flaws after deployment, DevOps and DevSecOps bring operations into the process from the beginning.
When considering threat modeling, development no longer has to “do it all” and get it right the first time. Including security and operations in a DevSecOps culture brings voices of experience with different perspectives to the design table. The effort and risk are spread out among multiple competencies, and everyone enjoys being a part of a cohesive team.
Any good team benefits from diversity. Few people possess all the competencies to create a functional, efficient, secure, and profitable software product. Teamwork is a requirement for software development success. Threat modeling fosters communication among disparate parties. Open communication leads to more personnel satisfaction and higher product quality.
Just switching to DevSecOps and embracing threat modeling won’t magically fix all your problems, but it can be a start. When employing healthy team dynamics, DevSecOps teams that embrace threat modeling can achieve higher levels of security and team member satisfaction. Being an active part of a good solution is a powerful motivator.
Reaching a goal won’t happen without first defining it
Although DevSecOps and threat modeling may seem like great and easy solutions, they do take effort. The first step toward implementing any change is to clearly define your goals.
With threat modeling, the goal is to produce secure and functional software. Defining what “secure and functional software” really means is a big topic on its own. Regardless of the specific definitions of “secure” and “functional,” each organization also needs a set of clearly defined design goals for its software. Every activity must directly support one of the organization’s stated goals.
Unfortunately, security is all too often reactive. Embracing threat modeling moves security earlier in the design process, making it proactive. To get there, you must define your threat modeling goals, choose an approach, and start using it.
Here are a few interesting resources to get you started:
- Awesome Threat Modelling: This site has a comprehensive list of threat modeling resources. Whether you’re new to threat modeling or want to learn more about it, this site is a great resource.
- ThreatModeler: This relatively new automated threat modeling solution for cloud environments helps identify and predict attacks.
- Microsoft’s Threat Modeling Tool: This tool is several years old, but it gives you a lot of information about how Microsoft views threat modeling.
Regardless of the approach you use, threat modeling can make your DevSecOps team work better and increase product quality. You just have to start thinking like an attacker.
