Phishing Tests: Are We Doing this Right?
Phishing tests have become a widely used method for organizations looking to gauge cybersecurity awareness among their employees and assess the resilience of their networks. By simulating realistic attacks—often through carefully crafted emails that mimic genuine communications—they provide companies with useful insights into how their staff responds under real-world conditions.
In principle, carrying out such exercises might seem like a no-brainer, hence their popularity. But over-reliance on this practice when it comes to enhancing security can have its downsides.
The problem with current phishing tests
Bypassing security controls. Many phishing tests rely on internal mail relay servers, allowing them to bypass critical security measures like DMARC and domain-based fraud detection. This can give users a false sense of security, as they may assume that any emails reaching their inbox have already been vetted. They may assume the domain is registered and controls through DMARC, DKIM, and SPF have been satisfied to authenticate and vet the sending domain.
Undermining user trust. Internal mail relays often suppress warnings about external emails, a crucial security indicator. This can confuse users and make them less likely to trust genuine warnings in the future. The warnings are generated as mail passes from an external source through the mail server and any related ingress monitoring and detection controls. When you bypass those controls by using an internal mail server, the alerts or red flags that you have trained your users to rely upon are not present and the message shows up as internal and not of concern (e.g. the recipient knows that the message is a test and is safe).
Creating a false sense of security. Some tests use unrealistic scenarios, such as emails appearing to be replies to messages the user never received. This can lead users to believe that any email with unusual characteristics is automatically a test.
These measures are counter to the conditioning of users in a way that is not desirable. What if your user recognizes these indicators and that the test must be a test and clicks the link or opens the document since they are sure nothing bad will happen? They really can't say that as it wouldn't be believed, but the safeguard indicators told them it was safe, and it was.
What if instead, we secured our systems to reduce the threat of a phishing attack? What if we used a mail client and server that had a lower success rate for phishing attacks? What if our credentials for applications were phishing resistant? At a certain point, the costs toward these controls is less than the phishing test subscription, maintaining the mail relay server, and the staff time to generate the tests.
A better approach
Instead of relying heavily on potentially misleading phishing tests, organizations should prioritize proactive security measures:
Invest in secure infrastructure. Utilize email clients, servers, and mail applications with built-in security controls to prevent attacks from being successful. Ensure client systems have a minimized attack surface, with mail accessed and viewed in an application that provides appropriate sandboxing from the user’s host operating system.
Implement phishing-resistant authentication. Adopt strong authentication methods, such as phishing resistant multi-factor authentication (MFA), to minimize the impact of successful phishing attempts. These measures should be deployed across enterprise applications to prevent lateral movement or credential re-use attacks.
The cost of phishing tests
There's one other area of concern worth raising here, which is that the cost of implementing and maintaining a robust phishing testing program can be significant. This includes the cost of the testing software, supporting infrastructure to bypass security controls, the time spent creating and deploying tests, and the potential disruption to employee productivity. By investing in proactive security measures, organisations can reduce the need for phishing tests while simultaneously enhancing their overall security posture.
A personal anecdote
I once received a phishing test that claimed I had won an award for my book. While flattering, it wasted my time investigating the award and notifying my publisher about a potential scam. This and other user testing experiences have highlighted the potential for phishing tests to be counterproductive and time consuming.
Conclusion
It's time to re-evaluate our approach to email and application security. By focusing on proactive security measures, Security Built-in at Scale (BiaS), organizations can better protect themselves from real-world threats while minimizing the potential for disruption. There are security controls integrated by design into some email platforms that reduce the opportunity for attacks to be successful and also reduce the distributed security burden placed on organizations.
