Vulnerabilities / Threats

6/20/2018
10:30 AM
Dan Koloski
Dan Koloski
Commentary
Connect Directly
Twitter
RSS
E-Mail vvv
0%
100%

Improving the Adoption of Security Automation

Four barriers to automation and how to overcome them.

IT has always added value through automation, but its penetration into security practices historically has been lower than in other functional areas. For example, in the just-released Oracle and KPMG Cloud Threat Report 2018, only 35% of respondents said that "Our company is committed to security automation and actively investing in solutions," even as the survey revealed that a fundamental aspect of protecting the cloud-enabled workplace is the challenge of keeping pace at scale.

Automation should be an essential part of the IT toolkit, enabling organizations to massively scale and remove effort, but it currently isn't widely adopted in most enterprises. To attack this problem, it's important to understand automation's barriers to adoption and how they can be overcome.

Barrier 1: We're Not Confident in Our Decision-Making
It's striking how often customers tell me they can't automate remediation because they aren't sure enough of their analytic conclusions to know if their automated remediation can actually help in a given scenario. This is a symptom of an upstream analytics problem, not really an automation problem. Overcoming this barrier involves improving the quality of upstream data and analytics with which to make decisions, and making the results of those decisions available to an orchestration/automation framework, which really means you need an analytics platform that can cope with the volume generated by a unified and comprehensive data and telemetry set.

Barrier 2: Not Everything We Want to Secure Is Easily Automatable
Platform choice matters, even though that choice is not always up to the security team. Now, more than ever, is the time for security teams to advocate that technical platform choices for upcoming projects must be automatable and ideally be as autonomously self-securing as possible. At any enterprise, there is a wide spectrum of cloud, on-premises, and hybrid scenarios that are evolving at different rates, so it's never "too late" for the platform conversation. It's important for security experts to be informed about which platform choices can lower an application's risk posture and for them to share that information with their colleagues in application development, actively and frequently.

Barrier 3: We're Arfraid of Losing Control 
This one is cultural and understandable. Security runbooks have been manual since the dawn of computing, and analytics have historically under-delivered actionable insights, so many experienced analysts are naturally distrustful of both of them. Here it pays to start small. Instead of beginning with automation of full-life-cycle remediation, perhaps begin with automation of forensics and lightweight remediation – say, a portion of the investigative runbook of your analysts and a simple remediation action, such as turning on one-time multifactor authentication (MFA).

If the analytics algorithms identify anomalous behavioral patterns from users on one system, a good next step could be to automatically aggregate similar user behavior across other systems and slow down the process with an MFA challenge delivered via text to users' smartphones. This sort of process isn't taking the full remediation step of account suspension, but it does automate some of the investigative runbook as well as an initial preventative step.

Barrier 4: We Have Dueling Automation Frameworks (Security vs. DevOps)
The industry trend for automation over the last several years has favored the developer, with DevOps automation ubiquitously increasing the pace of bringing innovations to market. There is a natural disinclination on the part of developers and line-of-business executives to allow a second set of automation that might slow or break the DevOps pipeline. In this case, it's time for security to partner with development and operations … in other words, DevSecOps!

DevSecOps requires a level of cross-team collaboration, joint instrumentation, and automation that is possible when organizations standardize on the same underlying data/analytics/automation regime for development, security, and operations. Modern solutions that offer different "skins" for development, security, and operations users (but are really the same platform underneath) can provide the shared factual understanding that is required to begin to bridge the historical divide between these roles.

Make a Difference
Automation is one of IT's oldest weapons. It represents the best opportunity for security efforts to match the speed and scale of today's attack surface and threat vectors, but most security teams are still underinvested in the area. A closer look reveals that automation's low level of penetration is largely due to factors that aren't about the automation itself — and each of these factors represents an opportunity for security teams to make a difference.

Focusing on better analytics, informing platform choices for new projects, overcoming cultural resistance in our own teams, and collaborating with other teams can all increase the adoption of automation, which ultimately will help us improve our security posture.

Related Content:

Why Cybercriminals Attack: A DARK READING VIRTUAL EVENT Wednesday, June 27. Industry experts will offer a range of information and insight on who the bad guys are – and why they might be targeting your enterprise. Go here for more information on this free event.

Dan Koloski is a software industry expert with broad experience as both a technologist working on the IT side and as a management executive on the vendor side. Dan is a Vice President in Oracle's Systems Management and Security products group, which produces the Oracle ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
nathanluise92
50%
50%
nathanluise92,
User Rank: Apprentice
6/27/2018 | 4:54:37 AM
More barriers
You mention only 4 barriers, but what if it is more than 4? Also it depends from the manufacturing issues and some addtional needs. What to do in such cases? Can you suggest any great examples of dealing with this problem? 
White House Cybersecurity Strategy at a Crossroads
Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/17/2018
The Fundamental Flaw in Security Awareness Programs
Ira Winkler, CISSP, President, Secure Mentem,  7/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-14492
PUBLISHED: 2018-07-21
Tenda AC7 through V15.03.06.44_CN, AC9 through V15.03.05.19(6318)_CN, and AC10 through V15.03.06.23_CN devices have a Stack-based Buffer Overflow via a long limitSpeed or limitSpeedup parameter to an unspecified /goform URI.
CVE-2018-3770
PUBLISHED: 2018-07-20
A path traversal exists in markdown-pdf version <9.0.0 that allows a user to insert a malicious html code that can result in reading the local files.
CVE-2018-3771
PUBLISHED: 2018-07-20
An XSS in statics-server <= 0.0.9 can be used via injected iframe in the filename when statics-server displays directory index in the browser.
CVE-2018-5065
PUBLISHED: 2018-07-20
Adobe Acrobat and Reader 2018.011.20040 and earlier, 2017.011.30080 and earlier, and 2015.006.30418 and earlier versions have a Use-after-free vulnerability. Successful exploitation could lead to arbitrary code execution in the context of the current user.
CVE-2018-5066
PUBLISHED: 2018-07-20
Adobe Acrobat and Reader 2018.011.20040 and earlier, 2017.011.30080 and earlier, and 2015.006.30418 and earlier versions have an Out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure.