Published on
This post was written by Chris Romeo during his tenure at Security Journey.
What if I told you that you could change the security posture of your entire DevOps team without ever documenting a single line of a process? It's hard to imagine that's possible, but it is. Security behaviors take the place of process, and change how the developer approaches security decisions.
In part one of this series, “A primer on secure DevOps: Why DevSecOps matters,” I discussed the importance of DevOps embracing security within its structure. The next logical question is, how do you transform a DevOps team into an army of security people? The answer is by modifying security behaviors.
People are the true drivers of application security, and in the world of DevOps, people move fast. DevOps people are not allergic to process, but in my experience, DevOps is more about the build pipeline and automation than process. People believe that process slows everything down. But if you embed security change into everyone on the DevOps team using security behaviors, you'll empower everyone as a security person.
The three core security behaviors you need to instill include threat modeling, code review, and red teaming. Each behavior is highly dependent on the human beings. Tools are available to support each behavior, but the primary delivery agent is the human brain. Each behavior requires learning and practice. These are not things that a development team will do without direction.
Threat modeling
Security behavior
Consider the security impact of each design decision, and think like the attacker.
Desired outcome
Choose the design decision that protects the confidentiality and integrity of your customer’s data.
Metrics to measure efficacy
How many issues are you detecting and fixing prior to committing the code, and is the security light bulb turning on when the developer sees the impact of finding the weaknesses in the design.
Threat modeling is about examining a design (or even code, if code is your design) to understand where security weaknesses exist. Threat modeling pinpoints how an attacker will attack your design, and highlights the places most likely to come under attack. With a threat model, you attack your product on paper, and fix those problems early in your development process.Many DevOps practitioners approach the design phase with agile-colored glasses. They design in terms of user stories or features, and focus on getting the feature to build and operate. Code takes the place of traditional design time activities. This is a challenge because security can be left behind when your primary focus is to get code running.
After the developer has applied threat modeling behavior and considered security for each design decision, they can embed security directly into their decisions, and move toward a more secure option every time.
How to make it a habit
Show developers how to create a threat model, and quickly move to threat modeling an active design on which they are working. Move quickly from the theoretical to the real-world feature.
Security code review
Security behavior
Detect security flaws in another person’s code.
Desired outcome
Find the errors in the code that could be exploited if they reach production.
Metrics to measure efficacy
How many security issues are you able to detect and fix prior to a build, promoting from test to production, or in a specific period of time.
A code review is a critique of another developer’s code by searching for problems. A security code review is a bit more refined. It's deeper than just looking for logic flaws. The practitioner must understand the common types of flaws (OWASP Top 10 for Web Apps or Buffer Overflows for C), how to detect them, and how to fix them. Many teams are already doing code reviews, but the developers are not knowledgeable about security, and they're unable to find security flaws.
Strong DevOps teams use their infrastructure to force code review with each check-in to the main line. I’ve heard of teams that use the built-in functionality with GitHub that only promote a change if another engineer on the team has given a "+1," indicating that they reviewed and approved the change.
Static analysis tools offer a way to scan code changes, and perform automated code review. These tools should not replace the human connection during your code review. Static analysis alone can't find all the problems in your code. Knowledgeable humans can detect logic problems that tools aren't smart enough to find. But do use static analysis tools to enable a more effective code review.
How to make it a habit
Force a security code review as a requirement of the code commit process. Require a security +1 for each check-in. Teach your developers the fundamental security lessons of their languages, and how to find those issues in code. Finally, make static analysis tools available as part of your security tool package.
Red teaming
Security behavior
Attack your code with the same ferocity the bad people will apply to it when it reaches production.
Desired outcome
Uncover flaws using active testing, fix those flaws, and push the fixes to production as fast as possible.
Metrics to measure efficacy
How many legitimate issues are found and fixed because of red teaming efforts within a set amount of time?
The idea of red teaming began within the military, as a way for a group of people to imagine alternative situations and then plan how to respond. Within the context of security and DevOps, a red team refers to the idea of having people who take on the persona of an attacker and attempt to compromise the code.
Enacting such behavior means everyone on the team is always watching for some part of the product to compromise. Some teams approach red teaming by having people spend a portion of their time doing security testing, while others can justify having a dedicated red team resource that's always be attacking the code.
The key to red team security behavior success is that nothing is ever off limits. When the code reaches production, attackers shouldn't consider anything to be out of bounds. People enacting the red teaming behavior must be given the freedom to try any type of attack, regardless of the potential outcome. As a word of caution, you can always point the red team resources to a staging version of the pipeline to protect your production instances. The point is to never say “that could not happen” or “nobody would ever attack that way”. If your team can think it up, then so can others.
As with the use of static tools in the code review, red teaming can incorporate dynamic analysis tools that scan for web application vulnerabilities as well as network and other infrastructure patches that are missing. These tools do not replace the knowledge of the human, but can find some of the easiest issues quickly.
How to make it a habit
Instill the idea that your code will be attacked, and provide the time and tools for everyone to spend some amount of time attacking the code.
Why security behavior matters
The traditional path to embracing security has historically focused on process. You list a series of steps and expect everyone to follow those steps to ensure a secure solution. The challenge with that process is that it breeds compliance, which means that someone improves security because they are forced to do so, not because they want the system to be more secure. Compliance provides some benefits, but it will never be as good as having developers change the way they think and embrace a security mindset. With compliance, people put forth the minimum amount of effort to check the box, and that results in minimal security gains.
To keep up with the pace of DevOps and mix in security, you need to approach things differently. You should leave behind the security process, and instead embrace the idea of security behaviors. If you can change security behavior, then any time your people reach a decision point, their programmed response for better security will kick in.
The idea for a set of lightweight and scalable security behaviors hit me while performing an application security assessment for a startup. The company had a mature DevOps process, and I soon realized that traditional application security practices were not going to work in its environment. A security behavior focuses on the lightest touch points, while still having an impact on security, and is the foundation of a true security culture change for a DevOps environment.
How to set the tone for security behavior
A good way to embed these behaviors within your team is to educate team members about the behavior, and then quickly move to its practical application. Encourage the activities and reward the team for completing them. The idea is to reinforce the positive behavior with the goal of evolving the security behavior into a habit.
True security culture change is reached when the behaviors begin to transform into habits. A security habit is just a security behavior that has been practiced over and over, and has become ingrained in the way the developer thinks.
I encourage you to embed these security behaviors within your DevOps process. Next time I'll conclude this series with an overview of security tools you can use to automate security in the DevOps build pipeline.Image credit: Flickr
Read more from:
Research