Welcome to the KuppingerCole Analysts Chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor with KuppingerCole, and so is Jonathan Care. He is a lead analyst with KuppingerCole Analysts.
Hi, Jonathan. Good to have you.
Hello, Matthias. It's very good to be here again. Great to have you. And the background shows it, and the publication date shows it. This is the Halloween episode 2025. And really adequate for a Halloween episode, we want to talk about things that are scary. So we want to talk about real-life incidents and, much more importantly, what we, what our audience, what everybody can learn from that. So it's not only scaring, but it's really taking the right measures, implementing the right controls.
And we want to talk about an incident where you know much more than me about that, and we want to talk about the F5 incident. Maybe if you give us a short introduction into what happened at all. That's right, Matthias. So we've got a real Halloween story here. But there is, I think, a glimmer of hope at the end.
And it is, as you say, about F5. F5 is a networking giant based in Seattle. It's trusted by 48 out of the 1,450. And in August, they discovered a nightmare scenario. They discovered Chinese state-backed hackers living inside their systems for at least 12 months. This is not just another breach. This is a sophisticated supply chain attack that put hundreds of thousands of organizations at risk. So how did it happen? So do we have insight? Is there telemetry? Is there an analysis? Do we know in hindsight or retrospective what happened?
Well, of course, despite this being now a public incident, many details are still confidential. But here's what we do know. Here's what we can say with confidence publicly. The attackers have been identified as UNC5221. And that is the name for a China Nexus APT group. And APT is an Advanced Persistent Threat group. They deployed malware called BrickStorm. This allowed them to gain long-term persistent access to F5's big IP product development environment. Let's think about what that means. They weren't just in the network. They had access to the kitchen where the food is made.
And so over 12 months, they methodically exfiltrated portions of the big IP source code, details about undisclosed vulnerabilities that F5 was privately working on, and configuration settings for customer deployments. Those three key areas, three key data points, gave them the blueprints to attack over 680,000 big IP devices exposed on the public internet worldwide. Right. That's okay. We wanted to talk about scary things. That sounds scary. But these are pros. So when F5 realized where these attackers were inside the systems, how did they react? How did they respond to identifying this issue?
Well, again, it's very interesting to observe this from our position in the timeline now. F5 discovered the breach on August 9th this year. The U.S. Department of Justice delayed public disclosure while they assessed the damage, which I think is, again, notable that this was recognized as a high-impact issue. Then it finally went public on October the 15th, so only a few days ago.
CISA, America's cybersecurity agency, issued Emergency Directive 2601. This is only the third under the current administration in the USA, which, as we know, likes their executive orders. They ordered all federal agencies to patch immediately. One of the unfortunate consequences was what happened to F5's stock. So there was a financial impact in that the stock dropped 12% in a single day.
Which is, again, not only scary but a real damage. But also when you mentioned this period of time between F5 gets notified and the public gets notified or the public agencies get notified. So that must have happened something in between. I think that's cleaning up the kitchen where the food is made, right? That's really, yeah, fixing code and making sure that the vulnerable version is no longer the one that is spread to the devices out. And of course, one of the reasons that we've been careful about what we said as an analyst firm is we don't want to add to the heat. We wish to provide light.
Exactly. And indeed, there are some actionable insights, I think, that we can now draw and I'd like to share with the community, if that's okay. Absolutely. In the end, we do not want to scare. We want to make sure that we shed some light so the spider web goes away and the bat goes away on the window so that we really understand what you can do. First of all, the attribution, how clear is it who the actual actor was? So the analysis that it was a likely nation state actor that you've mentioned. It is clear.
And I think this is one of the things that we need to be aware of, is that nowadays the blur between, if I can call it civilian targets, so businesses and software developers, software users, and which is everybody, the attackers are not distinguishing between military or government targets and indeed commercial or civilian targets. So we are all a target and we are all software developers or software users. This is the nature of the world we live in now. Our world is software. And so the attribution has been made. It has been defined as this threat actor group, UNC-5221.
And so we can be fairly confident that a commercial organization has been attacked by a state-sponsored group, which means, again, we all need to include the possibility of a state-sponsored attacker attacking our infrastructure, looking at our attack surface, looking at what we have exposed. And indeed, these are things that we can take forward and draw some actual insight from. Exactly. Just what you said. I think that is, if we take that step back and say, OK, that was an incident. We need to look at this as analysts, as security pros. So what is, first of all, what is the impact assessment?
You just said the security posture. What does that mean?
Well, let me, if I may, let the impact, as you say, I think is fairly clear. Cross-code breached, the stock dropping 12% in a single day, and 680,000 devices on the internet being attacked. So I think the impact is quite clear. And indeed, the impact is something that if we are users of F5 big IP, we all can be hit by that impact. But as I say, I'd like to move forward from picking over the bones and say, well, this has happened. What can we learn from that?
That would be, if this notification goes out to government agencies, but also to the general public, that means all CISOs that consider themselves to be under attack need to react. So what would be immediate actions for a CISO to say, hey, we are endangered? Right. Thank you.
So, yes, let's look at that and let's see if we can draw some insights, which, as you say, CISOs, security practitioners, and indeed software development teams and network infrastructure teams can all draw from this. And I think the first thing is, as I said, we're all software environments. And of those software environments, the development environment are the crown jewels. If attackers can compromise where you build software, they can poison the well for everyone downstream.
So our dev environments, whether they are in-house or whether we have a software supply chain, we need to make sure those dev environments are treated with the same or greater security that we would apply to our production systems, which is an interesting change. The second thing I think that we can look at here is that critical development systems can no longer be part of a general network where everything is open to everyone. That flat network, even a segmented network, critical development systems has to actually move a step further.
And we are seeing, in Copenhagen Coal, that the community is calling for renewed focus on network segmentation. And even our most sensitive build and release systems must be air-gapped and should not touch the internet at all. The third thing that I think we see is that dwell time is the silent killer. And what do I mean by that?
Well, 12 months of undetected access. That's not a detection problem. It's a visibility problem. So it's not that these attackers were detected, but that the operations and security were not able to see. So we need continuous monitoring, behavioral analytics, and threat hunting, not just the traditional perimeter defenses that we've all been comfortable enacting. And then we go, well, we've got our perimeter, we are secure. We need to move beyond that.
We need to move to what we've been calling for for some time, which is that perimeter, the protective layer, detection, response are now clearly key to reduce that dwell time. The fourth insight that we can draw is that source code is the offensive advantage. If attackers have source code, they can conduct static analysis to find logical flaws and zero days at scale. Why at scale? Because this is an automated algorithmic process. It's the same process that our software suppliers should and can use to detect flaws in their code.
And of course, remember the thing about exploits, exploits are just bugs with a security impact. And so we need to ensure software supply chain security. It's no longer optional. It is an existential requirement. I think the fifth thing that I would call out here is that management interfaces must not be internet facing.
And again, this is something we've been calling out for a while, but we've been beaten back by the tide of convenience. Hey, it's so much easier for me if I can just tap into my management interface over the internet.
Well, of course you can, but then so can other people. The CISA directive has explicitly required government agencies to remove management interfaces from public internet access. We should all pay attention to that. It should be table stakes. It should be not even something you have to think about because it's widespread, but it is clearly a problem. So to you people listening to this podcast, if you have management interfaces that are internet accessible, please remove them from the internet forthwith.
And related to that, the sixth point that we can draw from this is that we need right now to be cognizant of our attack surface. One of the things that came clear is that those 680,000 big IP devices that were vulnerable were not immediately identifiable. So customers of F5 had to scramble to inventory all their devices. And so again, this is what we would consider fairly mundane, basic level stuff to maintain a security posture. And this reinforces if you do not maintain a real time asset inventory, you cannot expect to respond effectively when a breach like this hits.
Again, protect, detect, respond. So right already, we know that the response, any planning, any tabletop exercises are in fact redundant because they're not based on a realistic and accurate inventory of assets and therefore understanding the attack surface. And the seventh and most, I think, final point we can make is that vendor risk is your risk. I'll say that one more time. Vendor risk is your risk. You can do everything right. You can have a brilliant perimeter defense strategy. You can have a wonderful segmented network, and yet you can still get compromised through your vendors.
Third party risk management is now to the fore, including software. In fact, I would say most importantly, software supply chain. You need teeth in your third party risk management. Security questionnaires aren't enough. Procurement saying, oh yes, we asked to see so, and they were okay with it, isn't enough.
You need, as part of your procurement exercise, as part of your ongoing vendor management strategy to demand evidence of security controls, monitor for security breaches, and have incident response plans that account for software supply chain compromise. So there is a good reason why these third party risk management requirements are built into NIST 2, are built into DORA, into these new frameworks, because they demand for that. And many organizations are currently struggling with how to implement that.
If we need proof, and F5 is just an example for that, then that's not what we're aiming at to, as you said, pick the bones, because they are alive and kicking and they will be providing services. So that's not the issue. The question is, who is next and how do we realize what we need to do? So embedding that into governance frameworks, into our daily life, when it comes to defining our XDR, SOAR, SIEM system to be able to get the right information at the right time. I think that is what we actually need to take away from that, right? I think so.
And I think that, as you quite rightly say, the F5 breach is a wake-up call. It is the evidence, if we needed it, that these strategic security postures like NIST, like DORA, are essential. In the world we live in now, 2025, soon to be 2026, nation state actors don't need to break into every target individually. They don't need to break into every bank, every hospital, every tax department, in every local government institution. They just have to compromise the vendors that we all depend on and thereby turning our trust relationships into attack vectors.
And I think the question, Matthias, that we all have is not whether this will happen again. It's whether we, and to you listening to this podcast, you the listener, will you be ready when this happens again? So please don't go back to sleep.
Please, if there's anything that I can leave you with, this breach exemplifies why generative AI defense is important. Secure software supply chains are important. Vendor risk management is important. Attack surface management is important. These are critical pillars of your enterprise security strategy. And these topics are why we in Köppinger Toll are actively researching and providing insight and guidance to customers in these areas. So thank you, Jonathan. I think that sums it up really, really well. And there's not too much to add from my side.
So it's really a lesson to learn for all of us. It's not about a single service provider, a vendor. It's about us understanding what risks are out there and that our way of consuming services and delivering services just has changed and the supply chain is part thereof. So that is maybe the final takeaway. Before we close down, Jonathan, any final words that you would like to recommend to our audience? I think you should look at the research that we're publishing. We are shortly going to be publishing a leadership compass into generative AI defense.
We're also publishing in the new year, we'll be publishing a leadership compass on the topic of software supply chains and how to secure them. And I know my colleague Osman is working very hard on attack surface management. So we also obviously looking at the topic of vulnerability management in general. So as I say, if you are a Coupling Leak Hold member, then this research is available to you in our research library. And you can obviously book inquiry calls, myself and my analyst colleagues, should you wish.
And of course, we have our colleagues on the advisory team who are spinning up advisory offerings in these areas as well, which I think is quite exciting. Thank you very much. I can only recommend that as well. So it's really topical is there and we can support you there with research, with individual communication. Thanks again, Jonathan, for being my guest today. I'm looking forward to having you soon again. And next time, then we switch on the lights again and we remove the spiderwebs and everything that's around and then we will be after Halloween. Thank you again. Thanks for joining us.
