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:
Top industry experts will offer a range of information and insight on who the bad guys are — and why they might be targeting your enterprise. Click for more information.
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
More Insights
Read More HERE