Last week, nearly 43,000 of my closest security friends and I gathered at the RSA Conference at San Francisco’s Moscone Center. Per usual, the event didn’t disappoint.
As a member of the DevSecOps speaking panel, here are a few of my key RSA takeaways from that discussion for organizations implementing DevOps.
1. Security has to break past the fear to enable DevOps
One reason there is so much friction as organizations try and adopt better security at the same time they are adopting DevOps is because DevOps creates fear. So much of what we do in security is still driven by compliance, and DevOps looks like another unsanctioned, uncontrolled thing that security cannot regulate.
Way back when I was a Unix system administrator, my boss came to me and asked a series of questions, which made me realize that as a group, we had lost our way and forgotten our mission. It was my job in security, just like it is any pro in security, to protect and ultimately enable the business. It’s the same way we need to view security and DevOps today. Despite the rapid growth of DevOps practices throughout various industries, there still seems to be a fair amount of trepidation, particularly among security practitioners and auditors. One of the first concerns that pops up is a blurted out, “You can’t do DevOps here! It violates separation of duties!” This is a misconception that Ben Tomhave has taken head on.
2. There’s no “best size” for a DevOps transformation
Many have noted that larger enterprises seem to be adopting DevOps faster than mid-size and even smaller firms.
On one hand, that makes a lot of sense. Large companies typically have the capital and the resources to make a transformation. But at the same time, no matter how many resources, you can’t just flip a switch and expect it all to happen in an instant. I see business managers are getting smarter in that they know you can’t move a mountain in a day. Many are starting off small, finding success and branching out.
Mid-size and smaller firms often have the benefit of a green field project that can be built the right way from the ground up. We’ll continue to see organizations of all sizes embracing DevOps.
3. Make automated security testing a priority from day one
Unfortunately, I think that for a lot of companies automated security testing is just not a priority. But let’s take a step back to the requirements for any given feature. We have to ask if the people writing those are including security? Because right now, security testing just isn’t getting done, as it’s not a requirement, which means it’s not a priority. If we made security a requirement from day one for both application and infrastructure engineers, then more testing would get done. People who write code or do QA testing are smart. They don’t want to be doing the same thing over and over again. If security is baked in from the beginning, pretty soon they’ll naturally start automating themselves.