Richard Bird
speaker
50 appearances
1 recordings
1 series
first heard Oct 2024
last heard Oct 2024
Richard Bird’s voice in public audio — every appearance, attributed to the second.
Trend
recordings per month · last 12 monthsNo recordings in the last 12 months.Older appearances are listed below; set an alert to hear about the next one.
Appearances
Those creepy crawlers are definitely the APIs that are engineered to exchange information without a tremendous amount of oversight. And this is really interesting because I think we're in a time right now where so much of the attention is being put on catalog and discovery, on creating an inventory or directory of all the APIs that we're exposed to.
That focus tends to orient people towards their old line technology providers where they go, oh, I've got a CDN. I've got a web application firewall. And they should know because all the APIs go over those channels. The estimate is somewhere around 30% of your API traffic in any large enterprise actually goes through those connectivity points. So now you've got 70% that you can't see.
There's your creepy crawlers. You've got 70% that are interacting with each other across these applications and are also finding or being built with pathways out of your organization that either bypass or just functionally ignore those web application firewall tools and those CDN tools. Now you've got this really interesting space where You don't know exactly what the API is doing.
You don't know exactly what it's supposed to be doing. You definitely don't understand how it's currently behaving. And in the meantime, information, revenue, reputation are leaking out of whatever access pathway that API is being directed to to push things out externally or receive things internally.
So the creepy crawlers are really all the things that you don't know about in your environment that are associated with APIs that are not in any kind of channel where you can see them.
There's two very precise ones that have received a lot of publicity. First of all, they result in tens of millions of customer records being lost. One is a very large, one of the largest mobile carriers in the world. And the other was a healthcare services organization.
And in both of those cases, I think this is such a powerful example of why so many people in the survey that we presented said their current technology is so ineffective in finding these API exploits. The reason that these particular breaches were successful was because at some point an API was taken out of production, an API that was already resident.
So now the argument that I'll catch that API in testing is completely irrelevant, right? These APIs were already there because there are already tens of thousands of APIs out in the wild that aren't going to go through this whole dev lifecycle thing. And those APIs in both of those cases, those APIs were taken out of production.
They were fixed, tuned, changed in some way, shape or form or another. And a developer put them back into production. And in doing so, there were no lifecycle management, no development lifecycle management practices that were put over that. It was like, hey, go fix that API and then go put it back in production.
And in both of those cases, the developers forgot to reinstate encryption on the endpoints that were associated with those APIs. So now you have this creepy crawler. You've got an API that you thought you knew what it was supposed to be doing, but it's now doing something it wasn't supposed to do.
expose a publicly open endpoint to a bot army that was fired off by bad actors who look for open API endpoints that are missing encryption. And then they found it. And as soon as they found it, they executed the moves that were necessary to go exfiltrate tens of millions of customer records, not just name and address, but like in the case of the mobile carrier, what your payment record was.
The reason why that's so important to the bad guys is because The most valuable thing on the dark web is a phone number with a confirmed live user on the end of it. And now all of that stuff was exposed that said, hey, you're a current customer and you pay regularly like you're supposed to. Bet you that's going to be somebody on the other end of that line that I can scam or that I can exploit.
The last thing that's most important about those two breach examples is no web application firewall, no CDN on the planet could catch that. And the reason is because that API looked like it was supposed to be doing what it was supposed to be doing. And the context of the information about the need and requirement for encryption to be on that endpoint simply did not exist in the system.
If you aren't controlling an API's encryption from an observation standpoint, you know it's supposed to have encryption, and it's been put back into production, and now it doesn't have encryption. If you're not controlling at that level of fine-grained granularity, there is no possible way for today's current technologies to catch those breaches. Wow. That's crazy is what that is. It is.
I can't disagree with you on that. And the one thing that I can tell you that I did see before was the mistakes that we made 20 years ago in forgetting to put encryption on an actual physical firewall and all the bad things that happened from that. So this isn't new. It's creepy crawlers, but it's a remake of a movie that we've seen before. It's a remake of The Living Dead.
It's a remake of any number of scary scenarios that we have seen in security before. The only difference may be volume and speed, but it doesn't make it different from a contextual standpoint. It just means that we've got to have technologies that can also operate at that kind of massive scale and that kind of speed in order to be successful against the bad guys.
There's an answer to that before technology. And the answer to that initially is the old seven steps answer, which is, hi, I'm Richard Bird and I have an API security problem. A, you have to admit that you have a problem to begin with.
And that sounds a bit trite, but the reality is in today's market, a large number of companies who have built the internet-enabled world that we are riding on today, they had on average nearly 18 or 19 years since the rise of those technologies to address the API space from a security standpoint. And they didn't. They didn't build the fine-grained capability. capabilities.
They didn't build a catalog and discovery capability that takes into account the entire organization's digital footprint, but only the things that moved across their channel. And that's resulted in a lot of people in leadership and companies today going, this solution provider I've had for the last eight or nine years or 10 years has said they do it.
And this other solution provider that we've worked with for years have said they can collect off of other gateways or WAF. That leads to the second piece when it comes to API security tooling.
Showing 21–40 of 50 · page 2 of 3
← Previous
Next →