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? 
What We Talk About When We Talk About Risk
Jack Jones, Chairman, FAIR Institute,  7/11/2018
Ticketmaster Breach Part of Massive Payment Card Hacking Campaign
Jai Vijayan, Freelance writer,  7/10/2018
7 Ways to Keep DNS Safe
Curtis Franklin Jr., Senior Editor at Dark Reading,  7/10/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Locked device, Ha! I knew there was another way in.
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-14337
PUBLISHED: 2018-07-17
The CHECK macro in mrbgems/mruby-sprintf/src/sprintf.c in mruby 1.4.1 contains a signed integer overflow, possibly leading to out-of-bounds memory access because the mrb_str_resize function in string.c does not check for a negative length.
CVE-2018-14329
PUBLISHED: 2018-07-17
In HTSlib 1.8, a race condition in cram/cram_io.c might allow local users to overwrite arbitrary files via a symlink attack.
CVE-2018-14331
PUBLISHED: 2018-07-17
An issue was discovered in XiaoCms X1 v20140305. There is a CSRF vulnerability to change the administrator account password via admin/index.php?c=index&a=my.
CVE-2018-14333
PUBLISHED: 2018-07-17
TeamViewer through 13.1.1548 stores a password in Unicode format within TeamViewer.exe process memory between "[00 88] and "[00 00 00]" delimiters, which might make it easier for attackers to obtain sensitive information by leveraging an unattended workstation on which TeamViewer has ...
CVE-2018-14334
PUBLISHED: 2018-07-17
manager/editor/upload.php in joyplus-cms 1.6.0 allows arbitrary file upload because detection of a prohibited file extension simply sets the $errm value, and does not otherwise alter the flow of control. Consequently, one can upload and execute a .php file, a similar issue to CVE-2018-8766.