From DevOps to DevSecOps

…Then add security

Yes, just like DevOps can make deployment smoother, DevSecOps can help ensuring security. The basic idea is simple, you make sure that “the security guy” is no alien anymore. He’s part of the team and share the same goals and incentives. It could be a security expert, or a skilled security-aware developer. Or even better, the whole team. This is achievable by helping them implement secure development practices, usually with additional training or externally facilitated workshops. The goal is naturally to ensure that security aspects are considered at the right stage of the development cycle. Needless to say, at a fraction of the cost it would require to make changes later. 

An example of DevSecOps work is a series of threat modelling workshops. In these the whole team draws a picture of the system architecture, paying special attention to trust boundaries. For example, a user retrieving data from a central database. The goal is to answer the question: What could go wrong? 

“STRIDE” forward and use other tools as well

 “STRIDE is a very important method. It helps you think like a hacker and identify what can be done to break the system.” Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Escalation of privileges. Take one at a time and think about how to apply that kind of attack. Like this: What info is showed to the end user when there is a database error? You need detailed info when debugging, but SQL table names are useful for hackers too. Looks like we identified an information disclosure issue! 

But if I am not a cyber security specialist…

But what about skills? The team does not have this competence. Yes, that’s common. And that’s why the workshops usually are led by an external professional facilitator. It ensures that the work is done correctly, but also serves as training for the teams. Facilitators are trained to ask the right questions and lead the team to discover issues themselves. That’s the optimal way to ensure motivation. No more “not invented here”. Professional facilitators also know that you must follow through after the workshop. Make sure it results in concrete tasks and backlog items and follow up on their progress. 

And how about your coding practices?

Identifying and mitigating possible hacks is of course important, but another dimension of DevSecOps is to avoid vulnerabilities with coding practices. Skilled experts have a very large toolbox available. However, usually it’s easier to define all valid than all invalid values for a certain input. So you can eliminate nasty bugs by checking for valid input and treating everything else as invalid, rather than the other way around.  

Use vulnerability scanner!

There are also tools that can be used early in the development. A good example is vulnerability scanning. (link: https://www.etteplan.com/security-youre-blindfolded-unless-you-scan-vulnerabilities) Scanning early supports the important concept of failing early. The sooner you discover failures, the sooner you fix them. And that means less maintenance debt and lower schedule risk. 

Code and practice the new skills

Practically everything you do in a software project can have security implications, from the initial planning steps to the final tests. Lack of security awareness will no doubt lead to wrong choices at all levels. Developing without integrated security awareness will give you two bad options; wasting resources on redoing stuff or shipping a bad product.  

The beef here is of course that the leanest way to fix bugs is to avoid making them in the first place. That’s a no-brainer, but still we keep developing insecure systems. Why? One important reason lies in our management structures. We work under pressure to deliver a predefined scope on schedule, with limited resources. The true cost of security problems is hard to forecast and quantify, while our scope and schedule goals are very concrete. That makes it an uphill battle for the alien security guy who tries to sort things out. 

Fighting that is an important part of DevSecOps. The core is of course secure development practices, but it is easy to focus too much on the technical aspects. They must be supported by the right skills, organization and incentives to be successful. It’s not enough to think about what the developers should know and do. You also need to think about what motivates them and what sets their priorities.