Optus and Medibank — Australia's Wake-Up Call Already Happened

Australia's regulatory architecture has just discovered what its defensive architecture could not: that compliance and resilience are orthogonal properties, and that no amount of incident response will replace the structural elimination of the crown jewels themselves.

The Australian Reckoning: Two Years, Two Breaches, One Unlearned Lesson

On 1 June 2022, Optus confirmed a breach affecting 9.8 million customers—one of Australia's largest known data thefts. The attacker had obtained names, dates of birth, email addresses, and phone numbers via an unsecured API endpoint. The company later disclosed that customer identity documents (driver's licences and passport scans) were also accessed. The reputational and regulatory cost was severe: OAIC commenced investigations under the Privacy Act 1988, and the Australian Government committed to the Notifiable Data Breaches scheme enforcement. Optus paid A$146 million in customer compensation and faced sustained media scrutiny. Six months later, in October 2022, Medibank suffered a cascade breach affecting 9.9 million customers—personal health information, prescription details, claim history, and customer identifying data. The attacker exfiltrated records spanning a decade of customer medical activity. The Privacy Commissioner's office issued a scathing report; ASIC commenced inquiries into market disclosure failures. Medibank eventually paid A$420 million in settlement and remediation costs.

Both incidents followed a predictable post-breach arc: forensics teams, threat intelligence, new firewall rules, SIEM tuning, EDR deployments, external audits, board-level risk committees, and mandatory cybersecurity maturity frameworks. Both companies had cybersecurity teams, both had incident response retainers, both had cyber insurance. Neither prevented what regulators and customers alike now understood: that the data should never have been there at all—or if it was, not in a form that could be read if stolen.

The Australian Information Commissioner has since tightened expectations under the Privacy Act and reinforced the Notifiable Data Breaches scheme, making clear that the burden of proof now rests with entities to demonstrate not just that they breached—but that the breach was unavoidable and the data minimised. Yet three years on, Australian financial services firms, telcos, and healthcare operators have largely responded by buying more detection tools, hiring more analysts, and running more red-team exercises. This is not a defensive posture. It is a concession.

The Industry Response: Theatre Under Regulation

Australia's regulatory posture has sharpened. The Reserve Bank of Australia's Financial Sector (Resolution and Other Measures) Bill 2023 imposed mandatory reporting timelines. The NYDFS Cybersecurity Requirements for Financial Services Companies (23 NYCRR 500) became a de facto baseline even for non-US firms. ASIC and APRA have jointly signalled adoption of the APRA Prudential Standard CPS 234 Information Security, which formalises the concept of "critical infrastructure" and mandates resilience strategies rather than detection-centric roadmaps.

Yet in practice, Australian telcos and financial services firms have adopted the same remedial script seen globally after major breaches: consolidation of SIEM platforms (Splunk, Elastic), deployment of EDR solutions (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint), adoption of SOAR (Palo Alto Cortex, Automation Anywhere) for alert orchestration, and expansion of SOC headcount. The Australian Signals Directorate published Information Security Manual (ISM) guidance which, while rigorous on access controls and encryption in transit, remains silent on the architectural principle that should precede all others: the elimination of centralised, readable datasets.

Medibank's post-breach audit revealed that identity documents and medical records were stored in plaintext in database tables with inadequate field-level encryption, and that encryption keys were managed separately—but in the same infrastructure perimeter. When the attacker obtained database credentials via a compromised Medibank employee account (later attributed to a contractor with legacy VPN access), the decryption path was accessible. Optus's breach similarly revealed that API authentication was implemented via legacy HTTP Basic Auth tokens stored in configuration management systems without encryption at rest. Both companies had deployed firewalls and IDS/IPS systems; neither had implemented substrate-level guarantees that would render stolen credentials non-interpretable.

The regulatory response has been to demand visibility and audit trails—more logging, more SIEM indices, more retention—rather than to demand the architectural pivot that would make the logs irrelevant.

The Structural Failure: Detection Cannot Precede Denial

Here lies the fundamental misreading: the industry assumes that a breach is detectable before it is catastrophic. This assumption is false.

Optus's intrusion lasted weeks before discovery. Medibank's attackers maintained access for an estimated 8–10 weeks pre-exfiltration. Both organisations had endpoint detection and response (EDR) deployed in parts of their infrastructure. Neither detected the lateral movement or data staging. Why? Because EDR operates on the assumption that you know what "normal" looks like on your own network—a baseline that presumes visibility into endpoint behaviour, process hashes, and network IOCs. But if an attacker has obtained valid credentials (which both Optus and Medibank attackers did), EDR tuning becomes an exercise in false-positive suppression. The attacker uses the same tools as the administrator. The lateral movement looks like routine maintenance. The data exfiltration resembles scheduled backups.

This is not an EDR failure. This is an architectural failure—a failure to recognise that post-breach detection is only useful if the breach yields nothing of value. And yet the Australian regulatory and vendor ecosystem is doubling down on detection sophistication: expanding YARA and Sigma rule sets, tuning MITRE ATT&CK matrices, deploying threat hunting teams. All of these are legitimate security practices. None of them address the core failure: the data should not have been there.

Consider the regulatory implication under APRA CPS 234. The standard demands "resilience"—which in APRA's language means "the ability to continue to deliver critical functions during or after a cyber incident." But it does not mandate the architectural posture that would deliver this: the separation of the data plane (where information resides) from the control plane (where decisions are made), such that a breach of one does not compromise the other. Nor does it demand zero-knowledge substrate—the cryptographic principle that the data custodian themselves cannot access the plaintext without involvement from the data subject or an external party.

Reframing Resilience: Architecture Over Detection

PULSE's reading of Optus and Medibank is unambiguous: both firms operated under the assumption that resilience comes from detection-and-response, and both discovered—at catastrophic cost—that resilience comes from architecture.

The remedial pathway is not incremental. It requires three structural shifts:

First: Data minimisation as a substrate property, not a policy statement. This means designing systems such that personally identifiable information (PII), health information, financial account details, and identity documents are never held in a readable form by the organisation itself. Instead, data is held encrypted under a key that exists only in the possession of the subject (the customer) or in a separate trust domain—an external party that has no business relationship with the organisation and no credential overlap with the business network. This is the zero-knowledge substrate: you cannot steal what is not there.

Medibank stored patient health information encrypted with a key managed by Medibank. When the attacker obtained credentials with access to both the encrypted data and the key management system (which was in the same network perimeter), decryption was trivial. The alternative: patient records are encrypted under a key that exists only on the patient's device or in a separate, air-gapped key derivation service. The organisation holds ciphertext. A breach yields ciphertext.

Second: Control-plane and data-plane separation. The systems that allow a customer to access, retrieve, or use their information (the control plane) should operate independently of the systems that hold the information (the data plane). A breach of the control plane should not yield the data plane. This is not a network segmentation problem—every Australian telco and bank has DMZs and VLANs. It is a trust domain problem. The control plane (the API, the web application, the mobile app) should authenticate and authorise through a separate cryptographic assertion that does not require knowledge of the data itself. Only upon successful authorisation does the data plane decrypt the requested record—and it decrypts only the minimum necessary field, only for that transaction, and only under a cryptographic key the data plane itself did not choose.

Third: Adaptive adversarial posture, engineered into the substrate. Rather than waiting for detection systems to flag anomalies (which assumes you know what an anomaly looks like), the system should assume adversarial access and ensure that even with valid credentials, an attacker cannot perform bulk operations. Rate limiting is not enough—it is visible to the attacker and can be brute-forced. Instead, the substrate itself should enforce per-credential, per-transaction access policies that shift continuously. An attacker with valid credentials can read one record at a time, with a randomised delay, and with automatic expiration of the credential after 50 transactions. These are not configuration settings; they are cryptographic primitives built into the key derivation and transaction signing layer. Every access is signed by a separate key that expires. The credential that worked for Transaction 1 does not work for Transaction 2.

None of this is novel cryptography. All of it has been field-proven in aerospace, military, and financial infrastructure for decades. The architecture is known. It is simply absent from Australian financial services, telcos, and healthcare.

Regulatory Expectation and Architectural Gap

APRA's recent stress-testing guidance (released March 2024) now includes mandatory cyber resilience scenarios—including scenarios in which the primary data repository is assumed to be compromised. Yet there is no corresponding mandate that data repositories be designed to be uncompromising: i.e., that a breach yields noise, not intelligence.

The Privacy Act's Notifiable Data Breaches scheme now requires entities to notify the Privacy Commissioner if there is a "serious possibility" that the breach will result in serious harm. The onus is on the entity to demonstrate that the data breached was minimised and that access controls were sufficient to prevent the harm. Three years after Optus, no Australian telco has restructured its customer authentication system to eliminate plaintext PII. Three years after Medibank, no Australian health insurer has shifted medical records to customer-held encryption.

Instead, the regulatory and vendor response has been to standardise on frameworks like NIST CSF, ISO 27001, and threat intelligence sharing via ASD ISM. These are legitimate baseline controls. But they are not sufficient. They are not even necessary—an organisation can be fully NIST CSF compliant and still operate under the assumption that detection precedes denial.

The gap between what regulators now demand (resilience, critical infrastructure protection, post-breach capability) and what architecture actually delivers (the elimination of crown jewels from the attacker's reach) has widened. The Australian financial services and telco sector is now in the position of building higher walls around a moat that should never have existed.

The Path Forward: Substrate-Driven Resilience

For Australian organisations holding critical customer data—particularly in regulated sectors (APRA-supervised firms, ASD ISM critical infrastructure, NIS2-equivalent defence supply chain participants)—the question is no longer whether detection works. The question is whether the organisation is willing to redesign its data architecture such that a breach of infrastructure credentials yields zero intelligence.

This requires engagement with operators—architects, cryptographers, and infrastructure engineers—who understand that resilience is not a SIEM query. It is a substrate property. It is engineered into the data model, the key derivation system, the transaction layer, and the audit substrate. It cannot be added retrospectively. It must be designed in.

For qualified operators seeking to understand how sovereign, post-breach-resistant digital infrastructure is structured—and how regulatory requirements like APRA CPS 234 and the Privacy Act align with architectural rather than operational solutions—a technical briefing is available under executed Mutual NDA.