From DevOps to DevSecOps
What’s the worst organizational problem in companies? Chances are that you answer silos. DevOps is one of the better solutions to this problem. But what about security? Tackle this with DevSecOps...
Start from DevOps…
What’s the worst organizational problem in companies? Chances are that you answer silos. People in different units are working on similar problems and could benefit a lot from cooperation. But they all have equally pressing schedules and no incentive to cooperate. A familiar problem for many of us.
DevOps is one of the better solutions to this problem. That’s forming units carrying a bigger end-to-end responsibility for the product and service. It stands for DEVelopment and OPerations. Like when the team developing a cloud service also takes care of operating the servers. Needless to say, that makes deployment of new builds a lot smoother.
But what about security? We still have that company security guy who rushes in and wants to mess up the architecture and schedule, at a far too late stage in the process. He’s an alien, he comes from behind the silo border. Yes, security is important. But sorry, we have a schedule to keep! I work as a SW testing & cyber security specialist at Etteplan. I have tackled this problem with DevSecOps. It’s about painless integration of security into the development process.
…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.
Running an initial threat modeling workshop is a good start, followed by repetitive recurring workshops to update the model as the project evolves. Drop in reminders about secure programming practice and the seed is sown. Most developers already understand the importance of security, but they may lack skills and be too busy to learn it properly. Make sure that knowledge and good examples are easily available, and the learning process will happen automatically.
It’s obvious that DevSecOps is so much more than just a bunch of coding practices. We need an environment where security isn’t an external disturbance that conflicts with other goals. That’s the fundament foundation DevSecOps stands on.
About the author
Harri Susi is a cyber security expert at Etteplan with a extensive history in security related assignments. Harri is interested in everything related to security and can be reached at firstname.lastname@example.org.