It has been argued that automation in the workplace tends to be misunderstood. Analysts are keen to point out that, despite myths to the contrary, automation isn’t going to put most people out of work, for instance. Nor is AI going to become a real substitute for actual human intelligence.

These are compelling arguments for rethinking the way we think about automation in general. But you can take the points further if you analyze the impact of automation on specific domains, such as cybersecurity.

Indeed, automation is perhaps nowhere more misunderstood than in the realm of cybersecurity. To prove the point, here are five common myths about automation’s impact on security, and why they’re wrong.

Myth 1: Automation Is Only a Reactive Part of SecOps

If you ask engineers how they can actually add security automations to their workflows, you’ll probably hear answers that focus on writing rules to drive automated remediation of security issues. Maybe you configure your SIEM to block a host that is port-scanning your network, for example.

Automations like these are fundamentally reactive. They can only be used to respond to security incidents that are already in motion. As a result, if you focus on this category of security automation, you may come away with the belief that automation can be used only in a reactive way within SecOps.

That’s not true. While automated security incident response is one use case for security automation, proactive management of security incidents is just as important. Automatically scanning IaC configurations or running networks to detect vulnerabilities is one way to leverage automations proactively, for example. Another is to automate collaboration between developers, IT operations teams, SecOps teams, and other stakeholders in preventing security risks before they turn into active threats.

Myth 2: Security Automation Is Just a New Term for Automated Security Testing

It’s also easy to fall into the trap of believing that the only thing you can do with security automation tools is perform the types of tests and scans that teams were running (often with the assistance of automated testing tools) long before “security automation” became a buzzword.

From this point of view, security automation may seem like just a flashy term to describe established practices, such as SAST, DAST, and container image scanning.

In reality, this is a narrow way to think about use cases for security automation. Again, automation can be used to do things like help manage complex security workflows and optimize collaboration between different stakeholders. These are tasks that were not traditionally automated.

So, while scanning and testing may be one example of a security automation use case, it’s hardly the only one.

Myth 3: Only Enterprises Need Security Automation

If you do SecOps work for a small business, you may believe that you don’t operate on the scale at which security automation becomes necessary. Only enterprises with thousands of endpoints and sprawling teams need automation, right?

Wrong. While contending with large-scale environments may be one reason to embrace automation, businesses of all sizes face challenges related to other forms of scale when it comes to security.

For instance, there are about 1 billion known types of malware in existence, and they imperil businesses of all sizes equally. Whether you’re a SecOps team of 1 or 100, you need security automation to manage risks on this scale.

Myth 4: Automation Will Replace Skilled Security Professionals

As with any form of automation, the doom-and-gloomers among us may believe that security automation is going to kill jobs and make highly skilled humans irrelevant.

Hardly! Any business that attempts to automate security will quickly find that most high-stakes security issues are far too complex to be detected and remediated by automation tools alone.

Sure, security automations may be able to do things like alert you about an insecure access control policy or adjust firewall rules to block malicious traffic.

But they are not going to deliver nuanced insight about the business impact of a large-scale breach or identify the latest and greatest emerging threats from the dark web. Human security professionals need to take the lead in that type of work.

Myth 5: You Should Automate All Security Processes

Relatedly, it’s a myth that you should strive to automate every process related to security within your organization.

You should automate routine, repetitive tasks that are not subject to much conditional variance. But workflows that can’t be reliably managed by automation tools, such as assessing the financial consequences of a breach or determining whether a security incident should trigger an application rollback, should remain the domain of humans, who can make complex security decisions that the bots just can’t.

Take A Realistic Approach to Security Automation

Instead of thinking about security automation as a form of technology that will change everything we know about SecOps, a more realistic perspective is to view automation as a way to improve some aspects of SecOps.

Just as important, remember that security automation is not only a way to react to breaches or perform automated testing. It can also be used to shape the way organizations assess risks, communicate about security issues, and so on.