Most organizations have seen exponential growth in API usage in the last few years, driven by a rapid increase in mobile applications, containers, serverless computing, microservices architectures and cloud adoption. The adoption of APIs is often synonymous with a move towards a more iterative, DevOps-centric development methodology, which can mean several things. In many cases, DevOps means decentralization of the development processes, allowing teams to roll out their own APIs and apps. DevOps also entails development taking on added security responsibility, also known as “shifting left.”
The “shift left” movement has brought about improvements in testing tools and adoption of security protocols earlier in the application lifecycle, yet developers are admittedly not security experts, with some expressing frustration with the amount of time spent on fixing code. Recent research shows that more than half (52 percent) of the developers surveyed said they would rather use this time to build new features and functionality, while 42 percent said freeing up this time would allow them to simply “do their job.”
In the end, the speed that developers can now roll out new APIs can lead to coding errors, which eventually get exposed as vulnerabilities, as shown in the numerous API-related security incidents in the past year. A balance must be struck where adequate shield right protection mechanisms are in place to support a more secure shift left adoption.
Shield Right Step 1: Runtime Visibility
When asked, most organizations will simply offer an estimate of “hundreds to thousands” of active APIs in their environment. Customer conversations combined with industry research supports the notion that organizations have no idea what the accurate picture actually is. Neither the security team nor the DevOps team can protect what they do not know exists. The first step towards securing APIs is to create an inventory of all APIs in production – all the endpoints that exist, what APIs they are serving and which team owns them.
Shield Right Step 2: Runtime Assessment
Security teams (and DevOps teams) can get overwhelmed if the inventory discovery uncovers many previously unknown APIs to protect. But not all APIs are created equal. Some APIs are informational, not posing any risk, while others may expose sensitive data – PII, PCI or PHI. Some APIs may not even be properly authenticated, while others may be prone to business logic attacks like account takeovers or scraping. The way to avoid being overwhelmed is to prioritize the API inventory based on their risk exposure.
In parallel, the security team can work with the development teams to document all discovered APIs using a common, language-agnostic standard, like the OpenAPI Specification or RAML. The same specification can then be used at runtime to detect deviations from the specification.
Shield Right Step 3: Runtime Protection
One other big realization as part of API security is that web security tools often fall short when it comes to API security. Most APIs are not vulnerable to traditional cross-site scripting and SQL injection attacks. RESTful APIs are designed not to use session cookies and do not follow SQL syntax to access the backend database. Instead of JavaScript, they use JSON or XML. There is no room to inject JavaScript and execute it on remote endpoints and collect endpoint signals used to detect automated attacks. So, traditional web application firewalls (WAFs) or bot prevention tools are ineffective in protecting the newly inventoried APIs. The result is a false sense of security that the traditional web security tools will protect their APIs.
Shifting Left While Shielding Right
Shift left adoption shows no signs of slowing down – the benefits are too great. A survey done by GitLab shows that roughly 25 percent of companies are in the DevOps “sweet spot” of three to five years of practice while another 37 percent are well on their way, with between one and three years of experience under their belts. Security teams continue to report that developers are not finding enough bugs at the earliest stages of development and are slow to prioritize fixing them. Over 42 percent said testing still happens too late in the life cycle, while 36 percent reported it was hard to understand, process, and fix any discovered vulnerabilities, and 31 percent found prioritizing vulnerability remediation an uphill battle.
Runtime security is a critical requirement for protecting your APIs against the ever-changing, ever-maturing API attacks that bad actors execute. With strong runtime security in place, your shift left adoption will be more successful and more importantly, more secure.
