DevOps + InfoSec Need to Come Together in DevSecOps

You don’t need to spend too many cycles pondering what might happen to a boxer crazy enough to enter the ring with one glove tied behind his back.

Security practitioners ought to keep that image in mind as they go about the business of organizing their defenses. Unfortunately, all too many organizations nowadays are letting corporate politics and status quo interfere unnecessarily with their security strategy. All the while, hackers are evolving and stepping up their efforts to deliver knockout blows. Consider the following:

• 1 in 13 web requests now lead to malware
• An 8500% increase in coin miner detections is creating new vectors for cloud breaches  
• Just 37% of security managers say they can adequately analyze threat data
• 24% of successful cloud exploits happen at the app layer

History Repeats Itself

The unfortunate reality is that competing interests and legacy policies in between InfoSec and dev teams have gotten in the way of effective collaboration. As companies digitize and adjust to the demands of doing business in the cloud computing era, the relationship between these two important groups is often marred by dysfunction.

Let’s shift gears for a bit and talk about how software delivery has changed over the last two decades. Then let’s examine similarities with security models today.

Do you remember waterfall? Unfortunately, I sure do, and you’d be surprised to know that some companies still use this methodology today (even if they call it something else). First introduced back in 1970, the waterfall methodology introduced a series of sequential processes to get code out the door. Essentially, there were six stages that defined requirements and typically involved separate teams for each stage. Once a team completed its stage, it would trickle down to the next team and so on.

Although the model was one of the first documented processes on how to really gather customer requirements and get those requirements into code, waterfall has three big drawbacks: lack of speed, lack of flexibility for changing requirements, and less collaboration between teams.

These disadvantages paved the way for the agile methodology. The agile methodology is great in three aspects. First, agile recognizes that the dev teams won’t have all the requirements up front or those requirements will change over time. Because of this, the second advantage is dev teams typically don’t focus on delivering an all-encompassing solution but rather chop up requirements into smaller parts for faster delivery. Third, because things change fast, both dev teams and biz heads must work closely (like face-to-face conversations daily) throughout the project to truly discover what the market and customers want.

So now how does DevOps play into this evolution? Agile is about getting customer feedback fast into code and making complex projects doable. DevOps is about getting that code out the door faster. DevOps teams are charged with getting every developer’s code (Continuous Integration - CI) out the door on a frequent basis (Continuous Delivery - CD) and own the CI/CD pipeline. I think of DevOps as train masters making sure everyone’s release is on the train, and that train rolls out the station on time. In this way, DevOps facilitate agile development and as a result customers get better code, faster.

Waterfall Security

Now let’s think about how the evolution of waterfall, agile, and DevOps has in common with security today. A traditional InfoSec team is most likely a security gatekeeper. This team reviews code only after it’s fully baked, grades code against some predefined, static list, and has authority to stop all progress if the tests fail (even if some parts are secure). This team is almost the definition of a waterfall stage that doesn’t get visibility into the code until it’s time to go out the door nor has flexibility to adjust to new requirements.

Why does this model fail in the new cloud era? The same reasons why waterfall fails today. The model can’t adjust to changing requirements (new security use case) nor has an environment where they can truly understand what the dev team is trying to do.

The cadence of business had accelerated to the point where companies now needed a faster way to react to constantly changing customer requirements, including new security requirements. As more business goes to the cloud, new dev teams get created that will move fast. Traditional InfoSec models won’t scale with this approach, so you end up with three results: insecure code goes out that door, your releases (business) slow down, or a worse yet a combination of both – insecure, slow code.

All the more reason behind the logic of embracing a DevSecOps approach.

Culture Change

People define DevSecOps (and other permutations of the words “development”, “security”, and “operations”) differently, but there are four main differences that change the game. In a nut shell, DevSecOps is a culture change on how you can release more secure code, faster. As you think about how to build a DevSecOps culture, keep these ideas in mind as starting points:

• Everyone is responsible for security. No longer do you have one team solely responsible for code security. Instead, you assign across-the-board responsibility for security. The dev team isn’t just on the hook for writing code; the dev team is also responsible for assessing risks and fixing issues. DevSecOps team can parachute in and provide guidance, but the dev team should ultimately be responsible for fixing their own code. Who knows code better than its creator?
   
• Shift left. The faster you identify a security problem, the better off you are. Just like in an agile world, getting customer feedback faster into code means you waste less resources down the line and produce a better product. Addressing security issues early in the dev or even the planning process, means your code will be more secure and you’ll waste less resources chasing down problems.
   
• Be flexible. Security requirements will and should change. Security is all about risk. I don’t have bulletproof glass for my car even though a sniper could technically shoot me through my window. Why? Because it’s not a likely risk for me (hopefully). However, I just recently added flat tire repair to my insurance because my commute changed due to construction (lots of nails). Good DevSecOps teams think about likely and new scenarios in which new code may get compromised. You might not ship code that is 100% bulletproof but do you need to? Better to ship code that is well protected against the likely and possibly newer risks.
   
• Frequent, face-to-face collaboration. In the end, DevSecOps serves the business. The team should be enablers, not preventers. The priority should be “how do I get more secure code out faster” and not “how do I stop bad code from going out.” It’s a subtle, but powerful difference. This requires clear feedback to the dev team, context about risk, and daily touch points (ideally during scrum) early in the process to help the dev team get better code out to customer.  

In the end, the day-to-day demands of a digital business will trump any lingering security paranoia blocking the implementation of DevSecOps. Aside from that, I honestly believe code is more secure using DevSecOps. Why box with just your right hand (InfoSec team), when you can untie your other hand (dev team) and go at your opponent full bore. When it comes to security, there’s no reason why you shouldn’t democratize every resource you have, and that’s what DevSecOps does.