Phishing – in its many varieties – is the threat most security leaders are concerned about protecting their organizations against. Why? Because attacks are frequent, hard-to-spot, time-consuming to investigate, and expensive to recover from.

And legacy solutions like Secure Email Gateways (SEGs), sandboxes, DMARC, and security awareness training out there just aren’t enough. With these methods, users aren’t engaged in a meaningful way and unknown anomalies aren’t accounted for.

But there’s a better way. 

This blog evaluates the shortcomings of legacy phishing prevention solutions, and proposes a different approach: Human Layer Security.

Note: This article is based on an extensive whitepaper available for download. The whitepaper provides greater depth as it compares Human Layer Security with the legacy security solutions discussed here.

The problem with SEGs & native tools

SEGs lack the intelligence to learn user behavior or rapidly adapt.

The backbone of a SEG is traditional email security approaches – static rules, signature based detection, library of known threats, etc. Meanwhile, attackers consistently evolve their techniques, email networks are dynamic in nature, and human behavior is inconsistent and unpredictable. That means rules are out of date as soon as they are created and signature-based approaches are ineffective.

They can’t detect advanced impersonation, account takeover (ATO), third-party supply chain risk, or wire fraud.

Worse still, SEGs don’t address other entry points like Microsoft SharePoint, OneDrive, and ShareFile, which are some of the most hacked cloud tools.

What about native controls like Microsoft ATP?

O365’s native security controls do protect users against bulk phishing scams, spam, malware, and domain spoofing. And these tools are great when it comes to stopping broad-based, high-volume, low-effort attacks – they offer a baseline protection.

But, today’s email attacks have mutated to become more sophisticated and targeted.

Attackers use automation to make small, random modifications to existing malware signatures and use transformation techniques to bypass these native O365 security tools. Unsuspecting – and often untrained – users fall prey to socially engineered attacks that would be hard for even a security expert to spot.

Why sandboxes fail to detect phishing attacks

One of the primary ways sandboxes can fail is in phishing attempts.

Any detection made by the sandbox is dependent on a file exhibiting malicious behavior. This is easy to work around. Hackers will often send a PDF that contains a link to a malicious form to avoid detection.

Likewise, documents with a URI (Uniform Resource Identifier) have an extremely low footprint for sandboxes to detect. And the short TTL domain doesn’t leave much evidence for event analysis or threat intelligence.

There are issues with latency, too. Emails, communications, downloads, and important files can take several minutes to reach their destination because of the bottleneck sandboxes can create. This is not an option in today’s modern enterprises where real-time communication and collaboration is paramount.

Why DMARC isn’t enough

Domain-Based Message Authentication Reporting and Conformance (DMARC), is an added authentication method that uses both SPF and DKIM to verify whether or not an email was actually sent by the owner of the domain that the user sees.

In order for DMARC to pass, both SPF and DKIM must pass, and at least one of them must be aligned.

While impersonating a given domain is a common method used for phishing and other malicious activities, there are other attack vectors that DMARC does not address. For example, DMARC does not address domain impersonation attacks (i.e. sending from a domain that looks like the target being abused – e.g. exampl3.com vs. example.com), or display name impersonation (i.e. modifying the “From” field to look as if it comes from the target being abused).

The other misunderstood aspect of DMARC is that enabling DMARC on your domain protects your domain from being used in a phishing attack. But to protect your organization against phishing and spear phishing attacks, all domains used in communication with your employees should have DMARC enabled on them.

But still, only one-third of businesses employ DMARC.

This makes the security of your organization dependent on other companies communicating with your organization and vulnerable to supply chain risk, especially since DMARC records are publicly available, meaning attackers can easily identify and target domains that are not registered, and thus are vulnerable to impersonation.

Finally, in addition to their own internal domains, organizations are likely to use some combination of Office 365, Gmail, MailChimp, Salesforce.com and other third-party email services. But it’s a challenge to then retrofit them all with DMARC.

Want to learn more? We explore the limitations of DMARC in more detail here.

The limitations of security awareness training

Security Awareness Training (SAT) is seen as a “quick win” when it comes to security – a box-ticking exercise that companies can do in order to tell their shareholders, regulators and customers that they’re taking security seriously.

Sadly, the evidence of these initiatives being conducted is much more important than the effectiveness of them.

And engagement is a big problem. Too many SAT programs are delivered once or twice a year in lengthy sessions. This makes it really hard for employees to remember the training they were given, and the sessions themselves have to cram in too much content to be memorable.

It’s also difficult for security leaders to trains their employees to spot today’s sophisticated attacks. That’s because SAT platforms rely on simulating phishing threats by using pre-defined templates of common threats. This is a fair approach for generic phishing awareness (e.g. beware the fake O365 password login page), but it’s ineffective at driving awareness and preparing employees for the highly targeted and continuously evolving phishing threats they’re increasingly likely to see today (e.g. an email impersonating their CFO with a spoofed domain).

What is Human Layer Security?

The only question left to answer is: When legacy solutions and training programs aren’t enough, how can we prevent employees from interacting with the malicious emails that land in their inbox?

The answer is Human Layer Security (HLS).

Human Layer Security (HLS) automatically detects and prevents threats by understanding human communication patterns and behavior, building a unique security identity for each and every employee, and continuously improving their security reflexes over time.