DevSecOps for Managers, Executives, and Mere Mortals

Tom Steihm is Chief Technology Officer of Coveros. He's been developing applications and managing software development teams for more than 20 years. Today, he explains the basics of DevSecOps.

Tom has been working to secure applications for a long time. And he's trying to help people who are starting with DevSecOps. He uses what he's learned from his experience and mistakes and hopes others don't make the same mistakes.

DevOps is a practice where the focus is on collaboration and feedback to build better software. And DevSecOps uses the same principle to build more secure software, Tom explains.

DevSecOps is a culture shift. It aims to make people focus on and take responsibility for security.

Most organizations have a cybersecurity group, and they take care of the AppSec (application security) practices. But the ratio of cybersecurity professionals to developers is roughly between 1 to 200 and 1 to 500. This obviously isn't enough and isn't scalable! You want these cybersecurity professionals to train others on how to include security in the jobs that they're doing.

How Can DevSecOps Help Your Organization?

DevSecOps shifts application security practices to the left in the software development life cycle. You use feedback to take security measures earlier and make security an everyday thing.

Implementing security at the end of the release doesn't make the application more secure. Instead, it increases the chances of inducing and missing out on more vulnerabilities in production. And DevSecOps prevents this. In short, DevSecOps helps improve security. So, how do you put this into practice?

Implementing DevSecOps

First, you need to understand what you can automate. Here are some processes that can be automated:  You can automate a lot of things. But some things still need an actual human! Here they are:

• Analysis of Security Testing Automation: Here, you're identifying false positive issues and real issues and remediating them.
• Penetration Testing: This means looking at how you can attack a system. Tools may help, but it's the person who's looking at it who matters.
• Threat Modeling: This refers to assessing who might attack you, why, and how they might attack. Then you figure out a plan to mitigate those threats.
• Architecture Analysis: You need to look at the way data and control flow through the system and then decide whether the system is exploitable.

Time-Consuming Parts of DevSecOps

We've seen different processes or steps to implement DevSecOps. Although a lot can be automated, there are a few things that are time-consuming.

The first of these is identifying and filtering false positives. Second, penetration testing itself is time consuming because people are involved, and they need to experiment with the system. Third, threat modeling is a challenge because of all the discussion.

In addition to these, discovering zero-day vulnerabilities takes time because finding hidden vulnerabilities is human intensive. And finally, forensics—figuring out what happened, when, and why it happened—requires serious attention and effort.

What Should You Do First?

According to Tom, the most important thing is getting started. In the beginning, what you start with matters less than starting.

The way it works is, you pick up something and practice it until you get value on it. The best way to get this value is to find issues and work to remediate them. When you get the value, show it to stakeholders. Then move to the next practice.

If Tom had to start somewhere, he would begin with the following:

• Install Software Composition Analysis: He'd look at dependencies and make sure they don't have vulnerabilities.
• Interactive Application Security Testing: The goal here is to reduce the number of false positives.
• Static Application Security Testing/Dynamic Application Security Testing: Plug these in your pipeline. They'll generate results, and you can start acting on those immediately. SAST/DAST will look for vulnerabilities in your system, and you'll start getting value right away.

Don't Forget Operational Security

Tom was a software developer and has built a lot of systems. His tendency with DevSecOps is that he forgets about operational security. So, he encourages others not to forget about that.

One of the first things to look at for legacy applications is RASP (Runtime Application Self-Protection). RASP gives a layer of protection while you're working on fixing vulnerabilities using other methods.

Next, don't forget to set up and monitor your security information and event management. Your infrastructure analysis scanning and testing is probably in place already. You just need to see how you can use it for security. And last but not least, don't forget to encrypt data!

Challenges Adapting to DevSecOps

DevSecOps is bringing together teams that operate differently. Therefore, DevSecOps can be difficult because the teams and the stakeholders need to look at things differently. Here are some of the challenges you may encounter:

• Communication across Dev, Sec and Ops teams
• Lack of time for application security analysis and remediation
• Pressure to skip parts or ignore findings
• Refusal to use application security practices
• Showing value to stakeholders

Tom concludes by giving some tips to overcome these challenges:

• Different teams use different types of jargon. Bridge the gap between them.
• Learn to negotiate for the time you need for application security analysis and remediation.
• Make stakeholders aware of the consequences of defective products and the importance of high-quality products in production.
• Show the damage that other organizations have faced for not fixing security issues.