Penetration testing and the Essential Eight

Penetration testing can help surface evidence of Essential Eight failures, but it does not on its own validate Essential Eight compliance.

We offer an Essential Eight Maturity Model Assessment, where we review implemented controls against the standard’s requirements. Penetration testing serves a different purpose, but it also gives us a huge amount of information about how your environment works and where security issues exist. That information can feed into your compliance efforts.

This page goes over which parts of the Essential Eight are often covered in penetration testing, which parts are not, and how to work with your consultant to help spot and report on potential compliance failures.

Penetration testing and DISP

If you have DISP obligations, you will likely need to meet Defence security requirements that sit alongside your broader security framework. In particular, as of the time of writing of this page, all DISP members are required to achieve and maintain compliance with the full Essential Eight Maturity Level 2 standard.

Penetration testing is not automatically required by DISP itself, but many organisations use it as one way to identify technical security weaknesses, support risk management, and demonstrate that security issues are being actively found and addressed.

Penetration testing can pick up compliance failures

A penetration test isn’t an audit - the two are extremely different practices. Whereas an audit moves step by step through a set of controls, penetration testing is a more creative exercise, finding new ways to break into systems. Still, penetration testers gain huge amounts of detailed knowledge about systems, which can allow us to spot compliance failures when we see them. Of course, whether something is a compliance failure will depend on the maturity level you’re aiming to meet.

For the strategies below, there’s the potential to spot compliance failures:

  • Patch applications and Patch operating systems: Our internal penetration testing often picks up patching failures. While it won’t be able to ensure that new patches meet requirements, if a critical patch has been available for more than 48 hours and has not been applied, that is a clear indication that your patching is not meeting the highest maturity requirements.
  • Multi-factor authentication: Penetration testing can identify a lack of Multi-Factor Authentication (MFA) for user accounts that are in scope or that have been compromised in testing. A lack of MFA, or MFA that is not phishing-resistant, is usually raised as an “additional recommendation” in our reports. However, if you let us know you’re expecting to follow the Essential Eight, we would raise it as a vulnerability and compliance failure.
  • Restrict administrative privileges: Old and inactive privileged accounts are a common target in our penetration testing. It’s the weakest link we target after all!
  • Application control: We will commonly try and bypass application control in our penetration testing efforts. If we succeed, it’s likely that you’re not meeting the requirements of the Essential Eight.

What a penetration test can tell you about Essential Eight depends heavily on scope, especially whether user endpoints, identity systems, and internal infrastructure are included.

Strategies that won’t be checked by penetration testing

Standard internal penetration testing likely won’t fully assess the following strategies:

  • Restrict Microsoft Office macros: Microsoft Office documents are not commonly used even in our phishing attacks anymore since macros from the internet have been disabled by default. We would pick this up as part of our SOE Review.
  • User application hardening: While user devices are often in scope for penetration testing, we usually focus on data stores, critical servers and infrastructure, and privileged users. Similar to macros, user applications are often exploited in phishing, social engineering, and malware attacks.
  • Regular backups: While we might “target” backups as part of a penetration test, we usually don’t check their frequency or whether they’ve been tested. We won’t, for instance, ask for records of backup testing or perform a restore as part of a standard penetration test. The only related control that may be observed is whether users or privileged users can access their own backups.

These strategies are generally better assessed through services like an Essential Eight Maturity Model Assessment or an SOE review.

Working with your consultant

The first step to using penetration testing to highlight Essential Eight compliance failures is to inform the consultant about your compliance requirements. You should tell your consultant:

  • That the environment is expected to comply with Essential Eight
  • Your target maturity level
  • Any Essential Eight requirements that are known exceptions or not yet expected to be in place
  • Any compensating controls you have
  • The likely impact of a compliance failure, so we can better inform our risk assessments

With this information, the consultant will raise compliance failures as a vulnerability and note the compliance impact. In the debrief, the consultant can then work with you to find the best way to remediate the issue, be it a change to process or a technical fix.

Penetration testing can help you spot compliance failures and understand the real impact of those failures. It can also give you confidence that your controls are working as expected in practice. If Essential Eight compliance matters for the environment being tested, make that clear up front so your consultant can actively look for relevant gaps during the engagement.