Human technology

Why the “Autonomous Security Operations Center” is a pipe dream

Many vendors in the security industry share a vision: to provide an autonomous security operations center (SOC) with their technology at the center. This idea is about as likely as me to be able to join Starfleet and travel with Captain Janeway in my lifetime. Why? First, let’s level exactly what does autonomous mean:

designating or performed by a device capable of operating without direct human control

The idea of ​​a security system that you could literally set and forget is compelling – no more understaffing, no more security policies, no more loopholes. Yet even in the physical world, we have not perfected the art of machine-based security. Estimates suggest that there are more than 20 million private security workers worldwide. Why so many people? Because machines cannot observe, interpret, and react to the infinite variations of human decisions quickly, completely, and accurately in the physical…or digital world.

Second, the expectation many have of automation does not match reality, for several reasons. Automation in the SOC comes in one of two forms: manual process automation or automation embedded in security technologies. Manual process automation is limited for the following reasons:

  • As with physical security, humans are still mandatory, even for basic processes. Human/machine collaboration is a necessity for automation used in global enterprises, especially when it comes to security technologies. The classic example of automation technology designed for security practitioners is Security Orchestration, Automation, and Response (SOAR), the security equivalent of basic digital process automation. (DPA), which efficiently automates repeatable processes such as sales orders, lead generation, and payroll. . It is best used for simple, repeatable systems. But even that can go off the rails without human scrutiny, such as when employees are automatically outsourced. If controls aren’t in place to ensure that employees who have actually left the company are being relocated, you could find yourself in detrimental situations…like CEOs losing access or integrity to all of their accounts.
  • Automation is not designed for complex systems that require resiliency. Reaping the benefits of DPA requires a simple system, and unfortunately the SOC is not one. The SOC faces highly inconsistent inputs in the form of ever-changing threats, which produces inconsistent outputs. When automation is applied to a complex system made up of unpredictable inputs, it does the opposite of what we expect from a simple system: it reduces consistency and quality, and it reduces resilience while increasing the risk of break time. Imagine an assembly line that starts with the wrong basic part – that unexpected little part can break the whole system.
  • Each step added to an automation chain limits the scope. Suppose your security team wants to implement a security orchestration, automation, and response (SOAR) playbook that, in the event of a potentially malicious file being executed on a box from a phishing email: isolates the endpoint; checks reputation on VirusTotal; confirms that the file is malicious; delete the file; remove the phishing email from the environment; and block the sender of the email. This can be a very beneficial playbook for a security team that regularly encounters this issue. However, this limits the scope, as a series of steps must be completed before the playbook is triggered. This works fine for consistent input, but when the input is as inconsistent as it is in SOC, with constant new attacks, new tech, and new people, it stops being nearly as effective.

These are also some of the reasons why practitioners struggle to derive much value from SOAR beyond 5-10 playbooks (most of which focus on enrichment).

Finally, the automation built into security technologies is limited because:

  • Humans can always outsmart machines. Human attackers don’t follow the rules of engagement; they identify gaps in security technologies or even attack the security technology itself. On the other hand, security tools to have to follow a set of rules – they’re designed with intent in mind, whether that’s detecting threats on the endpoint or finding anomalies in otherwise consistent data. These constraints impose a limit on the technology that cannot be overcome without the help of humans. If an organization uses endpoint detection and response, an attacker will find a way to bypass it or not target an endpoint. If an organization collects all logs from every asset in a security information and event management system, an attacker will find a vulnerable employee to exploit for covert access. Technology will always be limited by the purpose for which it was designed and will always lack the creativity and scope to deal with every potential threat.

Some return to this last point and say:In fact, Deep Blue beat world chess champion Garry Kasparov in 1997!” And that’s true. But it misses the point. Chess is a game based on a finite set of rules that both sides agree to follow. Machine learning (ML) is built into a particular set of constraints and optimizes itself based on those constraints – so chess would actually be a good game for ML or AI to excel.

Security is different. If anything, attackers As breaking the rules, especially the very rules around which our technology is structured. The “autonomous SOC” will not be able to operate beyond the constraints we define and will therefore always be susceptible to attack and pose its own risks to the organization. We cannot be constrained by rules that we put into our technology if we want a robust defense. Autonomous SOC will never be a reality because the technology is simply not up to the task of human ingenuity.

To learn more about this topic, sign up to participate in the Forrester Security and Risk Forum here.

This post was written by Senior Analyst Allie Mellen and originally appeared here.