In my last blog, I discussed the API discovery process (finding, inventorying, and gathering data from APIs), and I talked about how it is impossible to protect what you can’t see. In this blog, I look at the second pillar of the D.A.R.T. API Security Strategy: Analyze.
APIs are complex to analyze. The process involves more than searching for anomalies or exploits in API traffic. Much like the intrusion detection systems of the 1990s, the monitor-and-alert model is immature, produces far too many false positives, and requires more resources than most security teams have available. Additionally, simply monitoring the network traffic for abuse or anomalous behavior is a bit like suspecting there is a bomb and then waiting for it to blow up to confirm your suspicions.
Understanding the API security landscape in all its complexity requires parsing logs, ingesting catalog data, reviewing configurations, security testing, and so much more. The problem is many organizations have already developed and matured their agile CI/CD or SDLC processes. Trying to force security into those processes after the fact is akin to forcing the proverbial square peg into a round hole. And even organizations that have built security standards and compliance into their CI/CD processes will need to make sacrifices for the sake of business requirements.
The API production machine functions as an organic whole: as business requirements change, development teams make the necessary changes by releasing code, often in the form of APIs. Agile CI/CD processes speed up this development and deployment process, which means the business units expect more and in a shorter amount of time — often leading to shortcuts and tradeoffs. And therein lies the challenge. How do you empower the development team to maximize output without sacrificing too much security?
I emphasize “too much” because security is often the first sacrifice to be made. Consider the following: it’s three days before Black Friday and over 50% of the company’s revenue happens on Black Friday. Skip the review and sacrifice security for speed? Approved.
What does this mean from a practical perspective?
The point is, whether by accident or design, APIs are deployed every day with significant security issues. Only by thoroughly analyzing the API ecosystem can we identify serious issues such as misconfigured, misrouted, poorly authenticated, and unauthorized APIs.
Shift-left testing to find and resolve issues early on makes sense. (I’ve never met a professional software developer who wants to write easily hacked code.) But even if you assemble the best DevOps team; even if you employ the most skilled network architects, identity managers, and cybersecurity architects; and even if you invest in best-of-breed API gateways (and we highly recommend them) and web application firewalls, when you press the button to launch new code because “Black Friday is only three days out,” mistakes will be made.
Analysis makes it possible to live with those mistakes, but only if you can perform yours quicker than the bad guy, and still leave time for remediation. Remember, you want to find and defuse the bomb before it explodes. This is why analysis of the API landscape must be automated, repeatable, and actionable. Yes, it is important to identify misuse, abuse, and attacks on APIs, but this strategy is reactionary and will at some point be too late. A proactive strategy exposes vulnerabilities, misconfiguration issues, and changes before they can be exploited and provides an effective window for remediation to occur so the attack can’t happen in the first place.