Effective API Security is a Process, Not a Product

Gartner estimates that in 2021, APIs will account for 90% of the attack surface for web-enabled applications, and API abuse will become the most frequent attack vector by 2022. By some estimates, API traffic represents 83% of all web traffic. These APIs provide a direct on-ramp deep into the organization’s systems and critical data.

Breaches and data exfiltration can look like normal application behavior, meaning that current application security systems, such as Web Application Firewalls or SIEMs are insufficient to identify attacks. API security is far more complex than simply detecting run-time attacks, which may explain why many sophisticated organizations still fall victim. When it comes to API security, the current systems can fall short. It’s not just a case of buying a new tool that gives visibility into API inventory and behavior. Instead, API security should be thought of as a process that looks at how APIs can be discovered, misconfigurations identified, vulnerabilities mitigated, and new APIs tested.

Before we dive into the API security process, let’s take a step back and find out how we got here. After all, there have been plenty of new threat vectors in the past that the cybersecurity community was able to prevent. What makes API security so different that it requires a process, not just a product?

Why API Security is Urgent and Important

The following is what we see as  driving the adoption of API use and the resulting dramatic increase in the attack surface they represent:

• Digital transformation – Organizations are undertaking transformational strategies to meet customer expectations for experience and functionality. These transformations are often led by lines of business leadership, with varying degrees of participation by traditional IT. Often these projects are implemented rapidly in the face of competitive pressure or a commercial opportunity. Often, security implications are secondary and may not be considered at all, particularly when legacy security practices, technologies and assessment activities are bypassed in the name of expedient delivery.
• Cloud migration – Applications and infrastructure are moving to the public cloud at an increasing pace. While security features are readily available in the public cloud to limit public exposure and ensure configuration is sound, many organizations have not taken adequate measures to protect these assets.
• Microservices Applications – The move to microservices has changed the shape of the application attack surface. Monolithic applications are relatively static, with infrequent updates and a limited number of instances. Their perimeter is finite and known. A microservices-based application breaks that model, fragmenting the application into dozens or hundreds of smaller elements – containers, serverless functions, APIs, among others – each of which requires its own security. The odds just got worse of a single breach being successful.
• Agile development – The move to DevOps and agile software development has accelerated cycle times for new application deployment. Organizations with CI/CD pipelines are moving new code in short sprints of weeks, days, or even hours.  Many of these releases are made with limited oversight by the security team.  New APIs, for example, can be published without the security team’s knowledge; others can be left live even when they are no longer needed or in use. There has been much concern over so-called ‘rogue’ or shadow APIs on the network, but the reality is that even within the known APIs there are constant changes to the codebase, and misconfigurations can easily occur.

Each of these transitions has significant implications from a security perspective. The fact that all four are happening at once has overwhelmed security teams already hard-pressed with changes such as mobile adoption and the transition to remote work.

It would be great if API security vulnerabilities could be solved by a single control point, such as a WAF or API gateway.  However we just aren’t there yet, and there won’t be a magic API security box any time soon.

The API Security Strategy

API security is a process, not a product. It needs a holistic approach that will mitigate threats throughout the API delivery stack, not just at the API edge. The Noname API Security Platform can be used to drive a multi-faceted API security process that starts with testing in the API development stage and continues throughout the API lifecycle. The platform uses a combination of API testing tools, API discovery, continuous monitoring, and run-time threat mitigation. Process is crucial when it comes to API security.

Here are the four stages of the most advanced API Security methodology, which we have named D.A.R.T.:

• Discover – find all APIs across the environment, including rogue and shadow APIs.
• Analyze – detect API attacks, suspicious behavior, and misconfigurations.
• Remediate – prevent security breaches and data loss, and integrate with existing management solutions.
• Test – actively test APIs before production and after deployment.

Taking the Next Step

The API security threat is real and it can seem overwhelming. Security teams lack visibility into the extent of the problem, let alone have the means and methods to control exposure. The D.A.R.T. API Security methodology gives a framework for cybersecurity teams to approach the challenge in a structured manner. Curious how D.A.R.T. could benefit your organization and keep your APIs out of the headlines, request a demo.