Those of us highly focused on the delivery pipeline of DevOps will wonder why we should include the security guy to the party. After all, aren’t they just going to slow down the process and make it harder to deliver good features to end customers?
My prior post about introducing SecDevOps by example was not about defining a new role, but introducing how security can and should be part of the automation delivery suite. Whether you are talking about traditional infrastructure change process or automated instantiation of new nodes to handle customer demand, the tools and processes of DevOps merged with security requirements are available to provide security accountability and assurance. Those of you coming from the traditional security space, which might fear security automation, should consider just how exciting SecDevOps delivers on agile assurance.
Rich Mogull provided an excellent example and code to show how firewall changes in a real life situation can be fully automated. There is no need to be squirrely about what is emerging. Everyone needs to be involved with development and operations to take more opportunities to minimize risk.
Dwaye Melancon also recently wrote about the issues of security and risk when the baton is handed off from one owner to another. This too is another great example of where process and monitoring automation aids in delivering continuous security assurance.
I believe everyone craves for a future when security events are automated with full transparency from beginning to end. If security had a real closed-loop transparent agile process, then just imagine how easy it could be to deliver on both compliance and real risk reduction. As Richard Stiennon recently stated in a CloudPassage webcast “Compliance standards are woefully behind with the reality of operations”. Haven’t we all had an experience with an auditor and a clipboard asking for specifics that are clearly aligned with another age of computing?
Wouldn’t it be better to give auditors the same tools, to get a picture of accountability and risk decisions made in the DevOps cloud environments? Take for example the recent HeartBleed events that many security teams are still struggling with. As a DevOps professional, I would have rather just showed the security team and the auditors the truth – that none of my team did anything at all to mitigate this risk. Truth be told, our orchestration tools had already installed the new version of OpenSSL and generated audit logs before many people had their first cup of coffee.
Security can be improved with more integrated automation and by deputizing everyone to do more with DevOps tools. A SecDevOps approach will improve the compliance and audit process with tactical security tools for all. Burn the clipboards and provide an enlightened way to prove best security practices from the collective group of Dev and Ops. Maybe give the Security guy a break and invite him to the after audit beer bash too.