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.
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?
First, you need to understand what you can automate. Here are some processes that can be automated:
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.
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:
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!
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:
Tom concludes by giving some tips to overcome these challenges: