We’ve been cranking it out, haven’t we? Generating cool new toys for the business, creating new infrastructure to host those new toys and trying our best to secure all this new stuff while maintaining both our sanity and our cadence. And we’re doing it. Kind of.
One thing we’re naturally lagging behind on is security. While we don’t purposely shortchange security in our DevOps processes these days, it always takes a bit to figure out the best way to secure new technologies after they’re implemented. And we’re implementing a ton of new technologies. So our security staff (and increasingly, DevOps/SRE teams) is rushing to play catch-up. One area where this is screamingly apparent is APIs. We’re spewing them across the organization, often without cataloging or responsibility. This makes sense, as in many cases, the API is just an evolution of the function call. “I need a service, it is a good generic service, let me throw it up and we can use it from wherever the client ends up deployed,” type of thing. The problem is that leaves a ton of attack surface not truly protected. Because without cataloging or responsibility, there is no way for security to know about many of these APIs.
API Scanning Technology
That brings us to today’s topic. If you haven’t done so yet, it is past time to look at API scanning technology. It comes standalone and bundled with pretty much any API security product on the market and is increasingly bundled with other development security or even development tools. And the whole point is to get a list of APIs. Oh, most commercial implementations do something with that list–include it in static testing, drive it into WAFs, whatever—but just having the ability to inventory what is running on your network is reason enough to stop doing less important stuff and figure out what your exposure is. And the tools make it easy. They come in two flavors, and we should consider both.
Static API Scanning
The first type digs through source code and API specs to come up with the list of what is supposed to be running on the network. The big weakness of this method is that it only knows what it is told. This is static API scanning.
Dynamic Scanning
The second watches network traffic for API calls and then documents them, possibly even generating API specs for you. The big weakness of this method is that it only discovers what is being accessed on the network while it is watching traffic. Currently, unaccessed APIs are not caught, nor are ones on unreachable networks. Unsurprisingly, this is dynamic scanning.
As usual, the two together are more powerful than apart. By implementing both technologies, an organization can work toward a hardcore comparison of what should be running on the network versus what is running on the network. This goes beyond detecting unreported APIs, it also means that zombie APIs or runtime drift can be discovered by comparing what is there to what should be there.
If you’re not doing this, consider adding it to the toolbox. Setup is not onerous, and the reports are lists of APIs and parameters that can be reviewed at leisure. Some commercial products that offer these two functionalities take it quite a way beyond list generation, and if comparisons are made, work hard to understand just how much each toolset can do.
And keep rocking it. We need more tools to lock down the new perimeter precisely because you and your team are tackling new technologies and platforms to better serve the business. We are increasingly seeing security tooling catch up with the broad selection now available, so go implement them.
