In the rush to integrate, these lightly defended computer-to-computer portals allow rapid data transfer between systems to enrich and display data across your digital fabric. But the lightly defended part can allow vast vacuuming up of data by reverse engineering the API details and launching the siphon. Because an API-based data transfer is so rapid, there’s but little time to prevent very bad things happening quickly.
Here at the RSA Conference, several sessions and vendors have tried to get us to wrap our heads around how to plug these often ill-secured digital holes.
To protect your APIs, you have to find their vulnerabilities before they bad guys do. Once again, the same tools are used by attacker and defender alike. The difference is you are far more likely to be notified if your web app has a security issue than your public-facing API, although the latter can do at least as much damage.
While there is some overlap with traditional web application testing, APIs act different, and expect different forms of question and response present in machine-to-machine applications that are so prevalent these days.
For instance, APIs expect blocks of structured data that fits some interoperable standard that’s easily digestible by other computer systems. They also expect structured handshake authentication between computers, or sometimes little authentication at all.
An afterthought
In a room full of RSA attendees with lots of APIs out there, when asked how many knew they have fully secured them all, there was a general wandering to the door to go call the security team. That’s how this goes.
On the “fix and test as you build it” side of the equation, one vendor proposes baking in API dynamic testing during the software development cycle before anything gets deployed. With a nifty Docker container you can roll out that sees every API iteration your developers are working on and tests them as you go, that’s a good way to have confidence you’re not inadvertently building the next best backdoor.
How do the bad guys find insecure APIs? Quite frequently just reading the documentation. Baked into standard API interfaces is a file that sort of forms a directory service, outlining all the places you might look for secret stuff. In this way, scanners can automate recursively probing for data to slurp.
APIs don’t just face public networks either – they often sit at the core of a business, silently trading “trusted” information like statistics on HVAC systems for the building, but also offering lateral movement opportunities once bad guys break into your network. Vendors realize their product is only one part of the digital landscape at an organization and they have to be able to integrate with others, so they roll out an API to talk nice with the rest of the deployed technologies.
This also means internal security teams turn more of a naturally trusted eye toward this kind of traffic. But this is exactly the kind of access ransomware authors would love to get.
Also, since swarms of IoT devices are sprinkled around the enterprise these days, those devices open up APIs for things like software updates, data feeds and reporting functions to other nodes. In this way, a foothold can be gained through a vulnerability that can allow bad actors to start hopping from device to device.
The rapid proliferation of API calls from swarms of enterprise products represents a whole new way to think about what needs securing, and to ignore the very real, often unnoticed attack surface puts vast swaths of data at risk of being pumped in truckloads out the back, front, or side door with little time to notice, and less time to respond.
