Acrophax in 2017 suffered one of the worst data breaches in history. Adrian Sonabria is a security professional and researcher who's been taking a close look at what went wrong. Adrian, thank you for joining me today. Yeah, thanks for having me, Matthew.
I really am looking forward to talking about Acrophax. It seems like a great case study for others to learn from. If this is not too big a question, what would some of your top takeaways from the breach or the failures of Acrophax be for people in the information security field? Well, first of all, I think people need to spend more time really digging into case studies like this where we actually have all the details because it's incredibly rare that we get the level detail that we've gotten from Acrophax.
And typically, it only happens if there's class action lawsuits or federal investigations that by their nature end up making those documents public or getting them into the public domain, whether it's voluntarily or through the Freedom of Information Act, but defenders should be jumping on this opportunity and just digging through these documents with a fine tooth comb and seeing where they can apply some of these lessons to their own environments. And so it's a huge opportunity and nobody should just be, you know, gleaming over the headlines of something like this if they're a defender, if they're in a similar situation and they're worried about, you know, could this happen to us? It seems unusual to me that we've seen so much detail in depth. I mean, there was the GAO report, there was a report from House and Senate committees, there was the UK ICO privacy watchdog, they also put out a report tied to their fine against Acrophax.
There's a abundance of information here. Yeah, it's really, really useful. There's some good data in there and I wish we got this level of detail more often. It really helps us solidify some of the best practices and recommendations that we give.
And clearly, we can see that the industry is too focused on fixing problems with tools and not focused enough on leadership and on the people and processes parts of things. So one narrative that we've seen across many breaches where we get this level of detail is that even when companies own the tools, they rarely had them all set up and working correctly. And that was a big problem here in Acrophax. In fact, the way that they found out about this breach is they finally fixed one of these tools that had been, so I originally said broken and actually one of the people who developed this tool on Twitter came back and said, well, actually, it wasn't broken, it was working correctly.
They just didn't have it configured. They had it out of service. I didn't mean to say that your product was broken, but when it's not working, it's just the term that I used. So they had this SSL inspector that would decrypt traffic so that intrusion detection systems can look at that traffic and inspect it and alert you on suspicious or anomalous stuff and the cert expired and they let it sit expired for something like 18 months.
And once they got that fixed up, I think it actually needed several certificates to decrypt all the traffic it was inspecting. But the moment they hooked that back up, the alert started going off, the sirens started blaring and that's how they actually discovered the breach. So they had this investment in a tool that would have saved their bacon if they'd been using the tool correctly. Yeah.
And it's such a frustrating thing because it's like, well, you know, you did all the right things that you spent your budget on the right things clearly because it did tell you about the breach. But it only works if you believe it operational, if you take care of it, if you maintain this stuff, and clearly that's where we've got some pain. And there are also some issues of people knowing how to use the tools properly. And one of the things that fascinated me about Equifax is that in the media, like social media, you saw a lot of people just thinking, you know, Equifax was lazy.
They were slow to respond or they didn't bother to patch. But in fact, if you read the documents, they were really sweating this out. You know, when that stress vulnerability came out, they were aware of it. They had some big meetings.
They said, Hey, this is a big deal. Let's figure out if we've got struts and if the versions we have running are vulnerable. And they looked for it and they looked for it and they searched many different ways using many different tools. And it was there and it was vulnerable, but they failed to find it.
And part of the reason for that is the security team didn't really understand struts. They didn't understand the right ways to look for it and they didn't have any documentation of their own systems that they could search through and find struts that way. So there's no bill of materials, no software, bill of materials for their own products, for their own applications and what actually had struts in it and got hacked was an older legacy system. All the people that knew how it worked had left, sounds like from the report and nobody knew where struts was there.
So at one point, they actually run a tool to look for struts and they're one directory below where struts are sitting and they don't use the recursive flag on the tool. So it misses it. You know, they're only scanning the current directory and not the deeper directories from that one. You've talked about focusing more on the basics, but then there's the basic basics.
So what are some of the basic basics to take away here? For example, are you talking about asset discovery and management? So the problem with the basics is that they're not all that basic, they're tough. If you look at the critical security controls, there's a top 20 list of critical security controls, that's fairly useful as a general guidance for building out your security program and kind of judging how mature your company is in terms of cyber security.
And the first two on there, critical security control one is asset inventory and critical security control number two is software inventory because you can't do a great job at securing your stuff if you don't know what your stuff is comprised of. If you don't have a list of those assets and software, what's running on them, what versions are running on them and building these inventories is tough. I think back when this broke and they got in and they put all these web shells on different systems, part of the research I did is I wondered, well, how big is Equifax in terms of internet footprint and the tech service? Looked it up and found they have over 17,000 external IP addresses that they own.
Now that's not to say that they're actually running public external services on all 17,000 of them, but that's still a lot to inventory, to monitor, to take care of. It's not easy to do the basics once you scale up to these very, very large environments, but that's the job. You've got to find somebody to do it. These lessons that have been learned in terms of ensuring you have asset discovery, no world your systems are.
I feel like they have been learned and have they been forgotten. Yeah. So I think part of the problem here is that security is this layer that you could throw on top of anything. What companies expect their CISOs to do, it can be so broad, you know, if security or privacy comes up at all, they look down the table at the CISO and that's a lot to take care of because we're talking about things on the technical side, you know, you're interfacing with legal.
So dealing with PR type stuff, it's just such a broad set of things that, you know, coming in as a new CISO to an organization and cleaning up this kind of mess and trying to get a good security program in place. You're doing everything from training internal employees to make sure that they don't fall for phishing and BEC scams, business email compromised scams, and then dealing with technical issues like printers that are vulnerable and websites that are vulnerable and trying to work with the developers to write more secure code. So you're wearing so many hats and so many rolls that it's really easy to fall down in certain areas just because you don't have the staff or it's just it's difficult to visualize everything and to prioritize it and say, okay, you know, what's the most likely way that we're going to get hatier and is getting hacked even the worst thing that I'm worried about. It's a difficult problem to come into, security is very broad, which is why we have the frameworks like the top 20 critical security controls.
Where we see people fall down a lot is they're trying to outsource that to purchasing a tool or they're trying to outsource that to a third party organization that, you know, manages that for them, but you know, maybe doesn't do a great job of it. And what we end up doing or a lot of organizations end up doing is a very mediocre job at a lot of things instead of a very good job at the few things that really matter. And nobody agrees on what those things are that really matter. You know, so that's, you know, it's still a very young, you know, cybersecurity is, you know, maybe two and a half decades old, really.
So yeah, we're still trying to figure out what we're doing there. You know, it's not professionalized. We have some of these frameworks, but you know, there are best guesses at this point. So that's why we study these breaches.
That's why it's so important to get the details of these breaches. But we can come back and say, well, yeah, you know, maybe that's not a best practice or maybe we're missing a best practice or, you know, we need to, you know, rely on our priorities here. You've talked before about how there's really no natural highway traffic safety administration for data breaches, for example, but wouldn't that be a good thing if a government agency or some other organization was able to see the bigger picture and communicate some of those lessons learned to organizations, to sector by sector, which we don't have now, do we? No, no, we don't.
And it's a huge problem because, you know, we've got literally thousands of breaches occurring every year and we know almost nothing about them. You know, the information that's released, you know, to the media and to the public is just the bare details that were required to release. You know, there's this many, you know, customer accounts affected, you know, this meant here's the data that was lost. But we, you know, so we get details about the, you know, what was leaked, what was compromised, you know, whatever that data might be or whatever damages were done, you know, if it were ransomware or, you know, somebody just being destructive.
But the details we don't get are the ones that we need to learn from, you know, learning from other people's mistakes is generally preferable to having to make those same mistakes and learn from them yourself. And, you know, until we require some of those details to be released, you know, like the, you know, the organizations that study automobile crashes and why they happen, ship collisions and why they happen, you know, unlike those other industries where, you know, that are able to learn from each of these and put new rules into place to prevent them from happening in the future. That's just not happening here. We're seeing the same mistakes.
You know, if you go back and study a breach from 20 years ago, you know, there's some minor things different. But, you know, it can be like reading the same exact report, you know, over two decades of time and technology has changed a lot, but the attacks don't really have to change that much. You know, we were seeing extortion and, you know, those kinds of approaches in the 90s and we're still seeing it out where somebody takes over your company's resources and wants some money to give them back to you, stuff like that. So obviously digging into these reports, learning from them, this is the way forward if we don't want to be having the same discussion in other 20 years.
Yeah. And the positive note is those Equifax details are out there and this is something I want to spend more time on. I want to, I want to, I'm planning on a blog series that are just put some post mortems on breaches where we do have this level of detail. And we need somebody pushing for, you know, getting this level of detail more often without a federal investigation or, you know, class action lawsuit being necessary to bring it out.
Even if it's not shared with the general public, certainly defenders, you know, we need to know how these attacks happen so that we can prevent them. So that's, you know, the positive note is some of those details are out there and if you haven't dug into them, you know, you definitely need somebody on your team, somebody in your business that understands at a pretty deep level how Equifax happened, how target happened, how some of these different breaches occurred. Fantastic. Well, Adrian, thank you so much for your time insights today.
Yeah, my pleasure. I've been speaking with Adrian Sonabria, a security professional who's had a good hard look at what Equifax did wrong and what others should learn from that. I'm Matthew Schwartz with Information Security Media Group. Thank you very much for joining us.