Four (More) Reasons Security Automation Remains Elusive

As technology transforms, we have seen remarkable advancements in enterprise infrastructure in hyper-scale public clouds and large-scale containerized/serverless computing. But when it comes to security, progress does not look as impressive. A comparison of the average enterprise security architecture and operation today with that of 5 to 10 years ago, the difference can be underwhelming. And threat actors continue to find new and interesting ways to wreak havoc.

In the first part of this three-part series, we set out three fundamental reasons why security automation lags behind the rest of the IT industry, including 1.) Economics, 2.) Security Principles and 3.) Mindset. In this post, we continue that list with four more specific reasons.

4. High Stakes
Skepticism toward security automation is not an unreasonable mindset. Security tech., for example, has two main functions: detection and prevention. Detection is relatively harmless; prevention is not. Prevention is about breaking, interrupting, stopping. When we say a security system is properly tuned, what we mean is the system will only interrupt the malicious activity and cause no impact on legitimate activity.

When security automation enters the conversation, many SecOps minds gravitate towards the doomsday scenario of a runaway security system. They understand that security automation gone awry is an excellent way to DOS your own environment.

5. Data Quality
Data is a fundamental building block of any automation initiative, security or otherwise. Data quality then becomes an accelerator or an impediment to security automation. Ask most medium and large enterprises if they trust their CMDB as complete and authoritative, or have accurate identity/authorization maps, or have complete (or any) application flows mapped to trust boundaries.

To the average enterprise, the security data gap is a major impediment to security automation. Most enterprises will have staff with working knowledge of what applications should be allowed to talk to what, what identities/roles should be allowed to access what, what assets exist in various classification buckets. But that is not data that a machine can leverage to automate a task.

Automation built on a shaky data foundation is a dead-end. Most enterprises understand this in the planning stages and abandon security automation initiatives before they start down a dead-end road.

6. Maturity Curve
Security automation exists at the end of a maturity curve. Enterprises cannot realistically consider automation until they first achieve the prerequisite points along a maturity curve. The points can be categorized into two general buckets — technology and operational readiness.

Technology readiness means an enterprise maintains a modern estate, with modern features (for example, standards-based APIs), and the estate is tuned to acceptable noise levels. If an enterprise hasn’t kept up in terms of technology investment, it’s very likely they won’t have the necessary automation features. And if a system is a noisemaking, alert-fatigue-inducing machine, there are few if any safe options for tying that system into an automation architecture.

If alert fatigue is the prevailing operational state, there isn’t any foundation from which to automate the manual tasks that bog down an operation. The risks of false-positive impact would be too high and false negatives do not require automation at all, ignoring alarms is the one security task that scales extremely well.

More importantly, an operation characterized by alert fatigue is indicative of a deeper governance problem. A mature operation will incorporate asset classification to help prioritize events, as well as utilize metrics and reporting functions to identify and act on the early warning signs of alert fatigue.

Enterprises either create and follow long-term automation road maps (to build sufficient operational and technological maturity), or they lag behind on the foundational steps (and get further away from implementing modern security automation architectures).

7. What is Security Automation? 
Finally, many enterprises struggle with the simple starting point of defining security automation. Not from a dictionary definition standpoint, but from a “what is possible/realistic/advisable” angle. The security technology industry, vibrant as it is, does not make this an easy question to answer. There are dozens of new vendors each year offering their take on automation, some gaining considerable traction, most of them not. 

Technology advancements are continuously expanding the realm of what is possible, but the cutting edge is always about staying just inside the limits of what is advisable. Is it possible to tie dozens of modern technology components from disparate vendors into a single orchestration domain? Absolutely. What is less certain is whether or not you just made your environment more fragile or more robust, or if you just carried out a year-long violation of the KISS principle.

The who/what/when/where/why’s of security automation are still getting sorted out. Producers and consumers alike are actively experimenting with the scale and scope of automation. Complexity can get out of hand quickly, and in the high-stakes, high-end world of security automation, it’s not surprising we see cautious progress.

We will conclude by discussing what enterprises can do in the face of all these challenges to move the security automation needle in the right direction. 

Learn more about NTT DATA’s Managed Security Services.