Planning for the Day Your Security Vendor Is Breached
On October 15, F5 disclosed that a nation-state threat actor had maintained long-term access to parts of its environment, including the development environment for its BIG-IP products and an engineering knowledge platform. The attackers took source code and information about vulnerabilities that F5 was working on but hadn’t yet disclosed. F5 said it found the intrusion in August and that U.S. authorities allowed a delay in public disclosure. The same day, CISA issued Emergency Directive 26-01, requiring federal agencies to inventory their F5 devices, apply the newly released updates and report back.
F5’s products sit in front of a very large share of enterprise applications. Load balancers, application delivery controllers and access gateways see traffic, terminate TLS and often authenticate users. An adversary with their source code and knowledge of unfixed bugs has a significant head start in finding ways in.
The immediate work
For F5 customers, the near-term steps are clear and mostly covered by the vendor’s and CISA’s guidance:
- inventory every BIG-IP device and software instance, physical, virtual and cloud
- apply the October updates, prioritizing devices with internet-facing management interfaces
- make sure management interfaces aren’t reachable from the internet
- replace devices that are past end of support, since they won’t receive fixes
- forward logs off the devices and watch for unusual administrative activity
That work should already be under way. The more interesting question is what this incident should change about how organizations choose and arrange security technology.
Vendor compromise is a design input
Architecture reviews usually treat a security product as a control: something that reduces risk. They rarely treat it as a component that could itself be compromised, by a flaw in its code or by an intrusion at the vendor. This incident is a reminder that both happen, and that the products most worth attacking are the ones with the most privileged position in the network.
Three design questions help account for that.
What does this product see and hold? A device that terminates TLS for customer-facing applications holds private keys and sees decrypted traffic. A device that authenticates remote users holds credentials or session tokens. The more a product holds, the more important it is to limit what an attacker could do with it.
What else would stop an attacker who controlled it? If a compromise of the gateway leads straight to the application servers with no further checks, the gateway is a single point of failure. Segmentation behind it, application-level authentication and monitoring that doesn’t depend on the gateway’s own logs all reduce that dependency.
How quickly could we respond? Organizations that could inventory their F5 estate in an hour were in a far better position this week than those that needed several days. The same applies to every critical security vendor in the environment.
Concentration is a trade-off, not a mistake
Consolidating on fewer vendors has real benefits: simpler operations, better integration and often lower cost. Over the past few years, many organizations have reduced their vendor count for good reasons. Concentration also means that one vendor’s bad week becomes your bad week across more of the environment.
There’s no universal right answer. What matters is making the trade-off deliberately. When evaluating platforms, consider:
- which of your critical paths would depend on the vendor, and whether any have an independent check
- how the vendor secures its own development and build environment, and what it has disclosed about past incidents
- how quickly it has historically shipped fixes for actively exploited flaws
- whether the product’s management plane can be fully isolated from the networks it protects
These questions belong in technology selection alongside features, performance and price.
What a good vendor response looks like
F5’s disclosure was detailed, came with fixes and was coordinated with government. That’s a reasonable benchmark. When you evaluate vendors, ask how they’d notify you of a compromise of their own environment, what information they’d share, and how they’d help you assess exposure. A vendor that has thought about those questions in advance is more likely to handle a real incident well.
Every major security vendor will face a serious incident at some point. Organizations that plan for it, in their architecture, their inventories and their vendor relationships, can absorb it as a hard week rather than a crisis.