No Automated Tool is Capable of Providing the Full Context in Which a Threat Was Developed and Deployed
Like most security practitioners, I can thank automation for streamlining, expediting, and even replacing many of the tasks and controls that help fend off everything from network intrusions to DDoS attacks. But with so many tools at our disposal designed to block certain types of threats automatically while requiring relatively little, if any, effort from security personnel, there is less incentive for us to seek to understand these threats, the adversaries behind them, and why they’re targeting us in the first place. And when we don’t fully understand the threats we face, we’re doing a disservice to the organizations we’ve been entrusted to help protect. Here’s why:
No tool is infallible
Among the downfalls of automation in security is the fact that even some of the most sophisticated tools aren’t always capable of blocking all the threats they were designed to block. Tools can and do malfunction for various legitimate reasons. To further complicate matters, adversaries are continually shifting their tactics, enhancing their capabilities, and developing new ways to bypass these tools. And sometimes, adversaries succeed. When this happens, security teams without a solid understanding of the threat their tool was supposed to block but didn’t will inevitably be at a disadvantage in their fight against this threat and the adversaries behind it.
Signature-based automated tools such as intrusion prevention systems (IPS), for example, highlight this concept particularly well. By comparing network traffic against signatures of known threats, an IPS automatically blocks traffic whenever it detects a signature. But what about traffic from unknown threats with unknown signatures? Many malware authors have been known to develop malware strains that do not contain the same attributes as those with known signatures, thereby enabling the malware to bypass IPS and, if not detected or blocked by another line of defense, penetrate the network.
The outcome of such a scenario would naturally depend on the malware’s functionality, whether it executed, and how long it remained undetected inside the network. While no security program should expect to be able to neutralize each and every threat that attempts to bypass it, the better acquainted a program’s personnel are with the ins and outs of the threat landscape, the more effective their threat detection and mitigation efforts are likely to be—especially in the event that an automated tool fails to do its job.
Automation cannot replace education
As security practitioners, it’s our duty to share our knowledge with others. Some of the most effective security programs do this by conducting enterprise-wide training sessions on topics such as security awareness, best practices, and reporting procedures. When security teams are less informed about the threats and adversaries targeting their organizations, however, they become less capable of sharing critical information like this with others.
To further illustrate why user education is so important, let’s talk about phishing. Most organizations depend to some degree on automation to block phishing attempts, but again, none of these tools is perfect. And because phishing targets end-users, education is imperative. This is why security teams must keep up with emerging phishing campaigns and social engineering tactics. If they don’t, they won’t be able to educate users on how to identify and report phishing emails, and as a result, these users will be less capable of doing so in the event that one lands in their inbox.
Risk reduction requires more than automation
The phishing example underscores another reason why it’s imperative for security teams to gain insight into, and educate end-users on, the threats facing their organizations: It can help them mitigate risk more effectively.
Now let’s consider two hypothetical programs that aim to reduce an organization’s risk of experiencing a successful phishing attack. Program A’s strategy is to ensure that any and all indicators of compromise (IoCs) that have ever been linked to phishing campaigns are fed to the security operations center (SOC) and blocked automatically. Program B’s strategy is to employ some automation—primarily by using spam filters and email encryption—and then augment these measures with comprehensive and ongoing anti-phishing education and awareness training for all employees.
So which program would be more effective at reducing risk? In the short term, it could be either—both programs’ approaches to automation, though significantly different, are likely to block a considerable number of phishing attempts. But in the long term, Program A’s reliance on automated tools that block only known phishing campaigns means it likely won’t block emails from unknown or lesser-known campaigns. Although researchers are always identifying new phishing campaigns and IoCs for automated tools to block, adversaries are always deploying new campaigns that researchers haven’t yet identified and automated tools aren’t always able to block. This ongoing game of cat and mouse is largely why in the long term, Program A’s impact on its organization’s risk is likely to remain constant.
Meanwhile, Program B’s emphasis on education is likely to yield different results over time. The more educated an organization’s employees become on how to identify and report phishing emails, the fewer successful phishing attacks the organization is likely to experience. User education helps bridge the gap between the phishing emails that automation can block and those it can’t. And as long as education efforts are ongoing and ever-evolving, this gap—and therefore the organization’s risk—will likely grow smaller over time.
It’s important to emphasize that my critique of the various automated tools and functions highlighted in this article doesn’t apply to all types of automation in security. User education can’t replace or even augment the capabilities of firewalls or DDoS protection systems, for example. And although signature- and IoC-based tools can generally only block or detect known threats, these tools remain extremely valuable and necessary components of an effective security program.
What does apply to all areas of security—from network defense and endpoint protection to physical security, however, is our responsibility as practitioners to continually seek to understand the threats we encounter. No automated tool is capable of providing the full context in which a threat was developed and deployed. And without this context, we’re missing out on critical insights that, in many cases, can help us better protect the organizations we were hired to protect. This is why resources like threat intelligence, or, as I’ve highlighted many times before, Business Risk Intelligence, will always be true requirements for defenders across the enterprise.
