Planning for a breach you might not see

Now, before we start, it’s worth noting that the first few paragraphs below might make you tempted to file this article under "e-commerce problem" or "old news" and just move on. But if you keep reading you’ll see that would be a mistake. OK, let’s go!

In March, researchers at the Dutch security firm Sansec found a payment skimmer on the online store of a car maker with revenues north of US$100 billion. Skimmers can be a bit ho-hum; but this one wasn't! Instead of sending stolen card data over the usual web requests, it used WebRTC, the peer-to-peer protocol browsers use for video calls.

That choice mattered, because the site's Content Security Policy (CSP), the control most organisations rely on to stop scripts talking to unauthorised servers, does not govern WebRTC. Nor will conventional web application firewalls, which are designed to guard the inbound HTTP path; the WebRTC connection runs outbound, browser to attacker, over a protocol the WAF was never in a position to inspect. That's a different kettle of slippery fish entirely!

The tactic changes; the gap does not

The interesting thing about the March attack is not WebRTC because exfiltration over a "legitimate" channel is an old category of problem, not a novelty. WebRTC was (in March) simply one of the newer data-exit doors.

And here’s why it’s not old news: In the weeks since that Sansec-reported attack, attackers have run developer supply-chain malware over WebRTC nodes, and researchers showed an AI sandbox could be tricked into leaking documents over DNS when its HTTP path was blocked. And that is worth dwelling on, because it tells you something about where to spend money for greatest effect.

Chasing channels, WebRTC or otherwise, is a race the defender cannot win, because prevention controls only cover what they were told about in advance. The only path to success is, perversely, to assume failure: Assume that something will eventually run and send data where it shouldn't, and to be confident that if (when) it does, we'll be able to see it happen, no matter what the exfiltration channel.

And that means we spend our money on strategies like:

• Integrity monitoring on sensitive pages, and,
  
• Anomaly detection on what leaves your network.

The questions that we can then answer are:

• "Did this page/site change from what we published?", and,
  
• "Is data leaving over a channel that is abnormal for our system?"

Those questions can, with planning, be answered without knowing the attacker's method in advance.

The legal turn

Here is where it stops being a technical preference and becomes a question of legal exposure.

In February 2026, the Federal Court ordered FIIG Securities to pay $2.5 million in civil penalties for contravening section 912A of the Corporations Act over a four-year period. It was the first civil penalty for cyber security failures under the general financial services licensee obligations.

The detail that matters for everyone, regulated or not, is what the Court was careful to say: The mere fact of a successful cyberattack does not by itself mean an organisation failed its obligations. In fact, Justice Derrington was explicit in noting that preventing every attack is all but impossible.

The finding against FIIG was not that it was breached. It was that it had not maintained adequate risk-management and monitoring systems, and had not consistently implemented the controls its own policies required. The duty the Court enforced was not "be impenetrable." It was "manage the risk and be able to detect and account for what happens." That is the same distinction the WebRTC story illustrates from the technical side: Prevention may eventually fail, and if it does, it is increasingly likely that the courts (or insurers, or other interested parties) will ask whether there were strategies in place to identify the failure and respond to it.

The principle is not confined to financial services. As several firms analysing the judgment noted, the inadequacies were treated as failures of general statutory duty, building on the earlier ASIC v RI Advice decision, not breaches of a bespoke cyber standard. Layered on top are the Notifiable Data Breaches scheme and the recent privacy reforms, under which an organisation that cannot tell what was taken faces the worst of both worlds: A notification obligation it cannot properly discharge, and no evidence that it did the reasonable things beforehand.

We continue to contend that it remains cheaper, and far more manageable, to spend your own money on your own terms than to have the bill set by an attacker and a court. Whether it's taking cardholder data or medical records, the skimmer whose activities you cannot see is increasingly likely to result in the breach that's much harder (both technically and legally) to defend.