Updated on March 7, 2016 by UpGuard
I've been thinking a lot lately about the intersection of DevOps and Information Security. I'm definitely not the first to have considered the implications, but I am undoubtedly a complete cynic when it comes to InfoSec and how it can align itself to the DevOps movement. Why am I cynic you may ask? Well, I spent almost 10 years in the security/governance arena interacting with CISOs and their teams trying to help them 'reduce risk' and 'pass audits', but I've watched countless organizations fail miserably. What is the main reason why? Because the business fails to see the value of security and doesn't understand it. Better said - the business invests in what the business understands.
Business people completely understand 'release my product faster', 'time to market' and 'make more money' which is some of the outcomes that DevOps pontificates on. This is why DevOps as a movement has a higher probability of succeeding than other investment choices because there is a direct correlation between it and top/bottom line revenue. So if you're an InfoSec leader, a good bet is to align yourself to the DevOps initiative (or spearhead it yourself for that matter) and help the business understand the value of security in a way that doesn't measure things by # of incidents, time lapse from vulnerability to patch, or compliance score.
One of the major benefits of DevOps principles is that everyone's functional input (including InfoSec) is brought in earlier and then automated to ensure short, predictable release times and quality. But security professionals are stereotypically the wet blanket of IT. I do believe that this stereotype is beginning to wane out of necessity, but it still doesn't change the fact that InfoSec is usually the last one consulted and they tend to slow things down which is counterproductive to the DevOps movement as a whole. Therefore, I think there are a few things that need to evolve in order to bring together these two silos:
1. Let's stop thinking that "DevOps" only means Ops and Dev/R&D. Just because it starts there doesn't mean it has to or should end there.
2. Security must be involved earlier in development to harden systems as much as feasible.
3. Security must balance the audit/security needs with business goals to help standardize secure configuration settings that allows for faster deployments.
4. Organizations need to determine how they deal with separation of duty requirements while having assurance through the SDLC.
5. Security, Development, Ops and Testing all need to embrace using similar tool sets to improve visibility and collaboration.
Getting DevOps leaders to have a dialog around security is a good thing. DevOps provides a huge opportunity for security to be aligned with the business, transform the way security controls are implemented and ensure they become business enablers. I also believe that regular exposure to security will make it a by-product of everyday work processes for those in Dev/R&D. The security team will always need to have a strong presence in DevOps for monitoring and incident response, but over time should play a smaller part as everyone involved starts to embrace security.
Misconfigurations are an internal problem that emanate from within the IT infrastructure of any enterprise; no hacker is necessary for massive damage to occur to digital systems and stored data. And the problem is pervasive, with Gartner estimating anywhere from 70% to 99% of data breaches result not from external, concerted attacks, but from internal misconfiguration of the affected IT systems.