Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Security Management

8/15/2017
01:05 PM
Curtis Franklin Jr.
Curtis Franklin Jr.
Curt Franklin
50%
50%

DevSecOps: Security in the Process

Can building security into the process make everything more secure? Proponents of DevSecOps say 'Yes.'

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.

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Enterprises are Attacking the Cybersecurity Problem
Concerns over supply chain vulnerabilities and attack visibility drove some significant changes in enterprise cybersecurity strategies over the past year. Dark Reading's 2021 Strategic Security Survey showed that many organizations are staying the course regarding the use of a mix of attack prevention and threat detection technologies and practices for dealing with cyber threats.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-33988
PUBLISHED: 2021-10-19
Cross Site Scripting (XSS). vulnerability exists in Microweber CMS 1.2.7 via the Login form, which could let a malicious user execute Javascript by Inserting code in the request form.
CVE-2020-12141
PUBLISHED: 2021-10-19
An out-of-bounds read in the SNMP stack in Contiki-NG 4.4 and earlier allows an attacker to cause a denial of service and potentially disclose information via crafted SNMP packets to snmp_ber_decode_string_len_buffer in os/net/app-layer/snmp/snmp-ber.c.
CVE-2021-29912
PUBLISHED: 2021-10-19
IBM Security Risk Manager on CP4S 1.7.0.0 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 207828.
CVE-2021-38911
PUBLISHED: 2021-10-19
IBM Security Risk Manager on CP4S 1.7.0.0 stores user credentials in plain clear text which can be read by a an authenticatedl privileged user. IBM X-Force ID: 209940.
CVE-2021-3746
PUBLISHED: 2021-10-19
A flaw was found in the libtpms code that may cause access beyond the boundary of internal buffers. The vulnerability is triggered by specially-crafted TPM2 command packets that then trigger the issue when the state of the TPM2's volatile state is written. The highest threat from this vulnerability ...