DevSecOps: Security in the Process

Can security come with speed? More to the point, can security come via the agile methodology, or via agile's logical successor, DevOps? Those are questions that were addressed at last week's Agile 2017 conference in Orlando, Fla., and the subjects of several conversations that SecurityNow.com held during the conference.

Agile development is defined by the Agile Manifesto, while reads:

"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more."

There's no generally accepted similar manifesto for DevOps, but there are functional definitions, among them "breaking down the walls between development and operations," and "treating both hardware and software as code."

That last piece is important when it comes to figuring out what is meant by the recent IT portmanteau, "DevSecOps." What is this? According to the site DevSecOps.org, the definition begins by treating security as code. That means, among other things, that, "We will operate like developers to make security and compliance available to be consumed as services." And with DevSecOps, there is a manifesto that echoes that from agile development:

"Leaning in over Always Saying “No”
Data & Security Science over Fear, Uncertainty and Doubt
Open Contribution & Collaboration over Security-Only Requirements
Consumable Security Services with APIs over Mandated Security Controls & Paperwork
Business Driven Security Scores over Rubber Stamp Security
Red & Blue Team Exploit Testing over Relying on Scans & Theoretical Vulnerabilities
24x7 Proactive Security Monitoring over Reacting after being Informed of an Incident
Shared Threat Intelligence over Keeping Info to Ourselves
Compliance Operations over Clipboards & Checklists"

In trying to figure out what all of this means when translated to action, I spoke with Anders Wallgren, CTO of Electric Cloud, a company that provides tools for DevOps. He said that the end point for DevSecOps is a state in which as many steps in the overall process as possible are automated.

"An engineer checks in a piece of code; he checks in the tests. That gets automatically picked up by the continuous integration system, the continuous testing system, and automatically goes through all of the various stages in the software pipeline including security verification, static analysis, and testing. Then, when the software is qualified, it can automatically be put into production," he said. That makes for a lovely plan, but there must surely be those who feel that it represents far too much automation and far too little oversight in the process.

Wallgren noted that there has been significant push-back from some teams, especially in heavily regulated fields like healthcare, aerospace, and financial services. in reality, though, "DevOps demonstrably works better for security, demonstrably works really well with governance and auditing," Wallgren said.

The reason for the good fit lies in the nature of regulatory compliance. "Fundamentally, an auditor wants two things. They want you to documents what you do and they want you to prove that you did what you documented," Wallgren said. "Automation definition is the documentation of what you do. The run-time record of that automation is the proof that you did what you documented," he explained.

You're invited to attend Light Reading’s LTE Advanced Pro and Gigabit LTE: The Path to 5G event -- a free breakfast collocated at Mobile World Congress Americas with a keynote address by Sprint's COO Günther Ottendorfer.

Automation makes security more attainable because it removes some of the human investment required for each step and eliminates the possibility of human error at specific steps in the process. "Once we get to the point where we're automated and we're fast then it becomes less painful to do all the right steps every single time," Wallgren said.

There are legitimate reasons that many companies went to a silo'd approach, Wallgren said, but those reasons become less critical when companies change their objectives. A security silo, for example, is great for maximizing the utilization of security specialists: Requests from all departments are lined up in front of the security silo, which stays busy by switching between tasks in the queue. If the objective switches from "maximum utilization of a scarce resource" to "maximum security" then the silo begins to make less sense from a business perspective.

Even though integrating security into the engineering, development, and operational processes makes sense from a "maximizing security" point of view, Wallgren admits that it can be difficult. "It's difficult to re-architect teams and individuals," Wallgren said. "In many cases we're asking people to change the way they work -- hopefully for the better. But change is change, and people don't like to have their cheese moved, as the saying goes."

Wallgren went on to point out that agile and DevOps don't have to be "all or nothing" migrations for organizations. "A lot of teams do 'water-scrum-fall,' " he explained. "You know, we do a lot of up-front planning and then we do a bunch of scrum in the middle, and then we have some stuff at the end where we release the product." He noted that the hybrid approach can be good; in his opinion, agile is big enough, and flexible enough, to cover a wide variety of implementations.

Related posts:

— Curtis Franklin is the editor of SecurityNow.com. Follow him on Twitter @kg4gwa.