Overcoming the Inertia of Assessing and Securing APIs
Traceable AI CSO Richard Bird on Best Practices for Fighting API-Based Attacks Tom Field (SecurityEditor) • August 21, 2023Large enterprises may have hundreds or thousands of APIs. Concerns over API vulnerabilities have been around for years, but most organizations outside of highly regulated industries such as banking have not taken the steps to understand the threats they face, said Richard Bird, CSO at Traceable.
See Also: Corelight's Brian Dye on NDR's Role in Defeating Ransomware
"There's a huge amount of inertia and friction to try and orient your organization toward solving for API issues," Bird said. "And yet, the bad actors are moving extremely quickly and discovering even more interesting, new ways to leverage APIs to do bad things."
For example, Bird said, he recently observed a bad actor employing API volumetric attacks, application hacks, DoS attacks and fraudulent account creation - all in one campaign, which succeeded in stealing data. "When you think about how security organizations are structured over the last 20 years, we are almost singularly focused on a plane of attack or a point of attack," he said.
In this video interview with Information Security Media Group at Black Hat USA 2023, Bird discussed:
- Why API vulnerabilities are so hard for large enterprises to tackle;
- How bad actors are exploiting APIs;
- Best practices for securing APIs.
Bird has nearly 30 years of experience in the cybersecurity and IT operations industry. He has been a CIO and a CISO, and he is the former global head of identity for JPMorgan Chase. Bird has held multiple C-level roles advising organizations of all sizes and served as the chief customer information officer for Ping Identity, building security solutions for the market as a chief product officer.
Transcript
This transcript has been edited and refined for clarity.
Tom Field: Hi there. I'm Tom Field. I'm senior vice president of editorial with Information Security Media Group. I'm delighted to be talking about API security and even more delighted to be talking with Richard Bird, chief security officer with Traceable AI. Richard, it is a pleasure to see you again.
Richard Bird: I always love hanging out and talking with you, Tom.
Field: API security - I would bring up this in conversation, maybe two years ago, three years ago. And the joke was always, if anyone gave you a number of how many APIs are there in the enterprise, you multiply that by 10. And you might get close. Here's security leaders talking about API security, talking like they're seriously addressing it. A question for you: is the needle moving positively?
Bird: I think the needle is definitely moving in the right direction. I think there's two problems. When I just started a year ago, at Traceable AI, I heard many of the same things. I don't have a problem. I've got a WAF, I got a gateway. I'm going to get to it. And now a year later, I hear a lot of ideation, a lot of strategy conversations about 'we need to do something, what are we going to do?' I think when we look at tangible moves on the needle, we're seeing it in highly regulated industries, specifically banking, and there's no banker in tech. It sometimes sounds a little frustrating coming from bankers to say that financial institutions lead the way, but it is the truth. They're the honeypot of the most valuable economic gain for the bad actors. Within the highly regulators, we're seeing heads of API security being stood up, we're seeing API security being talked about, in terms of which part of the organization should it be aligned to from a leadership standpoint, so definitely seeing movement, but we get out of the highly regulated, and we're seeing people kind of in the thinking, pondering and data collection state. Yet we're seeing even more and more exploits against the API attack surface that would suggest that people need to be thinking and moving and collecting data a little bit faster.
Field: That was my next question. Let's go to the other side of the battlefield. How would the cybercriminals take advantage of APIs as an attack vector?
Bird: Recently there was a conversation that I had about how hard it is for large enterprise security organizations to kind of shift the direction of the ship. Over 20+ years of this, what I call notionally the cybersecurity industrial complex, now, cybersecurity organizations have entrenched budgets and entrenched organizational structures and leadership. The comparison I've made recently, as it relates to the bad actors, is that we're trying to fight a war against a guerrilla army that has very small groups and units of people that can move quickly. We're trying to fight them with an entire brigade, and everybody knows Special Forces is much easier to move a unit than it is to move an entire army. That's what we're seeing is that there's a huge amount of inertia and friction, to try and orient your organization towards solving for API issues. And yet, the bad actors are moving extremely quickly and discovering even more interesting, new ways to leverage APIs to do bad things. There's one important finding that I've had in the last, I'd say, 90 days, that took me aback that I always like to say, like somebody is a hardcore security practitioner, when there are hacks that happen and you go, that's scary. But that's cool. We tend to, on the good guy side of the equation, still admire stuff that may rise to that level of sophistication or innovation.
Field: SolarWinds.
Bird: But what I saw recently is bad actors are using APIs to conduct combination attacks in the same campaign against a single target, meaning that they're using API volumetric attacks, API application DoS attacks, and then API, fraudulent account creation, three or four or five different methods. When you think about how security organizations are structured over the last 20 years, we are almost singularly focused on a plane of attack or a point of attack. So this idea of bad actors being able to use four, five, six, seven different types of attacks in one campaign and obfuscating or creating a diversion, and then being able to commit the actual crime that they're trying to execute under the covers. That's shocking, and I think that's going to be a big wake up call for most organizations in the next year.
Field: I want to follow up on that, because you pointed out to me that the threat actors are now using bots, residential proxies and patterns, authentication, authorization, understanding of vulnerabilities, all to conduct fraud. Where does that intersect with security teams and their responsibilities because fraud and security don't necessarily speak all the time?
Bird: That is an outstanding observation. Because it's even more complicated than that. I'm fortunate. A number of other companies recently that have been developed over the last couple of years, that are specifically in kind of the traditional fraud space, I have friends and colleagues and former bosses that are now running those companies, so I get an opportunity to talk with them. For me, coming out of 17 odd years of banking, I maintain my contacts and kind of the classic fraud organizations. But it's not just the security and fraud, haven't historically, kind of come together. We've seen some movement in that in the creation of chief security officers and then bringing fraud under. But that's relatively limited. That's very advanced large enterprises. But there's even more complications in that; fraud doesn't just touch fraud organizations, it doesn't just touch security organizations, it has implications for legal organizations around data privacy, it has implications for compliance, as we've seen with the Optus or probably the Medibank breach in Australia, where the government had to step in and say, 'we're going to have to do loss limits on the laws that we passed on how much you can be fined.' Because the amount of customer data that got access was so massive, like Medibank will be out of business. The mechanics of all of the siloed functions within organizations that have never kind of integrated together, are now faced with a world where all of these business functions are knit together with APIs. That lack of coordination right now is a capitalizable opportunity for the bad guys. The more that we're all standing around the old proverb of 'the six blind men and the elephant,' the more that we're standing around, and fraud is going well. That's not fraud, because it didn't involve a magnetic code swipe. The security people are going, 'fraud's not our business, that's the fraud guys.' The bad guys love that, because it's a bunch of who's on first base conversations, and we're definitely seeing that type of confusion happening when these API breaches and exploits are being executed.
Field: Bring it back to one of your favorite topics - identity. What needs to happen now at the identity layer, to be able to prevent fraud, and bolster one security posture?
Bird: I'm a bit of two minds on that question. Because I think there's a certain amount of me that is in the wait and see mode. But that wait and see mode is kind of also aligned to this big change that I made moving to API security, I'm always kind of like to say identity, softer side of security, softer side of seers, and identity is the gateway for the human element to interact with the digital world. There's a lot of emotion, a lot of tensions and frictions that are tied up in how you execute an identity strategy. Historically, though, for all the achievements that we had in the identity space to finally get single sign-on, and federation, and authentication in place, we distributed authorization to the wind, to the same application developers that we've distributed APIs to. The reason why I have two minds on kind of progressing what we need to do an identity in the spaces, because I do believe, and I'm saying this cautiously, because I am not often confused with an optimist. But I'm excited about the possibility of us finally, achieving fine grained access control. When people say like, why did you leave identity? I'm always like, no, I went to API security. That's going to be identity in the next 24 months. And more and more security practitioners are agreeing with me on that observation. What I'm thinking is possible, is this idea of finally putting a security set of guardrails around authorization, where all of the access not just to exponential business value is, but to discrete access by your mom, your dad, your grandparents, to these particular bank accounts, or these particular pieces of information, and then being able to secure those post authentication. The implications for a more secure world are big. Here's the thing. We just can't screw it up, like we screwed up all of the preceding things that we've done in security, right where we finally spent years sorting out authentication, and then you authenticate once and get access to everything, meaning all I got to do is be you and get your stuff. We can't end up with the same type of poor decisions being made, relative to securitizing in the authorization plane, because we finally have a technology solution that can do it. Let's try and do it right this time.
Field: Back to API security. Let's set aside the whole challenge of knowing how many APIs are in your enterprise. We know that's an issue. What are the other API security gaps you commonly see organizations trying to fill them?
Bird: One is a gap in, I guess, functional knowledge about how APIs are exploited. Beautiful thing about APIs; they are coded in such a way that you can divine what it is that we're built for. This allows us to do things like create automated documentation, because for the last 30 years more than, application developers notating their code has been a substantial problem. Being able to use the design specs of the actual read of that API to create documentation, we now know what it's supposed to do. The reason why that's so important and why there's a knowledge gap on how API exploits work is that bad actors are incredibly clever at making minor adjustments to those APIs over the course of a few days, of course of a few weeks, a couple months, this idea of a low and slow attack. Without a normative baseline capability to compare what an API should be doing to what is now being used for is what leads directly to the claw hammer analogy, which that which I've used frequently, which is the people that designed to hammer, a carpenter's hammer designed it for two functions, to drive nails and to pull out nails. Nobody ever expects a hammer to be used for any of those other purposes until the news broadcasts that somebody used one as a murder weapon. Now that is a dark analogy. But the truth is that a hammer was designed to do a thing however it can be used to do other things that was never intentionally designed for. And that kind of knowledge gap leads to arguments internally within enterprises about, well, API security is AppSec. But I can do an app DoS attack. I think that this is on the solutions industry to help the enterprise world understand this reality of abuse cases versus use cases, and they can be encompassed or embodied within same API. That is a knowledge gap that needs to be closed extremely quickly. That may also make improvements on moving that needle that we talked about at the beginning. As people understand this characteristic of APIs, they'll begin to recognize the threat and risk if they are within their organizations.
Field: Richard, what are you doing in your new role to help advance the cause of API security?
Bird: I think it's probably a repeat Nappa vacation and what I did kind of being a champion for identity, which I haven't stopped doing, by the way. I just try and split my work between two Don Quixote causes. But I spend a lot of time now speaking with a much broader and interesting market. An example being I've recently been asked to be a part of technology and economic trade missions, to a number of different countries. It's fun to travel. But the reality is it's fun to have conversations with people where maybe some of these security issues are manifesting in different ways within their countries, or their legal structures. There's a lot of that activity going on. For me, it's still keynotes and speaking and being a voice, and ultimately certainly my relationship with ISMG over the years not kind of simply repeating the company line, but being willing to be diplomatically contentious and try and move the conversation into healthy debate with a recognition that what we've been doing, regardless of the security domain API, or identity, or threat and vulnerability management, that the scoreboard is clearly showing that we're not getting it right yet. Let's be honest with each other, that we're not getting it right. Let's have an honest dialogue and debate about how we improve it. That's what I'm staying focused on.
Field: Diplomatically contentious. That's our next topic. Richard, thank you so much for your time, appreciate it.
Bird: Not a problem. Always enjoy it.
Field: Again, the topic's been API security. We just heard from Richard Bird. He's the chief security officer with Traceable AI. For Information Security Media Group, I'm Tom Field, thank you for giving us your time and attention.