In my last two posts, I discussed first the core "Rugged DevOps" idea - integrating security into the DevOps cycle and agile sprint teams. In my second post, we went down the path of implementation. To core idea is that we need to secure three separate parts of DevOps: the infrastructure, the "sprint" updates, and the actual DevOps process itself. To do that, we need to first separate the application platform into infrastructure, architected and managed by operations, and application, designed by the agile sprint teams. Security would then design the right baselines or policies for each part, ensuring that the entire stack is secure, while not slowing down the agile development process.
Now we get to the linchpin: None of the proceeding discussion accomplishes much if the DevOps cycle itself is not repeatably secure.
I'll use an example to illustrate. In a previous life as a consultant, I was building automation for a large data center project. The auditors told us that they wanted to audit every single machine every time a change was made. We told them that this was untenable, since we were making changes all the time. We were at a impasse. Then we came up with a smart solution. We let them "audit" the provisioning process. This meant that we had to prove that the provisioning process was repeatably secure, and establish controls around how provisioning standards and packages were updated.
So, the auditors audited the end result of different provisioning jobs, and only audited changes one time on test systems - not everywhere. Back to our current discussion, the implication is that, in implementing Rugged DevOps methodology, the security team needs to be part of the architectural team for building the DevOps process, and then sign off on the repeatability and "ruggedness" of that process. If the modular components being provisioned are secure, the compliance baselines / standards are being deployed and applied with updates, and the process is repeatedly secure, you have the technical foundation for Rugged DevOps.
As I said before, this should be exciting to people in the security profession. No longer are you stuck in a dark room running network scans and running antiquated security tools. You are an integral part of the development process, and you will help make solutions secure while still deploying at DevOps speeds.
And as a DevOps believer, integrating security deep into your DevOps cycle means that you avoid embarrassing slow downs when security gets involved late in the process, and you have the confidence that you won't be woken at 3 A.M. trying to explain why a hacker penetrated your site after the latest update.