Thank You Chicago!

Earlier this week we had the pleasure of hosting a regional API Security Summit in Chicago (well, actually in Lombard). These summits bring together the local cybersecurity community for  half-day of API Security-focused content, including expert speakers and panelists. While this isn’t the first time we’ve organized an event like this, it was memorable for the quality of content and participants. I won’t attempt to repeat all of the content here, but a summary might be useful for those who couldn’t attend in person.

5 Essential Lessons for Building and Securing APIs, Aaron Bedra, CTO 

Aaron Bedra provided clear guidance for practitioners who are responsible for APIs, encapsulated into 5 lessons: 

Lesson 1: Have a firewall

You don’t only need a traditional network firewall (though you need that too), but make sure that you have the controls in place to block unwanted traffic. Aaron advised that organizations “restrict the space to only the actors who are viable,” by blocking things like TOR exit nodes or specific geographies. Don’t ask your application to process traffic that isn’t valid. 

Lesson 2: Implement rate limiting

Related, make sure your application can degrade gracefully in the face of broken clients (or attackers). Rate limiting should be dynamic and responsive to the clients’ behavior. With APIs, we’re not talking about human beings, so don’t expect human behavior. 

Lesson 3: Record everything

If you don’t record or log everything, you can’t figure out what happened during an incident. It’s that simple. Yes, it costs money, but it’s a non-negotiable if you want to have viable forensics for an incident. 

Lesson 4: Implement strong authentication

“API keys are not authentication.” Aaron recommends using mutual TLS for authentication, and for providing context on the authenticated users. You can pack a lot of context into the certificate. 

Lesson 5: Always, always, always test

Finally, testing is a must, at every stage of development. And testing needs to be automated because “scalable security is automated security.”

Howard provided an insightful talk on why API security is a key concern for 2024 and beyond. The reality is that APIs are increasingly where the attackers are focusing. As Howard put it, “The API is the application, and the application is the business.” You can’t get much more critical than that. 

Howard also talked about the two types of attacks; Malformed and mal-intentioned. Malformed attacks are things like SQL injection or remote code execution; requests that are outside what the API is intended to handle. While there are certainly still ways for these attacks to be successful, by and large they are detectable. We’ve seen them before. Mal-intentioned attacks are those that leverage an APIs intended capabilities, but with malicious intent. Think about business-logic attacks, or scraping a API for data. These are valid use of an API in unintended ways. Mal-intentioned attacks are much harder to detect.  

Finally, Howard reminded everyone that the starting point for API security is discovery. You can’t protect what you don’t know about, and most organizations today don’t know about all their APIs. 

We also gathered a group of industry experts for a great panel discussion: ‍

Ed Yousfi, BISO at Gallagher Bassett;

Vinay Vishwanatha, Senior Principal, Product Security Architect at Sprinklr;

Sebastiaan Gybels, CISO & CIO at CoinFlip

The group affirmed that API Security is a top-of-mind challenge for CISOs, with plenty of references back to Howard’s talk about why. They also echoed Howard’s emphasis on discovery, pointing out that the unknown unknowns are a key concern. Organizations need to be able to answer the question “what APIs do I have?” And they need to include third-party APIs in the process. 

An interesting part of the discussion touched on the role of penetration testing in API security. There was general agreement that there’s an audit-gap when it comes to APIs.Compliance frameworks, and therefore auditors, don’t directly address APIs. Consequently, penetration tests done to meet compliance requirements don’t often include APIs in their scope. The panel agreed, however, that penetration tests aimed at improving security must include APIs.