Securing DevOps Is About People and Culture

Source: darkreading.com

Preconceived notions and divisions make building security into the software development life cycle an uphill battle for many organizations.

Security teams have long had the reputation of being “out of process” — that they add requirements, complicate processes, and disrupt DevOps.

“The reality is that building security into the development process — be it agile, DevOps, DevSecOps, or a mix thereof — remains a significant challenge for many reasons, beginning with the group relationship,” says Matt Keil, director of product marketing at Cequence Security. “In many organizations, the teams rarely interact, and the group reputation precedes the meeting. Security is ‘Dr. No’ and app dev is ‘rogue, ignoring security.'”

These preconceived notions and divisions make building security into the software development life cycle an uphill battle for many organizations. Perhaps it is possible that the solution to securing DevOps lies in reframing how we look at the problem.

Is Automation the Answer?
Trying to put different labels on security is antithetical to the goal of complementing an existing DevOps process. “When you integrate and use security as part of that automation associated with [the] DevOps pipeline and constant integration orchestration, it works much better,” says Matt Rose, global director application security strategy at Checkmarx. 

Many dev teams have been told to “shift left” or “shift right,” but a good DevOps process is an infinite loop that is constantly moving. In other words: continuous integration (CI), he says. “Automation at CI is the key aspect — the conductor of the symphony orchestra,” Rose says.

Automating at every stage of the process isn’t really difficult, according to Rose, who points to four disciplines of DevOps: development, CI, continuous delivery, and continuous deployment (CD) and production.

“You look at those building blocks, and there are different security technologies that slot themselves within each of those disciplines,” Rose says. “It’s about understanding where to integrate, but people make it much more difficult by putting different labels on security. When you look to architect a DevSecOps, you basically insert the right technologies at the right points in the DevOps process.”

Where Does ‘Sec’ Fit In?
Ever since development and operations came together to unify responsibility and accountability, different parts of the business have tried to create their own iteration of DevOps. And that is part of the problem, says Kelly Shortridge, VP of product strategy at Capsule8.

“I think we need to discuss a DevOps-centric approach to security rather than trying to figure out a security-centric approach to DevOps,” she says. “SecDevOps is a vendor-driven term that gives a false sense of comfort for security teams so that it seems they are actually doing something to fit into the DevOps world.”

Fundamentally, DevOps is a mindset, according to Shortridge. It’s a collaborative approach for optimizing the software delivery and performance life cycle. Security-centric DevOps tends to focus on the automation component, but Shortridge says the way security tries to integrate into DevOps isn’t working out too well.

“When security teams in various organizations automate some tasks, they boast that they are DevOps-friendly or DevOps-enabled, and I think that is misguided,” she says.

The biggest step an organization can take toward bringing security into the DevOps world is actually ensuring that their priorities align with the business priorities, Shortridge says. 

“Security has to shift to thinking about how it can improve software delivery performance and how it can start unifying that responsibility and accountability,” she explains. “It takes a lot more work than what I’ve seen commonly, which is supporting the old threat models and controls with new technologies and trying to steamroll the DevOps team by trying to shove all the security testing into the software development life cycle.”

Changing the DevOps Narrative
The very suggestion that security needs to be tacked onto or integrated into the DevOps process inherently suggests that DevOps does not think about security — which Mozilla security engineering manager Julien Vehent says is not the case.

While a culture of “go fast and break things” has been attributed to DevOps, it was a symptom of startup companies that didn’t have a lot of risk, he explains. Large organizations that want to stay competitive are focused on speed, but they usually don’t want to break things.

“These companies have adopted DevOps but have also made sure to integrate security in their [quality assurance] and testing processes to make sure that they can go fast without breaking things,” Vehent says.

Securing DevOps is about more than technology, though. It is also about people. Marrying security and DevOps requires a change in culture, a breaking down of barriers, and dispelling the myths of misguided beliefs that have led to finger-pointing in the past. So how do organizations change the culture? In the case of Malwarebytes, it started with changing the name.

“At Malwarebytes, we did not have good SecDevOps until I created a group within engineering that had the specific charter of ensuring the ‘ops’ and ‘sec’ part of SecDevOps was owned and done properly,” says Malwarebytes senior vice president of engineering Mark Patton. “We named the team ‘Site Reliability Engineering,’ and they were the bellwether team that changed the culture of engineering from within.”

The Malwarebytes SRE team then worked backward, guided by the mantra of “100% uptime, 0% breaches, optimize cost.” That mantra allowed the team to slowly push good practice into the engineering team.

“They reshaped the way our environments were created and deployed, reworked our deployments to use the most economical AWS services, showed our developers how to architect cloud systems to optimize security and cost, and then added security monitoring that immediately flags issues to the proper people,” Patton says.

The process was not without its challenges, which included both finding talent and convincing the teams. In the end, Patton says, the new processes and feedback converted even their most reluctant engineers to get onboard.

Leave Your Ego at the Door
Both security and DevOps teams must unite in the common goal of deploying apps and features securely and quickly, experts say.

“Security teams need to be willing to loosen the security change control reins, allowing automation to play a larger role in their process,” Cequence Security’s Keil says. “Security teams also need to look outside of their existing toolset to ensure they have the right mix for their current and future application architectures.”

The shift to DevOps and security working more closely together “promotes teams to move from viewing security inclusion as a blocker to instead viewing security as an enabler to getting their code into production,” adds Jonathan Deveaux, head of enterprise data protection at comforte AG. “SecDevOps is an excellent way for developers to play a vital role in the overall security program for enterprises and businesses wanting to ensure data security is a critical part of their organization, especially in the development phase.”

Related Content:

• A Security-Related Approach to DevOps
• Planning a Bug Bounty Program? Follow Shopify’s Example
• The Truth About Your Software Supply Chain
• 6 Ways Mature DevOps Teams Are Killing It in Security