Organizations of all stripes are working hard to “shift left” with security and improve the security of code released to production. Security and DevOps teams are working together on initiatives spanning developer training, improved security awareness, additional code scanning technologies, penetration testing efforts, and bug bounty programs.
Such tactics have indeed helped organizations improve their security posture, but in APIs as in most applications development areas, improving security during build and initial deployment cannot provide the full answer. Security in production or runtime mode is still essential. Consider the number of high-profile API breaches and vulnerability disclosures at organizations including Uber, T-Mobile, Panera Bread, Verizon, Facebook, USPS, Google, and many others. We can assume that these organizations have sophisticated development practices, security-conscious developers, and tools to improve security at multiple steps along the development lifecycle – attackers still found a way in, and these companies ended up in the news.
It’s inevitable that gaps and vulnerabilities will make their way into production environments, no matter how much effort is put into security during the build and deploy phases. The following challenges help explain why:
Each API an organization creates has unique logic and therefore unique vulnerabilities. Most applications rely on a combination of APIs, increasing the mesh of logic. In addition, a variety of internal groups typically create the different APIs, adding more complexity to the business logic. These groups often make a range of assumptions about security, such as that another portion of the application has handled authorization, leaving gaps and creating points of exploitability.
Thanks to agile development practices such as CI/CD, APIs change frequently – in just weeks, days, or in some cases, hours. At today’s speed of development, no security testing in the build phase can capture 100% of coding gaps and vulnerabilities.
Just like any other software, APIs also contain zero-day vulnerabilities. Just like with any other zero-day, you may not know it’s there until it’s exploited and someone makes off with your data or wreaks havoc with your services. If you’re lucky, a researcher or your own testing efforts will eventually find zero-days, so developers can eliminate them, but often it’s an attacker who gets to them first. Worse yet, the open gap stays open until the dev team can provide a fix. Typically, it takes days or months before you’ll become aware that a zero-day exists in your API.
Teaching developers to be more security aware and to write more secure code is an ongoing effort. While developers continue to get smarter, the reality is that developers don’t think like attackers, and they never will. A developer builds for functionality and efficiency, thinking “How do I make this feature work?” An attacker looks for ways to get features to do unintended things, instead thinking, “What will happen if I do this?”
Most of the security mechanisms applied in development revolve around scanning code. Scanning tools help in certain areas but fall far short of providing full security. Note Gartner’s take on the demise of the RASP market in the 2020 Application Security Hype Cycle: “[RASP] has failed to live up to its potential because of the complexity of its interaction with both applications and the surrounding ecosystem…”
A major shortcoming of scanning tools is their dependence on signatures and configuration. Also, because of their expense, they are often deployed in a limited fashion, focusing only on primary applications. Signatures are often out of date, configuration is never perfect, and you won’t cover all your applications with scanning.
The biggest reason scanning won’t solve your API security challenge is that these tools provide very limited coverage across API vulnerabilities. As an example, Broken Object Level Authorization, the #1 vulnerability in the OWASP API Security Top 10, is not a vulnerability that code scanning will identify.
Just as with scanning tools, penetration testing and bug bounty programs provide only partial coverage in identifying API vulnerabilities and gaps. As with any security initiative, applying limitless time and budget will help you approach 100% coverage, but no customer has such a luxury. As a result, organizations must focus these programs on just their primary applications, leaving gaps.
DevOps teams dedicate significant time and effort to identify and eliminate gaps early in the development cycle, before releasing APIs into production. At a certain point, though, spending more time identifying, prioritizing, and remediating security gaps in pre-production stands in the way of rapid app dev practices and with API-based applications, many gaps do not surface until they’re in production. Organizations succeed when they combine security efforts across the release lifecycle to include pre-production, runtime, and post-production.
Our customers benefit from runtime protection to identify and stop attackers early during reconnaissance as they try to uncover and exploit zero-day vulnerabilities. In addition, details of an attacker’s reconnaissance efforts provide invaluable remediation insights for development teams to eliminate gaps in post-production. By essentially using attackers as penetration testers, developers clearly understand what in the API is vulnerable and how to eliminate the gap. As a result, development teams can more easily prioritize their remediation efforts, be more efficient in their remediation, and improve workflows. Remediation insights also improve secure development practices so developers release code with fewer gaps and vulnerabilities in the future.
Visit https://salt.security/demo/ to learn how Salt Security makes it safe for you to innovate by protecting your APIs.
Salt Security streamlines API security with automated protection for TripActions
Salt Security named by CRN as a top emerging vendor in security for our leadership role in API security