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.

Application Security

12/20/2018
10:30 AM
John De Santis
John De Santis
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

Automating a DevOps-Friendly Security Policy

There can be a clash of missions between security and IT Ops teams, but automation can help.

Much has been written about the need for a balance between DevOps and security architecture. While DevOps is all about getting whizbang apps to market as efficiently as possible, the security team is often portrayed as the party pooper — folks who tell you why you can't do something instead of how you can do it.

There's a similar clash of missions between the security team and the IT operations team. Security can be disruptive to IT Ops, with requests that can seem arbitrary and needlessly time consuming. IT Ops generally has the goal of simply keeping things running — even if this opens opportunities for bad actors.

Security has a strong case for wanting what it wants and for not wanting what it doesn't want. Security vulnerabilities are rising at an alarming clip — data theft, leakage of intellectual property, corporate sabotage, denial-of-service attacks, and more. A company's profits, reputation, brand, and even viability are at stake. But the relentless march of commerce takes no prisoners. Any company that's hamstrung from acting with speed and agility is pretty much already dead on its feet. So, we find companies willing to accept risk that those in charge of security see as unacceptable, and implementing solutions that may be insecure.

It's a tension that raises its head frequently for us at HyTrust. Our customers routinely face this tension when they try to implement our offerings. The security team wants to do X, but the IT Ops team does not want to do X. In one recent case, a client's security team wanted to implement our solution, but the IT Ops team put up roadblocks every step of the way, with a list of reasons why our offering wasn't a good idea. In this case, those on the Ops team feared the rollout would expose process flows they hadn't been following — weaknesses that made the client vulnerable.

An Unsafe House
Security architecture work is like building a safe, compliant house. The problem is that the builders made it so hard to lock the windows, turn on the security system, and operate the surveillance cameras that the inhabitants leave these tasks undone. DevOps promises to make life in the house a comfortable and efficient experience, but without a security policy that is friendly to DevOps, this promise is never fulfilled.

In a recent "Ask Me Anything" session on Reddit, Mike Foley described this problem. Mike is a senior technical marketing architect at VMware whose main goal is to help IT admins build secure platforms that stand up to scrutiny from security teams with the least impact to IT Ops. Asked what he thought was "the coolest new security toy" in the recently released vSphere 6.7, Mike said virtual Trusted Platform Module (vTPM). But it's the rationale he gave that's germane to this post:

"I like the balance of security and IT operations impact. Let's face it, if I'm an IT guy and security comes to me and says I have to do a bunch of things that I know are only going to 'make work' for me, then it's no longer a technical discussion. It's political. And everyone loses. If, as an IT guy or gal, I can meet the security requirements of security with the least impact to my day-to-day operations, then I'll be much more open to enabling those features."

Mike used VM encryption to illustrate what he means, then added: "It's the same with virtual TPM. I'm not having to completely re-jig my environment to support this need."

Automating Doing the Right Thing
No one wants to "completely re-jig" their IT environment without good cause. One reason those in charge of security don't always make a compelling case is that many security and compliance monitoring tools haven't kept pace with the times. They certainly weren't built to test code at the breakneck speed DevOps requires.

The good news is that security can take a page from the DevOps playbook — in particular regarding automation. DevOps encourages automation, and as I argued in a previous post, I favor an approach to security that automates doing the right thing — that automates ethics for cybersecurity. That's because most security breaches and system failures result from human mistakes. Automating the right thing takes a load off security architects. It spares them from having to configure security consoles manually. It reduces the chances of human error.

What is the right thing? When it comes to risk, most companies already have clear governance of what they consider it to be. From this, they derive their security policies. A security policy is whatever you decide is the correct behavior, based on experience. The next step is to bake these policies into your processes — which puts us squarely into DevSecOps territory.

This is a hot topic. In a 2017 survey, Gartner found that the issue of how to securely integrate security into DevOps — delivering DevSecOps — was one of the fastest-growing areas of interest of clients in the preceding 12 months. A key finding was that information security must adapt its security testing tools and processes to developers, not the other way around. As more companies embrace DevOps principles to help developers and operations teams work together to improve software development and maintenance, they're increasingly automating security in this way. In fact, the Gartner report predicts that DevSecOps will be embedded into 80% of rapid development teams by 2021.

Automating doing the right thing is key to a DevOps-friendly security policy — a policy that's also friendly to IT Ops. Going back to the "Ask Me Anything" session on Reddit, one poster joked that Mike's focus on minimizing impact to IT Ops was "the lazy man's approach." Mike's terrific comeback: "One man's lazy is another man's 'I have only so much time in the day.' :)"

Related Content:

John De Santis has operated at the bleeding edge of innovation and business transformation for over 30 years -- with international and US-based experience at venture-backed technology start-ups as well as large global public companies. Today, he leads HyTrust, whose ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
mohara-avon
50%
50%
mohara-avon,
User Rank: Apprentice
3/8/2019 | 8:08:46 AM
Excellent Article!
The article really hits the nail on the head...  striking the balance between security and a seamless experience within DevOps is a delicate process, albeit an absolute requirement.

We are in the early stages of SecDevOps and have ID'd a solution that integrates very nicely with our DEV platform (BitBucket, Jenkins & JIRA) and will introduce a completely different level of security to our coding programs.
Commentary
Ransomware Is Not the Problem
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  6/9/2021
Edge-DRsplash-11-edge-ask-the-experts
How Can I Test the Security of My Home-Office Employees' Routers?
John Bock, Senior Research Scientist,  6/7/2021
News
New Ransomware Group Claiming Connection to REvil Gang Surfaces
Jai Vijayan, Contributing Writer,  6/10/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Zero Trust doesn't have to break your budget!
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-34812
PUBLISHED: 2021-06-18
Use of hard-coded credentials vulnerability in php component in Synology Calendar before 2.4.0-0761 allows remote attackers to obtain sensitive information via unspecified vectors.
CVE-2021-34808
PUBLISHED: 2021-06-18
Server-Side Request Forgery (SSRF) vulnerability in cgi component in Synology Media Server before 1.8.3-2881 allows remote attackers to access intranet resources via unspecified vectors.
CVE-2021-34809
PUBLISHED: 2021-06-18
Improper neutralization of special elements used in a command ('Command Injection') vulnerability in task management component in Synology Download Station before 3.8.16-3566 allows remote authenticated users to execute arbitrary code via unspecified vectors.
CVE-2021-34810
PUBLISHED: 2021-06-18
Improper privilege management vulnerability in cgi component in Synology Download Station before 3.8.16-3566 allows remote authenticated users to execute arbitrary code via unspecified vectors.
CVE-2021-34811
PUBLISHED: 2021-06-18
Server-Side Request Forgery (SSRF) vulnerability in task management component in Synology Download Station before 3.8.16-3566 allows remote authenticated users to access intranet resources via unspecified vectors.