Elusive Security Automation
- January 08, 2020
As we begin 2020, we continue to see significant technology transformations. Enterprise infrastructure in hyper-scale public clouds and large-scale containerized/serverless computing are two examples of mainstream IT environments that were either non-existent or very rare five years ago. Progress does not look as impressive on the security front, however. Why is this? “Security is fundamental,” or so the IT saying goes.
The security industry has, by no means, stood still the last 5 to 10 years. Go to any security conference, and you will find dozens, if not hundreds of new security vendors offering innovative approaches, services, and technologies. But if you compare the average enterprise security architecture and operation today to that of 5 to 10 years ago, the difference is underwhelming — and in some cases — discouraging.
Everyone knows threat actors operate very differently today than they did ten years ago. The ratio of security staff to development staff is continuing to shrink. Applications, operations, employees, hackers, all move around and morph and scale in dizzying ways. So why are a large number of enterprises still struggling with traditional security models with less and less effectiveness?
Let’s look at some reasons why focusing on automation as both a goal of — and means to — transformational security.
Every dollar spent on security is, at best, an annoyance to board members, primarily because it’s money not spent on growing the business. “Security spend” is more “threat spend.” where a bad guy somewhere might punish you if you don’t spend it!
This is the fundamental reality in security today! Security will always be scraping and fighting for a budget. Advanced security investments, those that move an enterprise well beyond the standard (minimum) best practices, will always be few and far between, particularly for organizations that still do not view IT as a business driver.
2. Security Principles
A second fundamental reality (and one which is more of a mixed blessing), are basic security principles. Some security basics are grounded in logic, so they are, in effect, timeless and universal. The prime example is the principle of least privilege.
Public cloud providers now offer some fairly robust native security tools. Enterprises are using these cloud providers to build sophisticated environments, and the native security tools offer matched sophistication. But many of the tools are merely implementing the least privilege principle with cloud-ready capabilities, so even the most advanced implementations still bring us back to the fundamentals.
Other security basics — such as: understanding your risks/assets, maintaining visibility to prevent known threats, and detect new threats — are also universals. Most innovation in the security space focuses on incremental improvement of these fundamentals. Well-executed fundamentals are critical to security success, but they can become a comfort zone trap when we rarely see genuinely transformative innovation.
The IT security market continues to be dynamic, with hundreds of new firms launched every year, but it also continues to be a very difficult place for those firms to succeed. As noted above, it’s rare to see a revolutionary offering from these new firms. The vast majority are instead leveraging technology to improve upon or replace a human-centric security task. Security automation, in other words.
The difficulty in succeeding in the security market is evidence of widespread hesitancy towards automation. Skepticism of automation/change/automobiles replacing horses and buggies is nothing new, but it’s holding back the security side of IT more than others.
Combine the economic reality of IT security with the incremental, fundamentals-focused nature of industry development, and the result is an enterprise mindset collectively set against innovation/automation.
In Part 2, I will discuss four more factors in the slow adoption of security automation: 4) Security is a High Stakes arena, 5) Data quality impediments, 6) The automation maturity curve, and 7) Defining automation.