Endpoint security remains a constant challenge for organizations 25 to 30 years later. Even in the 90s when things were much simpler, understanding what was attached to a corporate network was a seemingly insurmountable task—and that was with good port security. Today, not only do organizations manage, maintain, and secure the devices they issue but also, so much business is conducted on personal devices operating within a network that is under constant change. Factor SaaS and cloud services into the mix, and it gets even more daunting. It’s no wonder that endpoint security and data protection remain a constant battle for most organizations today.
Understanding inventory and what should or should not be part of the corporate ecosystem, control over those endpoints, incident response, policy, compliance, malware … The list of challenges is at best constant, at worst, ever-growing. It’s not a new problem but one that remains difficult to solve. It seems that infrastructure and security teams are relegated to robust reactive measures (e.g., incident response) when proactive measures are undermined by careless or thoughtless users.
There is a certain level of irony in the fact that APIs (application programming interfaces) are often referred to as endpoints as well. Architecturally, APIs are designed to make software more extensible and offer flexibility to unique and custom use cases. Each API is defined as a contract, which accepts certain input and provides certain output. Most modern software leverages private APIs to proffer out-of-the-box functionality as well as public APIs, which users of the software may interact with to extend functionality or cater to their own specific use case.
Much like physical (or virtual) machines on a network, APIs represent a significant viable attack surface area for would-be attackers. What’s more, command and control over APIs, how they’re built, what security mechanisms they employ, the data they expose, and how and when they are released or sunset is an increasingly challenging problem that organizations are forced to deal with.
Security teams often aren’t advanced enough to look into what developers are deploying; documentation of APIs is often lacking; version control is often missing; and as a result, the underbelly of deployed applications is (unintentionally) exposed. Some security reports suggest that 40 to 50 percent of organizations have experienced an API breach in the last year, and research also suggests that an overwhelming volume of API traffic is malicious. Well-known companies like Peloton, LinkedIn, Experian, and John Deere have all dealt with the fallout of API security challenges.
For the developer audience that may be interested in common weaknesses of APIs and how they’re built insecurely, consider reviewing the OWASP API Security Project. For the security architects and risk managers, there are a couple of obvious first steps to gain ground on the API challenge.
First, you cannot protect, regulate, or inspect what you don’t know about. Discovery, much like infrastructure endpoint security, is a very critical first step. Second, once you know what’s out there, you need to gain an understanding of what type of data may be exposed by these APIs. APIs that expose sensitive data should be known, documented, and properly secured. Lastly, find out what exploitable weaknesses or vulnerabilities may be lurking in the implementation of that API (see OWASP API Security Project).
Seems easy, right?
Most security tooling for API security lives in runtime space. This means these tools can examine, in real-time, API calls and the data that these APIs are delivering. But in many cases, this is too late. These tools support a reactionary model that relies on stopping malicious actors just in time, if at all, and they are less capable of detecting data sensitivity concerns or vulnerabilities in the implementation of an API.
A better way to do API security is to shift left and look at the code developers are writing. With this approach, discovery, data sensitivity issues, and exploitable vulnerabilities in API code can be identified simply by interrogating code stored in a repository. All this can be done well before any APIs are deployed in a production environment. The opportunity to trap security issues well before they are a legitimate risk, and when they’re cheaper to fix, is significant and a game-changer in the API-security space.
API security tooling isn’t new, but it’s never been done the Checkmarx way. To learn more, check out Checkmarx API Security.