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.

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
 

Recommended Reading:

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? 
News
US Formally Attributes SolarWinds Attack to Russian Intelligence Agency
Jai Vijayan, Contributing Writer,  4/15/2021
News
Dependency Problems Increase for Open Source Components
Robert Lemos, Contributing Writer,  4/14/2021
News
FBI Operation Remotely Removes Web Shells From Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/14/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
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-2020-28973
PUBLISHED: 2021-04-21
The ABUS Secvest wireless alarm system FUAA50000 (v3.01.17) fails to properly authenticate some requests to its built-in HTTPS interface. Someone can use this vulnerability to obtain sensitive information from the system, such as usernames and passwords. This information can then be used to reconfig...
CVE-2021-29456
PUBLISHED: 2021-04-21
Authelia is an open-source authentication and authorization server providing 2-factor authentication and single sign-on (SSO) for your applications via a web portal. In versions 4.27.4 and earlier, utilizing a HTTP query parameter an attacker is able to redirect users from the web application to any...
CVE-2021-31523
PUBLISHED: 2021-04-21
The Debian xscreensaver 5.42+dfsg1-1 package for XScreenSaver has cap_net_raw enabled for the /usr/libexec/xscreensaver/sonar file, which allows local users to gain privileges because this is arguably incompatible with the design of the Mesa 3D Graphics library dependency.
CVE-2020-23907
PUBLISHED: 2021-04-21
An issue was discovered in retdec v3.3. In function canSplitFunctionOn() of ir_modifications.cpp, there is a possible out of bounds read due to a heap buffer overflow. The impact is: Deny of Service, Memory Disclosure, and Possible Code Execution.
CVE-2020-23912
PUBLISHED: 2021-04-21
An issue was discovered in Bento4 through v1.6.0-637. A NULL pointer dereference exists in the function AP4_StszAtom::GetSampleSize() located in Ap4StszAtom.cpp. It allows an attacker to cause Denial of Service.