People: The Critical Element in DevSecOps
In his talk, “DevOps is Automation, DevSecOps is People,” at the 2018 Security Congress in New Orleans, Mike Shema, CISO at Colbalt.io, said there needs to be a more collaborative approach when it comes to securing DevOps.
The Classic DevOps Approach
The increasingly popular buzzword “DevOps” means development and operations, and it comes from the reality that more of the responsibility of operations is being put onto developers. While different people may be tasked with different areas, the DevOps approach is that the developers are maintaining the code that they are building.
According to Shema, DevOps is the principle of how people have been embracing agile and adapting to cloud environments, because the people who are building the systems also are the ones maintaining the systems. When deploying to AWS, there is a lot of code, text files and configurations that all are being managed in a very developer-oriented manner.
Benefits of Automation
Beyond being able to scale, automation allows developers to be really confident that they can make changes quickly and that a mistake in those changes won’t be catastrophic. Yet on the operations side, the team has to consider, What is my system supposed to look like? How do the pieces interact? and How can I ultimately understand where the security controls should be? Who should have access? Who shouldn’t have access?
Automation and other tools are all really important, but DevOps needs to think about how to work with security teams so that security is something that emerges from those DevOps automation techniques.
Where Security Comes In
Historically, DevOps teams have tacked on security at the end of the software development process—asking security at the last minute to perform a security review, usually the day before the software is scheduled for release.
“DevSecOps is putting more of the responsibility onto the DevOps team, which I think is important,” Shema said. “There have been a lot of funny conversations about where to put the ‘sec’ when writing it. Does it go on the end? At the beginning? I put it right in the middle because security really is a part of the whole process.”
Keys to Collaboration
While it’s important not to wait until the end to tack on security, it’s also important that security does not hinder development. “That’s not collaborative. We need to shift left and introduce security early on in the development,” Shema said.
It’s equally important to introduce security into the process early on, so the DevOps team can build in security controls and a good security architecture from the beginning. “You don’t wait until the end to bring in security. On the security team side, you don’t become the gatekeeper who says, ‘Thou shalt not release because the security team hasn’t looked at it.’”
Shifting Left
If a person with a security title isn’t part of the DevOps team, security may not be able to scale. Companies then may have a security person—an ambassador of sorts—who consults different DevOps teams, providing feedback on best practices and tools. It’s people working together.
“There’s security in development, where you are architecting it. There’s security in the CI/CD process about how you are trying to deploy to AWS. Then there’s that security element within AWS for enforcing least privilege. All of these things have security elements to them, so it’s not just one security angle,” Shema said.
Yes, security means looking at how you are handling SQL injection and whether your application is friendly to content security policy headers, but those are highly technical conversations.
While those conversations are important, security also means thinking about the ways that the application interacts with people, which is where the larger conversations about privacy, trust and safety should be considered.
