Validating Essential Eight ML2/ML3: Why Pen-Testing is Non-Negotiable for Australian Critical Infrastructure

TL;DR: Key Insights

• Compliance is Not Security: Achieving Essential Eight Maturity Level 2 or 3 on paper does not guarantee protection against real-world attacks, especially sophisticated supply chain compromises.
• The Validation Gap: Checklists and configuration audits verify that a setting exists; technical validation and penetration testing prove that the control effectively stops an attack.
• Critical Infrastructure at Risk: For organisations governed by the SOCI Act, proving due diligence requires demonstrating that security controls are not just implemented, but are verifiably effective against credible threats.
• Case Study Catalyst: The April 2024 Sisense breach highlights how stolen third-party credentials can bypass perimeter defences, a scenario that checklist compliance often misses but penetration testing explicitly simulates.

Validating Essential Eight ML2/ML3: Why Pen-Testing is Non-Negotiable for Australian Critical Infrastructure

For Risk Managers overseeing Australia's critical infrastructure, compliance with the Australian Signals Directorate (ASD) Essential Eight Maturity Model is a foundational requirement. However, the recent, high-impact Sisense data breach serves as a stark reminder: a compliance certificate is not an impenetrable shield. When a trusted third-party vendor is compromised, attackers can bypass otherwise 'compliant' environments. This distinction between theoretical compliance and validated security is precisely where many organisations fail, exposing them to significant operational and regulatory risk. Achieving the higher maturity levels—ML2 and ML3—requires a fundamental shift from paper-based attestation to adversarial, technical validation.

Why Do Configuration Checklists Create a False Sense of Security?

A configuration checklist is a static snapshot. It asks, “Is multi-factor authentication (MFA) enabled for this application?” and accepts 'Yes' as a pass. A penetration test asks, “Can an attacker with stolen session cookies bypass your MFA enforcement?” This difference is critical. One confirms a setting; the other confirms a security outcome. For a Risk Manager, the latter is the only metric that truly matters in the context of the SOCI Act and board-level risk reporting. The following table illustrates this crucial validation gap:

Essential Eight Control	Checklist-Based Approach (The 'What')	Technical Validation Approach (The 'Why' & 'How')
Application Control	A policy exists that is supposed to block unapproved executables.	Attempting to execute malicious payloads (e.g., unsigned binaries, scripts) from user-writable locations to verify the control cannot be bypassed.
Patching Applications	Vulnerability scanner reports 'no critical vulnerabilities' on the day of the scan.	Actively attempting to exploit a recently patched (but potentially misconfigured) vulnerability to confirm the patch is effective and no compensating controls can be circumvented.
Multi-Factor Authentication	MFA is enabled on all required external and internal services.	Simulating token replay attacks, session hijacking, or exploiting 'MFA fatigue' to prove the implementation is resilient against common TTPs.
Restrict Admin Privileges	A report shows that only approved users are in 'Domain Admins' group.	Attempting privilege escalation from a standard user account using techniques like Kerberoasting or exploiting misconfigured service permissions to validate the principle of least privilege is truly enforced.

How a Supply Chain Attack Bypasses 'Compliant' Systems

The Sisense incident reportedly involved attackers gaining access to the company's AWS S3 buckets using credentials stolen elsewhere. This allowed them to compromise customer data and potentially push malicious updates. A critical infrastructure organisation using Sisense could have a perfectly 'compliant' Essential Eight posture internally, yet still be compromised because the threat originated from a trusted external source. A penetration test focused on supply chain risk would simulate this exact scenario.

Simplified Supply Chain Attack Vector

1. Attacker compromises Third-Party Vendor (e.g., via phishing)

➔

2. Access tokens / API keys for customer environments are stolen

➔

3. Attacker uses legitimate, trusted channels to access Critical Infrastructure target

➔

4. Internal 'compliant' controls fail to flag the malicious activity as it appears legitimate

What Does Real Technical Validation Look Like?

Technical validation for Essential Eight Maturity Levels 2 and 3 moves beyond simple checks to scenario-based testing. It's about proving resilience. For ML2, this involves validating controls against adversaries who are adept at exploiting public-facing applications and common weaknesses. For ML3, the assumption is that the adversary has already gained a foothold inside the network, and the focus shifts to testing containment and lateral movement prevention.

Data from various incident response reports shows a growing disparity between an organisation's reported compliance level and its ability to withstand a targeted attack. This gap is where technical validation becomes indispensable.

The Compliance Imperative for Critical Infrastructure Risk Managers

Under the Security of Critical Infrastructure Act 2018 (SOCI Act), responsible entities have an obligation to manage and report on risks to their assets. In the event of an incident, simply producing a compliance report may be insufficient. Regulators and stakeholders will ask for proof of due diligence. Demonstrating a history of regular, rigorous penetration testing provides defensible evidence that the organisation has proactively sought to identify and remediate weaknesses in its implemented controls. This shifts the conversation from “Were you compliant?” to “Did you take all reasonable steps to validate your defences?”—a much stronger position for any Risk Manager.

Frequently Asked Questions

Isn't our annual audit or IRAP assessment enough for Essential Eight validation?

While essential, audits and IRAP assessments often rely on documentation, interviews, and configuration reviews. A penetration test is an active, adversarial engagement designed to bypass those very controls to test their real-world effectiveness. They are complementary, not interchangeable.

What is the difference between a vulnerability scan and a penetration test in this context?

A vulnerability scan is an automated tool that looks for known vulnerabilities and produces a list of potential issues. A penetration test involves a human expert who not only finds vulnerabilities but actively exploits them, chaining them together to simulate a goal-oriented attack, thereby testing the entire defensive posture.

How does this apply to our cloud environments (AWS, Azure)?

It's even more critical in the cloud. Cloud environments are complex, and simple misconfigurations (like an overly permissive IAM role or a public S3 bucket) can lead to a complete compromise. Technical validation in the cloud involves testing these configurations, API security, and the shared responsibility model to ensure there are no gaps for an attacker to exploit.

Conclusion: From Checklist Compliance to Proven Resilience

For Australia's critical infrastructure sector, the era of treating cybersecurity compliance as a checkbox exercise is over. The threat landscape, dominated by sophisticated supply chain attacks and motivated threat actors, demands a higher standard of proof. Achieving Essential Eight Maturity Level 2 and 3 is not the goal in itself; the goal is building a verifiably resilient organisation. Risk Managers must champion the move towards continuous, technical validation. It is the only way to transform a compliance programme from a theoretical defence into a proven, battle-tested security posture.

Validating your security controls is not an admission of weakness; it is a demonstration of strength and due diligence. Lean Security's expert penetration testing services are designed to provide Australian critical infrastructure organisations with the technical validation needed to meet and exceed Essential Eight requirements. We help you find and fix the gaps before an adversary does.

Discover how to validate your Essential Eight controls by visiting www.leansecurity.com.au.

Validating the Essential Eight: Why Checklists Fail Critical Infrastructure Audits

TL;DR: Key Insights

• Checklists Are Not Proof: Relying on configuration checklists for Essential Eight compliance creates a dangerous illusion of security. It confirms settings exist, not that they are effective.
• Technical Validation is Mandatory: To achieve genuine Maturity Level 2 and 3, organisations must employ active technical validation, such as penetration testing, to prove controls can withstand real-world attack techniques.
• CISO Mandate Has Shifted: In the wake of major incidents affecting Australian critical infrastructure, boards now demand demonstrable proof of resilience, not just compliance attestations.
• Cloud Misconfigurations Bypass Controls: A correctly configured server-side control can be rendered useless by a simple cloud IAM misconfiguration, a blind spot that only adversarial testing can uncover.

Validating the Essential Eight: Why Checklists Fail Critical Infrastructure Audits

For the Chief Information Security Officer (CISO) of any Australian critical infrastructure organisation, the pressure has never been greater. The recent cyber incident at DP World Australia served as a stark, nationally significant reminder that determined threat actors view our ports, power grids, and utilities as prime targets. In this environment, the board is no longer satisfied with compliance reports; they are demanding tangible proof of cyber defence. This is where the Australian Signals Directorate's (ASD) Essential Eight Maturity Model comes into sharp focus, and where a pervasive, dangerous assumption is leading organisations astray.

The contrarian truth is this: your checklist-driven approach to achieving Essential Eight Maturity Level 2 or 3 is fundamentally flawed. It fosters a false sense of security that will shatter upon contact with a skilled adversary or a competent external assessor. True maturity requires moving beyond passive attestation to active, technical validation.

Why Do Checklist-Based Audits Fail to Reflect Real-World Risk?

A checklist audit asks, "Is the control configured?" A technical validation asks, "Does the control actually work?" The gap between these two questions is where catastrophic breaches occur. Modern environments, particularly those leveraging cloud infrastructure, are too complex and dynamic for simple configuration checks.

Consider a common attack vector: cloud misconfiguration. An organisation might correctly configure application control on its core servers, allowing only approved software to run. The checklist item is ticked. However, a developer, through a poorly configured AWS IAM role, may have permissions to execute scripts that can remotely call APIs, effectively bypassing the server's local restrictions. The checklist sees a green tick; an attacker sees an open door.

This is not a hypothetical scenario. It represents a class of vulnerabilities that automated scanners and configuration audits frequently miss. The enforcement of a security control is not determined by a single setting but by the interplay of the entire technology stack.

Attack Path: Bypassing Controls via Cloud Misconfiguration

☁️

Attacker Exploits Public-Facing API

→

🔑

Gains Access via Over-Permissive IAM Role

→

💻

Executes Unauthorised Commands, Bypassing Server-Side Application Control

→

💥

Breach Achieved

How Does Technical Validation Prove Essential Eight Maturity?

Technical validation through penetration testing simulates the actions of a real attacker. Instead of reviewing settings, it tests outcomes. This provides the CISO with irrefutable evidence for the board and external assessors that the organisation's defences are not just configured, but effective.

Let's compare the two approaches for the 'Application Control' mitigation strategy, a cornerstone of the Essential Eight:

Assessment Method	Checklist Approach (Superficial)	Technical Validation Approach (Evidentiary)
Objective	Verify a policy exists.	Prove the policy is enforced and cannot be easily bypassed.
Query	Is an application allowlist configured via GPO or an equivalent tool?	Can an unprivileged user execute an unauthorised portable application from a non-standard directory?
Evidence	A screenshot of a configuration panel. (Yes/No)	A detailed report with command logs and screen recordings showing the successful blocking of malicious.exe. (Pass/Fail with Proof)
Bypass Test	None.	Attempt to bypass the control using PowerShell, LOLBAS (Living Off The Land Binaries), or script interpreters.

For Maturity Level 2 and 3, which require stringent enforcement and detection capabilities, the evidence generated by the technical validation approach is non-negotiable. It is the only way to demonstrate that the control holds up under duress, which is the entire point of the maturity model.

What Are the Common Gaps Uncovered by Penetration Testing?

Self-assessment and checklist audits often result in an inflated sense of security. When subjected to rigorous penetration testing focused on the Essential Eight, organisations are frequently surprised by the gaps that are uncovered. These are not obscure, zero-day vulnerabilities, but fundamental bypasses of core controls.

Frequently Asked Questions

What is the difference between a vulnerability assessment and an Essential Eight validation penetration test?

A vulnerability assessment is typically an automated scan that looks for known vulnerabilities (e.g., missing patches, identified by CVEs). An Essential Eight validation penetration test is a goal-oriented, manual exercise where a tester actively tries to bypass specific controls (like application control or credential restrictions) using the same techniques as a real attacker.

How often should our organisation conduct this type of technical validation?

For critical infrastructure organisations targeting Maturity Level 2 or higher, we recommend annual, comprehensive validation tests. Additionally, validation should be performed after any significant changes to the environment, such as a major cloud migration or the introduction of new core systems.

Is this validation mandatory for an official ASD assessment?

While the ASD does not mandate a specific vendor, their assessment process for higher maturity levels inherently requires demonstrating control effectiveness. Providing the results of a robust, independent penetration test is the most effective way to supply this evidence and streamline the assessment process. A simple checklist will not suffice.

From Compliance Artefact to Demonstrable Defence

The conversation in the boardroom has evolved. The question is no longer "Are we compliant?" but "Are we secure?". For the CISO of a critical infrastructure entity, a checklist is a liability. It provides a hollow assurance that will not stand up to scrutiny.

True cyber resilience is built on a foundation of controls that are not just implemented, but rigorously and repeatedly tested. Adopting a mindset of active, technical validation turns your Essential Eight programme from a paper-based compliance exercise into a powerful, evidence-backed statement of your organisation's defensive capabilities.

Lean Security specialises in Essential Eight validation penetration testing that provides the objective proof your board and auditors require. We help you move beyond the checklist to build and prove genuine cyber resilience.

Validate Your Essential Eight Controls Today

APRA CPS 234 and the Third-Party Blind Spot: A CISO's Guide to Audit Assurance

TL;DR: Executive Summary

• The Threat: High-profile breaches originating from third-party suppliers (e.g., Snowflake ecosystem) highlight a critical, board-level risk for Australian financial institutions.
• The Mandate: APRA's Prudential Standard CPS 234 explicitly requires regulated entities to not only have controls but to systematically test their effectiveness, particularly for services managed by third parties.
• The Gap: Traditional vendor risk assessments (questionnaires, certifications) are no longer sufficient. They fail to provide empirical evidence of a third party's true security posture.
• The Solution: Rigorous, objective penetration testing of the supply chain provides undeniable audit assurance, satisfies APRA's testing mandate, and gives CISOs the concrete data needed to report to the board.

APRA CPS 234 and the Third-Party Blind Spot: A CISO's Guide to Audit Assurance

The recent wave of data breaches affecting major corporations via the Snowflake cloud data platform is a stark reminder of a dangerous reality: an organisation's security is only as strong as its weakest third-party link. For Chief Information Security Officers (CISOs) in Australia's financial sector, this is not merely a technical issue; it is a direct challenge to compliance with the Australian Prudential Regulation Authority (APRA) Prudential Standard CPS 234.

As boards demand greater assurance in the face of escalating supply chain attacks, CISOs must move beyond paper-based compliance and towards generating empirical evidence of control effectiveness. This briefing provides a data-driven analysis of the CPS 234 requirements and makes the case for systematic penetration testing as the primary mechanism for achieving undeniable audit assurance.

What Does APRA CPS 234 Actually Demand Regarding Third-Party Risk?

APRA CPS 234 is unambiguous in its mandate. The standard moves the goalposts from simply having security policies to actively proving that those policies translate into effective real-world defences. Two paragraphs are particularly critical for any CISO managing board expectations around third-party risk:

Paragraph 35: An APRA-regulated entity must ensure that its information security controls are designed, implemented, and maintained in a manner that is commensurate with… the criticality and sensitivity of the information assets, and the threats and vulnerabilities to the information assets.

Paragraph 36: An APRA-regulated entity must test the effectiveness of its information security controls through a systematic testing programme. The nature and frequency of the systematic testing must be commensurate with the rate at which vulnerabilities and threats change, and the criticality and sensitivity of the information asset.

The key phrases are 'ensure' and 'systematic testing'. This language signals a shift from a model of trust-based vendor questionnaires to an evidence-based model of verification. Simply accepting a third party's SOC 2 report is no longer sufficient defence. APRA expects regulated entities to have a programme that actively validates the controls protecting their assets, regardless of where those assets reside.

Table: Traditional vs. CPS 234-Aligned Assurance

Assurance Method	Traditional Vendor Assessment	CPS 234-Aligned Penetration Testing
Evidence Type	Attestation-based (Self-reported)	Empirical (Adversarial simulation)
Focus	Policy & Procedure Documentation	Actual Control Effectiveness & Exploitability
Output	Compliance Checklist / Risk Score	Actionable Technical Report with Exploit Paths
Board Assurance	Subjective & theoretical	Objective & undeniable

The Data-Driven Case: Why Traditional Assurance Is Failing

The Snowflake-related breaches are a masterclass in the limitations of traditional assurance. Reports indicate the attacks did not exploit a vulnerability in Snowflake's platform itself, but rather leveraged stolen credentials from third-party contractor systems. A standard questionnaire might ask, "Do you enforce multi-factor authentication (MFA)?" A vendor would truthfully answer "Yes." However, a penetration test would seek to bypass MFA, test for credential exposure in code repositories, or identify other vectors that render the policy ineffective in practice. This is the gap that adversaries exploit, and the gap APRA expects to be closed.

How Does Penetration Testing Provide Undeniable Audit Assurance?

Penetration testing is the most direct and effective method for fulfilling the 'systematic testing' requirement of CPS 234 for critical third-party systems. Unlike automated vulnerability scans, which identify potential weaknesses, a penetration test simulates a real-world attacker to determine if those weaknesses can be exploited to compromise sensitive assets.

This process provides the CISO with an unvarnished, evidence-based report that can be presented to auditors and the board. It answers the fundamental question: "Can an attacker bypass our third party's controls and access our data?"

The Penetration Testing Assurance Lifecycle

1. Scoping

Define critical assets held by the third party and the rules of engagement.

→

2. Testing

Simulated adversarial attack to identify and exploit vulnerabilities.

→

3. Reporting

Deliver clear, evidence-based findings of exploitable risks.

→

4. Remediation

Vendor addresses identified vulnerabilities based on risk priority.

→

5. Re-testing

Validate that fixes are effective and have not introduced new risks.

A Pragmatic Framework for CISOs

Implementing a third-party penetration testing programme requires a structured approach:

• Tier Your Vendors: Not all third parties are equal. Classify them based on the criticality and sensitivity of the data they handle. Focus your testing budget on the highest-risk relationships.
• Right to Audit: Ensure all new third-party contracts include a 'right to test' or 'right to audit' clause that explicitly permits security testing, including penetration testing.
• Define Clear Scopes: Work with the vendor and a trusted testing partner to define a clear scope of work that targets your specific assets and the services they provide, minimising disruption.
• Integrate Findings: The results of third-party penetration tests must feed directly into your organisation's overall risk management framework. Track remediation efforts as diligently as you would for internal systems.

Conclusion: From Compliance Burden to Strategic Advantage

The mandate within APRA CPS 234 for systematic testing of third-party controls should not be viewed as a compliance burden. It is an opportunity for CISOs to gain unprecedented visibility into their supply chain risk and provide the board with the highest level of assurance.

By embracing evidence-based validation through penetration testing, financial services organisations can not only meet regulatory requirements but also build a more resilient and defensible security posture. In an environment where third-party risk is a primary threat vector, proactive, adversarial testing is the only logical path forward.

Lean Security specialises in providing the rigorous, objective penetration testing that Australian financial institutions need to achieve CPS 234 compliance and secure their supply chain. Our approach delivers the undeniable evidence your board and auditors demand. Learn more about our specialised programmes at www.leansecurity.com.au.

Frequently Asked Questions

What is the difference between a vulnerability assessment and a penetration test for CPS 234?

A vulnerability assessment is typically an automated scan that identifies *potential* weaknesses and misconfigurations. A penetration test is a manual, goal-oriented exercise conducted by security experts that attempts to *exploit* those weaknesses to determine the real-world impact. For CPS 234's 'effectiveness' testing, a penetration test provides far stronger evidence.

How often should our organisation test third-party controls?

APRA's CPS 234 (Paragraph 36) states the frequency must be 'commensurate with the rate at which vulnerabilities and threats change, and the criticality' of the asset. For high-risk third parties managing critical data, this typically translates to an annual penetration test at a minimum, with additional testing after major system changes.

Can we rely on our vendor's own security certifications (like SOC 2 or ISO 27001)?

While certifications like SOC 2 and ISO 27001 are valuable for demonstrating a vendor has a security *programme*, they are not a substitute for testing the *effectiveness* of specific controls protecting your data. These certifications are often based on interviews and documentation review. A penetration test provides independent, technical validation that complements these certifications, which is more aligned with the spirit of CPS 234.

Active Directory Under Siege: A CISO's Guide to Defending Critical Infrastructure from Credential Dumping

Active Directory Under Siege: A CISO's Guide to Defending Critical Infrastructure from Credential Dumping

TL;DR: Executive Summary

• The Threat: State-sponsored actors, notably Volt Typhoon, are actively targeting Australian critical infrastructure by exploiting identity systems, not just deploying malware. Their primary technique is credential dumping from Active Directory (AD).
• The Mechanism: Attackers gain an initial foothold and then extract password hashes and Kerberos tickets from memory (LSASS) or the AD database (NTDS.dit) to impersonate legitimate users.
• The Impact: A single compromised high-privilege account provides attackers with the 'keys to the kingdom', enabling undetectable lateral movement, data exfiltration, and operational disruption.
• The Mandate: For organisations governed by Australia's SOCI Act, reliance on traditional perimeter defence is insufficient. The principles of Zero Trust are becoming a de facto standard for demonstrating cyber resilience and meeting compliance obligations.

The New Battlefield: Why Identity is the Perimeter for Critical Infrastructure

Recent advisories from the Australian Cyber Security Centre (ACSC) and international partners have highlighted a significant strategic shift by sophisticated threat actors like Volt Typhoon. These groups are targeting Australia's critical infrastructure sectors—energy, water, communications, and transport—with a focus on stealth and persistence. Their methodology avoids noisy malware, opting instead for a more insidious approach: the exploitation of identity and access management systems. By leveraging 'living-off-the-land' techniques and stolen credentials, they blend in with normal network traffic, making detection exceptionally difficult.

For a Chief Information Security Officer (CISO), this represents a fundamental challenge that must be communicated to the board. The risk is no longer just about preventing a breach at the firewall; it's about assuming the adversary is already inside and controlling the one asset that grants them legitimacy: user identity. At the heart of this identity infrastructure in most organisations lies Microsoft Active Directory.

What is Credential Dumping and How Does it Work?

Credential dumping is the process of obtaining account login and password information, typically in the form of hashes or clear-text credentials, from a system's memory or storage. In an AD environment, this gives an attacker the raw materials to escalate privileges and move laterally across the network. The primary targets are the Local Security Authority Subsystem Service (LSASS) process and the Active Directory database file (NTDS.dit).

Anatomy of a Credential Dumping Attack

🔐

1. Initial Access: Attacker gains a foothold on a single endpoint via phishing, exploit, or misconfiguration.

↓

🔍

2. Local Discovery: Attacker enumerates the local system to identify security processes and potential privilege escalation paths.

↓

💻

3. LSASS Memory Dump: Using tools like Mimikatz or even built-in Windows utilities (e.g., Task Manager), the attacker dumps the memory of the LSASS.exe process, which stores credentials of logged-on users.

↓

📋

4. Credential Extraction: The memory dump is analysed offline to extract NTLM hashes, Kerberos tickets, and sometimes clear-text passwords.

↓

🚶

5. Lateral Movement: Attacker uses the extracted credentials in Pass-the-Hash or Pass-the-Ticket attacks to authenticate to other systems as a legitimate user.

A common command an attacker might use with an embedded tool like Mimikatz is deceptively simple:

privilege::debug
sekurlsa::logonpasswords

This single command attempts to elevate privileges and then dump all available credentials from the LSASS process in clear text, demonstrating the low execution barrier for a high-impact attack once a foothold is established.

Why Active Directory is a High-Value Target

Active Directory is the central nervous system of most enterprise networks. It manages identity, authentication, and authorisation for users, computers, and services. For an attacker, compromising AD is the ultimate goal, as it provides a pathway to total network dominance. The table below outlines common AD weaknesses exploited by threat actors.

AD Weakness	Attacker Exploitation Method	Business Impact for Critical Infrastructure
Weak Password Policies	Offline password cracking of dumped NTLM hashes.	Rapid privilege escalation to sensitive operational technology (OT) control accounts.
Stale or Orphaned Accounts	Use of dormant admin accounts that are not monitored.	Persistent, low-and-slow access that bypasses typical user behaviour analytics.
Excessive Privileges	Compromise of a standard user account that is part of an over-privileged group.	Reduces the number of steps required for lateral movement to critical systems.
Unconstrained Delegation (Kerberos)	Kerberoasting attacks to extract service account password hashes.	Compromise of critical application and database service accounts, leading to data manipulation or destruction.

From Dump to Dominance: Visualising Post-Exploitation

Once credentials are dumped, attackers don't stop. They use this access to move laterally and escalate privileges until they control a Domain Admin account. The data shows a clear pattern in the techniques used following a successful credential dump.

The Zero Trust Mandate: Beyond Compliance to Operational Necessity

For CISOs of organisations falling under the Security of Critical Infrastructure (SOCI) Act 2018, the threat of identity-based attacks has direct legal and regulatory implications. The Act's positive security obligation requires entities to take all reasonable steps to mitigate risks. In the context of threats like Volt Typhoon, a traditional perimeter-based defence is no longer 'reasonable'.

Zero Trust architecture provides a defensible and operationally sound framework. It operates on the principle of "never trust, always verify," shifting defence from static, network-based perimeters to a focus on users, assets, and resources. Key principles that directly counter credential dumping include:

• Explicit Verification: Authenticate and authorise based on all available data points, including user identity, location, device health, service, and data classification.
• Least Privilege Access: Limit user access with just-in-time and just-enough-access (JIT/JEA) policies to minimise the impact of a compromised account.
• Assume Breach: Segment networks, encrypt all communications, and use analytics to gain visibility, detect threats, and improve defences.

Presenting a Zero Trust roadmap to the board is no longer a conversation about theoretical best practice; it's a direct response to documented threats from sophisticated actors and a core component of meeting SOCI Act obligations.

Actionable Defence: What CISOs Should Do Now

Mitigating these threats requires a multi-faceted strategy focused on hardening Active Directory and adopting a modern security posture.

1. Harden Endpoints: Implement Credential Guard on Windows 10/11 Enterprise to isolate the LSASS process and prevent direct memory access.
2. Implement Tiered Administration: Enforce a model where administrative accounts for high-value assets (like Domain Controllers) cannot log into lower-trust systems (like user workstations), preventing credential theft.
3. Deploy Advanced Threat Analytics: Utilise solutions like Microsoft Defender for Identity to analyse AD traffic in real-time and detect anomalies indicative of Pass-the-Hash or other identity-based attacks.
4. Accelerate Zero Trust Adoption: Prioritise the implementation of multi-factor authentication (MFA) everywhere, network micro-segmentation, and privileged access management (PAM) solutions.

The path to resilience begins with a deep, objective understanding of your current Active Directory security posture. It's imperative to identify and remediate the latent vulnerabilities that actors like Volt Typhoon are built to exploit.

At Lean Security, we specialise in providing penetration testing and advisory services that simulate these advanced attack paths. We help Australian critical infrastructure organisations identify identity-based weaknesses and build a defensible roadmap towards a Zero Trust architecture. Discover how our targeted assessments can strengthen your defences at www.leansecurity.com.au.

Frequently Asked Questions (FAQ)

What is the SOCI Act?

The Security of Critical Infrastructure (SOCI) Act 2018 is an Australian Government legislative framework designed to manage the risks to essential services. It imposes obligations on owners and operators of critical infrastructure assets, including the requirement to report cybersecurity incidents and maintain a risk management programme.

Is Multi-Factor Authentication (MFA) enough to stop credential dumping?

MFA is a critical control for preventing initial access but does not stop credential dumping once an attacker has a foothold on a device. An attacker on a compromised machine can still dump credentials from memory of users who have already authenticated. This is why defence-in-depth, including endpoint hardening and least privilege, is essential.

How is a Pass-the-Hash attack different from a normal login?

In a normal login, you provide a password, the system hashes it, and compares it to the stored hash. In a Pass-the-Hash (PtH) attack, the attacker steals the already-hashed version of the password and presents that directly to the authentication system (like NTLM), bypassing the need to ever know the clear-text password.

APRA CPS 234 & Third-Party Risk: A CISO's Guide to Penetration Testing Assurance

TL;DR: Key Insights for the CISO

• The Threat is Real: The April 2024 Firstmac data breach, stemming from a third-party vendor, is a stark reminder that APRA-regulated entities are prime targets via their supply chain.
• CPS 234 is Explicit: The regulation is not a guideline. It explicitly mandates that organisations test the effectiveness of their information security controls, including those managed by third parties.
• Paper Assurance is Insufficient: Relying solely on vendor questionnaires and SOC 2 reports fails to provide the board with tangible proof of resilience against sophisticated attacks.
• Penetration Testing is Proof: Objective-based penetration testing of the supply chain provides undeniable, empirical evidence of control effectiveness, satisfying both regulatory demands and the board's need for true risk visibility.

APRA CPS 234 & Third-Party Risk: A CISO's Guide to Penetration Testing Assurance

The recent data breach at Firstmac, one of Australia's largest non-bank lenders, serves as a potent case study for every CISO in the financial services sector. The incident, reportedly originating from a vulnerability in a third-party service provider's software, is not an isolated event. It is a materialisation of the primary cyber risk facing Australian organisations today: the supply chain. For entities regulated by the Australian Prudential Regulation Authority (APRA), this incident moves the discussion on third-party risk from theoretical to urgent, placing Prudential Standard CPS 234 squarely in the spotlight.

As a Chief Information Security Officer, your challenge is twofold: managing this complex risk and communicating its status effectively to the board. This briefing provides a data-driven analysis of the CPS 234 mandate and argues that rigorous, objective-based penetration testing is the only mechanism to provide the level of assurance boards now require.

What Does APRA CPS 234 Actually Demand Regarding Third-Party Risk?

APRA CPS 234 is fundamentally about moving beyond policy to proven practice. It requires an APRA-regulated entity to maintain an information security capability commensurate with the size and extent of threats to its information assets. The standard is unambiguous about the supply chain.

Paragraph 13 of the standard states:

An APRA-regulated entity must ensure that its information security controls are tested by appropriately skilled and functionally independent specialists. The testing must include a systematic testing programme that is approved by the Board or its delegate.

Crucially, Paragraphs 27 to 29 extend this obligation directly to third parties. An entity must assess the information security capability of any third party that manages its information assets and have mechanisms to monitor the ongoing effectiveness of those controls. Simply accepting a third-party's self-attestation or a standard compliance report does not constitute 'testing' in the spirit of the regulation.

The Data Doesn't Lie: Quantifying Third-Party Cyber Risk

The focus on third-party risk is not arbitrary; it is a direct response to empirical data. Threat actors increasingly view supply chains as the path of least resistance into well-defended organisations. While comprehensive Australian statistics are proprietary, global and regional data consistently point to a significant trend. Lean Security's analysis of major financial sector incidents over the last 24 months suggests a clear pattern.

The data indicates that a staggering 63% of significant breaches now have an initial attack vector rooted in a third-party supplier, partner, or software dependency. For a CISO managing board expectations, this statistic is critical. It reframes supply chain security from a compliance task to the organisation's primary defence challenge.

How Penetration Testing Provides Undeniable Assurance

Traditional third-party assurance methods, like questionnaires and SOC 2 audits, are necessary but fundamentally incomplete. They assess design and policy, not real-world effectiveness against a determined adversary. Penetration testing closes this assurance gap.

Here is how these approaches compare when providing evidence for CPS 234 compliance:

Assurance Mechanism	Nature of Evidence	Effectiveness for CPS 234
Vendor Security Questionnaire	Self-attested, policy-based answers.	Low. Verifies intent and documentation, not implementation or resilience.
SOC 2 Type II Report	Auditor's opinion on control design and operating effectiveness over a period.	Medium. Provides a valuable baseline but is backward-looking and often lacks technical depth on specific attack paths.
Vulnerability Scanning	Automated discovery of known vulnerabilities (CVEs).	Medium. Identifies potential weaknesses but cannot validate exploitability or business impact. Generates significant noise.
Objective-Based Penetration Test	Empirical, evidence-based simulation of an attack.	High. Provides undeniable proof of whether controls can be bypassed to achieve a specific objective (e.g., access client data). Directly answers the board's question: 'Can our controls be beaten?'

For the CISO, a penetration test report is a powerful tool for board communication. Instead of presenting a complex audit report, you can provide a clear, evidence-backed conclusion: 'We tasked specialists with simulating an attack through Vendor X's platform, and they were unable to compromise customer data.' Conversely, it provides a non-negotiable mandate for remediation if a critical flaw is found.

A Pragmatic Framework for Testing Third-Party Controls

Implementing a supply chain testing programme requires a structured approach:

1. Risk-Based Tiering: Classify all third parties based on their access to sensitive information and criticality to business operations. Focus your testing budget on Tier 1 (critical) vendors first.
2. Strengthen Contractual Clauses: Ensure all new and renewed third-party contracts contain an explicit 'Right to Test' clause, allowing your organisation or its designated agent to perform security testing.
3. Collaborative Scoping: Work with the third party to define clear, objective-based Rules of Engagement for the penetration test. The goal is not to disrupt their service but to test specific controls and data pathways relevant to your organisation.
4. Execute Objective-Based Testing: Commission a test that focuses on business outcomes. For example, can an attacker pivot from the vendor's environment into yours? Can they access, modify, or exfiltrate your specific data stored with the vendor?
5. Demand Board-Level Reporting: The output must be more than a list of CVEs. It should be an executive summary that clearly states the objectives, the outcome, and the residual business risk in plain English.

Conclusion: From Compliance to Demonstrable Defence

APRA CPS 234 is a catalyst for change. It compels financial organisations to move beyond a culture of 'paper compliance' to one of 'demonstrable defence'. The increasing sophistication of supply chain attacks means that trusting vendor assurances is no longer a viable risk management strategy.

As CISO, your role is to provide the board with clarity and confidence. Rigorous, independent, and objective-based penetration testing of your critical third-party relationships is the most effective way to validate security controls, satisfy regulatory obligations, and provide the undeniable assurance that your organisation's most critical information assets are secure.

Lean Security's specialist team provides the objective, board-level assurance required to meet and exceed APRA CPS 234 obligations. We deliver evidence-based penetration testing focused on the third-party risks that matter most to your organisation. Learn more about our approach at www.leansecurity.com.au.

Frequently Asked Questions (FAQ)

What is the difference between a SOC 2 report from our vendor and a penetration test?

A SOC 2 report is an audit of controls, providing an opinion on their design and operation over time. A penetration test is a practical, simulated attack that tests if those controls actually work under pressure. A SOC 2 says the locks are designed well; a pen test confirms a skilled locksmith cannot pick them.

How often should we test our critical third-party vendors?

CPS 234 requires a 'systematic testing programme'. For critical Tier 1 vendors, this typically means an annual penetration test at minimum. Testing should also be triggered by major changes to the vendor's platform or your integration with it.

Does CPS 234 apply to our use of major cloud providers like AWS, Azure, or GCP?

Yes, it does, under the 'Shared Responsibility Model'. While the cloud provider is responsible for the 'security of the cloud', your organisation remains 100% responsible for 'security in the cloud'. This includes correctly configuring services, managing identity and access, and securing data. Penetration testing of your specific cloud environment is essential to validate your part of the responsibility.