Are You Taking APIs Seriously Yet?
We are 15 years into the great cloud migration, which started when people realized that virtualization, access controls, and enterprise service level agreements made it possible to put YOUR business applications on Somebody Else’s Computer. The cloud-enabled Netflix Streaming platform has caused a ground shift in Hollywood, cable television, and entertainment around the world. Yet, in all that time, I still see too many companies treating the lifeblood of the cloud architecture - API services and endpoints - as if they were just another Java web stack to be secured the old way. Because of this fifteen-year bias, most everyone has an API security problem that’s now a three-front problem - Undocumented old APIs, API-naive development security practices, and a lack of a forward-looking strategy for the future.
Unfortunately, there isn’t a perfect tool that can be bought and deployed to solve these problems. Getting a handle on API security requires a realization that API-driven cloud solutions are different from other types of software, a product-owner commitment to get a handle on the unseen vulnerabilities built into most naively-developed APIs, and some heavy lifting from development, testing, and security to tackle existing tech debt and quit adding new APIs to that pile.
Your steps for API Security success are to deal with the fires today while managing to do network scans to find undocumented “rogue APIs” so you’ll know where tomorrow’s fires will start burning. Get those APIs on board with a get-well plan with requirements and security controls that you’ll get from threat models you’ll start next month. Oh, and while this is happening, there’s still mobile, cloud, traditional web, and other development happening that needs to be secured as well.
While the best time to fix issues that appeared in the past is back in the past, all we have is the present. Many security professionals are either firefighters or show up to work every day in front of a whack-a-mole machine because dealing with issues of the past is a full-time job for the present. Instead, the path to a manageable present should be rooted in the future. While we all love to procrastinate, that’s what got us into our current messes, so instead, we have to start with a strategic vision for a safe and manageable future.
Getting out of the purely reactive API security stance is first a matter of putting out the fires before there are sparks. What I refer to as “rogue APIs” happens when developers create API interfaces and endpoints without getting documentation, security, and testing requirements from the security team before deploying their API-driven software. These are the APIs that are most likely to be playing with matches and will pop up during network scans and bug bounty requests in best cases, and incident reports in worst cases.
Dealing with rogue APIs is a two-part exercise - Find and Get Well. The finding part can be difficult as there are often specialized tooling packages that have to be installed, configured, and operated to fingerprint every host in the environment. If the host responds to HTTP or HTTPS calls, it might be an API server. Additional fingerprinting on HTTP hosts is required to verify that it offers an API interface and from there, the hunt for an owner is often performed cooperatively with IT or Ops.
After rogue APIs are found, they have to take their insecure, missing, or incomplete secure development and API documentation practices and “Get Well”. The goal of a get-well plan is to allow API service owners to get in line with the larger API security strategy; this may involve scheduling testing, code reviews, inventory documentation, and the not insignificant effort associated with properly documenting API endpoints. If that wasn’t enough, the devs may also need to work with security to provide test data for those endpoints to facilitate proper penetration testing.
After finding all of the rogue APIs in your environment, it’s time to build a vision for the future where all APIs in this Security Utopia (Greek for “no place” so let’s take that as encouraging) are properly documented, tested, configured with security features and libraries to handle vital functions such as authentication and authorization, and provided with actionable API-specific non-functional requirements. This is essential to getting developers from applying API-naive security practices to API-specific ones to their software.
Those documentation, testing, and security requirements, features, and API-specific NFRs are how security teams make security happen for their API development teams. Where do all those great things come from? Threat Modeling! At least the requirements and suggestions for security features do. By running a threat modeling exercise on a couple of representative APIs in your portfolio, you’ll have a pretty good idea of how to approach API security in general. A threat model works by breaking the design into its component parts, tracing attack paths from threats to assets, and listing security controls that could break those paths. After collecting controls from threat models of a few crown jewels, those can be added to a library of knowledge that is then shared with other teams who can re-use those features and patterns to secure their own APIs.
Unfortunately, I haven’t really found a good tool to solve everything API, so this is a job for Humans. Maybe you’ll need some extra help from humans who have already tackled API security. Bringing in external expertise is going to do way more than trying to crawl wikis or frantically copy notes from the OWASP web page. While that expert is there, they might also have time to grab some coffee for you. It’s a big job so put a fresh pot on.
There's always more words to spend on a topic like this one, but I've hit my budget for now. Stay secure, and never forget the humans.