Two weeks ago, I was able to participate in an online panel focusing on DevOps and Security which was put on by Continuous Discussions (#c9d9). Continuous Discussions is a weekly online panel discussion which is sponsored by Electric Cloud and discusses a variety of topics around Agile, Continuous Delivery and DevOps with a range of different speakers.
The panel discussed the role that DevOps plays with respect to Security. This topic was broken into several different sections: Securing your Code, Securing your Environments, and Securing your Process.
You can watch a recording of the panel discussion here:
Securing Your Code
There were a lot of excellent ideas thrown around in this portion but the most important takeaway that I had was that securing your code starts with really looking for the low hanging fruit in your process. A lot of those vulnerabilities can be fixed with relatively little effort and many times by just having a proper release engineering process in place. Here are some simple questions you can ask to see if you can have some quick wins in your own environment:
Do you know what libraries you are using in your products or are developers pulling in whatever they want from the web? e.g. A client was using over 50 different versions of the same library in their products, most contained well known vulnerabilitiesAre these libraries kept in a central repository? e.g. Nexus Repository, ProGetAre you using 5/10/20 different versions of a library, if so do you really need to?Have you checked to see if they have security vulnerabilities? e.g. OWASPDo your developers and operations people work together to make sure that the software you are building is deployable and able to be secured?
Securing Your Environments
There was almost universal agreement that culture is probably the most important aspect of securing your environment. Growing a culture that encourages people to bring forward those security vulnerabilities instead of trying to hide them is paramount. If management makes it one of their priorities and encourage people to bring it forward, it definitely helps.
The need for configuration management was brought up, either directly and indirectly, by all the participants. We had all seen tons of hard-coded configurations of connection strings, passwords or things where you have a configuration file that was just checked in to source control. There was also a lot of discussion around ways to make sure that infrastructure is also viewed as code and how to surface things quickly if someone had to touch a production machine.
Here are some links to some of the interesting tools mentioned:
Securing Your Process
The last portion was a discussion that built upon the previous sections and was that of how to best secure your process. One important point made was that in the end people just want to get their work done. To enable a secure process you have to keep that process very lightweight so people don’t want to circumvent it, if your change control process takes 15 minutes it’s not a big ideal but if it takes 4 hours and 19 signatures and 3 days to get that change out because of it, people are going to look for ways around it, whereas if it’s 15 minutes, there is no reason to try and circumvent something that so simple and built in.
What impressed me most about this experience was that all the panelists naturally tended towards solutions that were not a specific tool or technique but more of a cultural mind shift in order to get increased security. I was also impressed by how natural and free flowing the conversation was between the panelists who had only briefly met each other before. I think that this is a real credit to the community that Continuous Discussions is building and I want to thank them for inviting me to join them.