Game Plan Execution: API Security and March Madness

A few months back we sat through an exercise to review API risk for a client. After looking through their inventory of all of APIs, someone raised the question “which API do you think would be most likely to be breached?”

The responses around the Zoom resulted in a list of pretty predictable hot targets: user logins, shopping cart, checkout.

But I couldn’t help but be a contrarian. I didn’t think the obvious endpoints would be the biggest risk, but rather something much less likely, the translation API.

The feedback all around was pretty incredulous, to say the least.  What damage could the translation API possibly do, after all? It’s just translating the words that are on the app for everyone to see plain as day.

In my experience, though, developers, security teams and even auditors will pay most attention to the APIs they know are high risk, and too often pay little attention to the ones that seemingly present the lowest.

This got me thinking about how much of what we do in cybersecurity is like the NCAA brackets. Sometimes the obvious APIs will be the ones that get the most play from hackers and provide them with the most wins. But sometimes it’s the API you never think about – that “eighth seed” API that out of nowhere becomes the means by which a bad actor can win big.

Much like Villanova over Georgetown in the 1985 championship – all it takes is a perfect run of field shots for the hacker to bypass even best-in-class defenses. Or, sometimes there’s no need for an attacker to dominate your defenses if they’re able to take a shot at an API completely in the clear. Like the translation API which is white-listed, and as such, bypasses security, giving bad actors a clean shot at the payload.

So, how do you protect yourself from an unlikely upset? (or even a likely one?) Game plan creation and execution is the best place to start.

Game awareness: Pay attention to the entire API landscape

I’ve got to say that if during that meeting I mentioned if I didn’t have the full API list in front of me, I don’t think I would have come up with the translation API. Because, without a reminder of all possible areas of exposure, your mind as a security professional will almost always think first of the obvious, high-value targets.

Keep in mind that visibility isn’t just about the list of APIs, though. You also need to see which APIs are being accessed, and where and how they’re being accessed and if they conform to spec/security standards.

Review the scouting reports: Continuously monitor APIs for security risk

Automating assessment of your API security risk is the next critical step because all it takes is one bad release to have an API go from low risk to high risk. You want to be sure that you’re able to flag APIs that don’t have adequate authentications, that may be passing PII or sensitive data without encryption, traffic coming from malicious IPs, or traffic that doesn’t reflect known good behavior.

Rimshots, not dunks. Implement strong controls and protections.

There’s lots of attention on ‘shift-left’ security, however, shifting-left assumes that you’ve already got strong protections in place on the right side, in runtime. Too often that’s not the case. With the ever-increasing threat of automated bot attacks, it’s critical that you can respond appropriately and quickly when your APIs are being targeted with a “drive from the right”, despite well-intentioned “left-side defenses”.

Maybe you run a zone defense, or maybe you choose to go bot-to-bot. Whichever path you take consider how that defense will impact the usability of your app and the customer experience, as there’s no sense in winning the play but losing the game and the customer.