End-to-End API Security

Doing security properly for application programming interfaces (APIs) is a process that goes well beyond security. It’s also about IT operational and architectural issues that drive security outcomes. To be successful, API security must be viewed as an end-to-end process covering the full software lifecycle. It starts with development but continues through runtime and end-of-life. 

Challenging a few old assumptions

API security forces us to challenge some old assumptions. One may assume, for example, that software development ends with the deployment of code into production. This is no longer true. Software development now outlives the basic process of writing code. Development is a continuous process embodied in the concept of Continuous Integration/Continuous Deployment (CI/CD). In tandem, software comes into existence through DevOps, which blends the previous sequential steps of software development (Dev) and deploying software into products by IT operations (Ops). 

Today, as soon as a piece of code gets deployed into production, the DevOps team is busy getting ready to deploy another iteration of the application. That next deployment could be an hour later. With DevOps, Dev is Ops, it seems. The operational side of the process is no longer distinguishable from the development side. Security for applications must therefore span the connected stages of Dev and Ops. 

Additionally, modern software is more than just code. It’s also a set of connections between components like microservices, APIs, code libraries, and the like. Keeping APIs secure means understanding how these connections work, where they are, and how they can be vulnerable to malicious actors. This requirement, too, transcends regular security practices to include operational tasks like creating API inventories and monitoring API traffic.

API security must span the entire SDLC and beyond

API security must be active at the development stage of an application’s life, at runtime, and beyond. Starting with development, developers may instruct applications to invoke API functionality through API calls or create APIs that expose the app’s functionality and data to other software applications. Both modes of API operation create risk exposure. 

API security risks occur for a variety of reasons, but many have to do with problems in API configuration that affect user authentication and authorization. A misconfigured API might allow an unknown user to access sensitive data. Alternatively, a mistake in configuration could enable a user to get data beyond what is permitted. Other configuration issues can allow an attacker to overload the API with calls and execute a denial of service (DoS) attack. 

API security testing can mitigate such API risks at the development stage. The testing needs to be specific to APIs, because general-purpose application testing will not catch issues like API misconfiguration. Instead, a dedicated API security testing suite needs to identify API vulnerabilities and facilitate their remediation before software gets deployed.

To work, API security testing has to be positioned early in the development process, known as the “shift left” approach. The testing suite must integrate with the CI/CD pipeline, as well. Otherwise, the security remediation process will be too cumbersome for DevOps team members to handle. 

At runtime, API security means blocking threats in real-time. This takes API security monitoring. An API security solution has to stay on top of API traffic and alert admins when it notices anomalous behavior or attack signatures. Alternatively, the solution may take the extra step to automatically block the API when it detects a threat. 

The need to inventory APIs

API runtime security is relatively straightforward. However, it only works if the API security solution knows where all the APIs are. To be secure, APIs must be subject to API posture management, which involves the process of API discovery. It’s impossible to defend an API that is invisible to the security solution, which is why APIs must be inventoried. API discovery is necessary, too, because API gateways and Web Application Firewalls (WAFs) do not automatically inventory all APIs in an environment, despite what people may think. 

The API discovery process inevitably leads to IT admins being surprised to find that their environments contain many “rogue,” “zombie” and “shadow” APIs. A rogue API is an API that somehow became lost over time. It may be an old version of an API that never got switched off. It might be an API exposed on a commercial packaged software application that no one knew about. A zombie API is a functioning API that is off the radar screen. Shadow APIs are created by people who take it upon themselves to build APIs, but don’t inform the IT department. 

All three types of undiscovered APIs generate risk exposure. Security policies cannot be applied to them because they are invisible. If they are not configured for security, and they are almost always misconfigured or lacking in patches, they will allow improper access to attackers. 

It can be challenging to know what to do with previously unknown APIs. If they are going to continue operating, they need to be brought into compliance with policies regarding configuration, authentication, and so forth. Shutting off a just-discovered API may be the best choice, but this can cause problems. For instance, if an earlier version of an API is still in use, despite being superseded by its replacement, turning it off could cause applications to break. Someone could get in trouble for making the decision to take the API offline. What’s needed is a toolset that gives admins the information they need to make the right decision.  

Putting the right tools to work

Executing API security on an end-to-end basis requires having the right tools. An effective end-to-end API security solution will be one that can handle API security testing, API runtime security, and API security posture management and inventorying. One needs to take a critical look at existing tooling, as most WAFs and API gateways do not cover development, testing, runtime monitoring, and inventorying.

The API security solution should also ideally operate in ways that don’t affect the network or API performance. For example, Noname API security solutions work by monitoring a copy of network traffic. They can spot API calls in this copied network traffic, identifying unknown APIs and security threats in the process. 

API security must cover all phases of an API’s life, from development through runtime and retirement. Security comes in part from processes that are not technically about security, such as API inventories. Because unknown APIs create risk exposure, identifying them makes their applications more secure. It’s an end-to-end proposition. The more complete the API security measures are, the more secure the entire environment will be.