The ECB AI Cybersecurity Action Plan Needs an Egress Control

By October 31, significant euro area banks have to submit an ECB (European Central Bank) AI cybersecurity action plan to their supervisors. The request came in a July 7 letter from Claudia Buch, chair of the ECB's Supervisory Board, addressed to the CEOs of the institutions the ECB supervises directly. Each plan goes to the bank's Joint Supervisory Team.

Most of the commentary so far covers patching, testing, and identity. Illumio has made a solid case for segmentation, which the letter names outright. One question gets less attention: once an attacker is inside, what stops data from leaving?

What the Letter Asks For

The letter groups its requests into short-term and long-term measures. The short-term list has four items:

• Attack surface. Identify ICT assets, including third-party software and open-source components, then minimise and continuously monitor everything externally exposed. The letter calls out perimeter technologies, cloud environments and VPN connections to third parties.

• Patching. Accelerate vulnerability and patch management "at scale," with change processes that allow fast, risk-based fixes.

• Monitoring and detection. Strengthen "monitoring of application and access logs, network traffic and other indicators."

• Governance and supply chain. Check that budget, staffing and third-party risk management are up to the task.

The long-term list has two. One is defence-in-depth: "segmentation and, where feasible, micro-segmentation, together with the adoption of zero-trust principles." The other is operational resilience, including "exercises covering high-speed, high-volume attack scenarios." The letter also says the Digital Operational Resilience Act (DORA) requirements "remain highly relevant and valid."

Speed Changes What a Compromise Is Worth

The letter starts from the premise that AI systems are changing cybersecurity, and its first answer is to patch faster and at higher volume. That's necessary, but it can’t be the whole plan. Some exploit will always arrive before its patch does.

Palo Alto Networks' Unit 42 has described a case where AI compressed roughly two weeks of intrusion into under 10 hours. Whatever the entry point, an attacker who gets in then needs two things: a way to move, and a way to get something out. Segmentation deals with the first, but the second is the job of egress control.

Segmentation and Egress Control Do Different Jobs

Segmentation limits where an attacker can go inside the environment. Illumio's post on the letter recommends mapping connections, limiting east-west traffic and isolating compromised workloads, and it does that well. However, it doesn't cover outbound traffic.

Egress filtering limits where traffic can go once it leaves. A workload that's been compromised inside a well-segmented network can still open an outbound connection to an attacker's server, and if outbound traffic is allowed by default, nothing stops it. Egress control flips that default so a workload reaches approved destinations and nothing else.

The gap is wide in practice. Aviatrix's own estimate is that only 5 to 20% of enterprises have controls limiting which destinations a workload can communicate with.

The letter's monitoring item asks banks to strengthen monitoring of network traffic. Monitoring tells you a connection happened, while egress control decides whether it happens. A plan that only monitors will document the exfiltration accurately after it's finished.

Egress control has limits. It doesn't replace patching, identity or segmentation, and an allow-list can't stop an attacker who abuses a destination you've already approved. That's why the list should be narrow and built per workload, and why denied and unusual outbound attempts still need to be logged and reviewed.

Where It Fits in the Plan

Egress control slots into the letter's own structure without adding a new category:

• Attack surface. Default-deny outbound rules for workloads in cloud environments, including connections to third parties.

• Monitoring and detection. Denied outbound attempts become a high-signal alert source, because a workload that has never called an external host and suddenly tries to is worth a look.

• Defence-in-depth. Destination control sits alongside segmentation and Zero Trust. Segmentation restricts movement, Zero Trust verifies who is asking, and egress control restricts where the traffic ends up.

• Operational resilience. Include a test that exit paths are closed when the high-speed, high-volume scenarios the letter asks for are run.

What to Write in the Plan

Supervisors read plans for named controls, owners and dates, so the egress paragraph should have all three. A workable version: workloads that hold customer data may reach an approved list of external destinations and nothing else, the security team owns the list, denied outbound attempts are logged and reviewed on a fixed schedule, and the next resilience exercise tests whether an attacker inside a segment can get data out.

This is the layer Aviatrix works at: enforcement in the cloud network path, between workloads and everything outside them.

Filing on October 31 doesn't end the process. The ECB has said it will analyse submitted plans across institutions to spot industry trends and may hold workshops afterward. If your plan explains how an attacker gets stopped from moving and says nothing about what stops data from leaving, that's the paragraph to add before the 31st.