Phishing Tests: Are We Doing This Right?

Phishing tests have become a widely used method for organisations 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.
• 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.
• 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 recognises 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, organisations should prioritise proactive security measures:

• Invest in secure infrastructure
  Utilise email clients, servers, and mail applications with built-in security controls to prevent attacks from being successful.
• Implement phishing-resistant authentication
  Adopt strong authentication methods, such as phishing resistant multi-factor authentication (MFA), to minimise the impact of successful phishing attempts.

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 experience 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, Built-in at Scale (BiaS), organisations can better protect themselves from real-world threats while minimising 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 organisations.