Movin’ right along
Several years after the introduction of DevOps, the security community continues to laud the method while scant few developers are hopping on the bandwagon. One of the issues is that “security” isn’t part of DevOps.
DevOps, as the name suggests, is a marriage between development teams and operations, focusing on interdepartmental communication so that development teams can meet the needs of the business without disrupting enterprise operations. Simple and clear enough, but security isn’t part of that equation, even though the security community is one of the biggest proponents of DevOps. (DevSecOps, on the other hand, involves the security team, but DevSecOps is even less popular than DevOps.)
During Cloud Security World 2016, Adrian Sanabria, Senior Security Analyst with 451 Research, presented a talk on “Cloud, DevOps, and the New Security Practitioner.” Sanabria’s take was refreshing; he didn’t try to sell the idea of DevOps so much as he explained why our current model of shouting “Go, DevOps” from the rooftops isn’t working. Security is always “a secondary or enabling layer,” and as such, security practitioners remain on the outside of many processes, in this case, development. Inserting oneself into the development process and repeating, “Your code must be more secure. Secure code is the root of many breaches,” isn’t going to make developers code more securely, nor will it earn the respect of the development team. However, direct experience in core technical disciplines, said Sanabria, will.
Opportunity knocks once, let’s reach out and grab it
“Cloud-first” as a business mindset presents an opportunity for security to evolve its skill set. Cloud technology is changing rapidly and affecting the way security practitioners work; lower levels of IT are now outsourced, infrastructure-heavy security skills are losing value, and the concept of bi-modal IT further complicates things, said Sanabria. Physical, OS layer, and network layer security all get baked into the cloud, which means that security practitioners who want to focus their work on those levels will need to work for the provider.
Enterprise security practitioners, however, can embrace an opportunity to redesign security’s role. Sanabria explained that, in addition to service desk responsibilities, security must start to share responsibilities with development, operations, and infrastructure in a way that doesn’t impact service delivery schedules. He said that the new internal security practitioner will be redistributed into IT for operational tasks.
Moving in this direction, said Sanabria, security must be aware of the change taking place around us and adapt. While he said, “traditional security doesn’t have to worry for a while,” the time is now to revamp and recharge: “As it turns out, it is easier to take someone with a development background and skills and teach them security than it is to take security folks and teach them development and low tolerance for inefficiency.”
Together we‘ll nab it
Managing endpoint security and mornitoring security alerts are quickly becoming tasks that can be more easily and accurately automated. Security staff won‘t need to be so hands-on with these in the future, but they will need to know how to influence infrastructre design and architecture standards; learning basic JSON, REST, XML, and SQL means that security practitioners will be able to identify gaps and recommend fixes, he said. Gain skills, then influence and respect, and you will affect security outcomes.
The “new tech generation experience and skills,“ said Sanabria, will require scripting, general purpose programming languages, and the ability to teach those to developers. The majority of current security job postings that Sanabria found listed the above as requirements now.
He concluded his talk by advising, “If you want to understand where security is going, stop looking at security, and start following IT innovation, trends and changes.”
