The 3 pillars of API Security: Visibility, risk scoring, and enforcement

You can’t secure what you can’t see. And APIs are no exception. Whether your application uses internal APIs to manage interactions between microservices, external APIs to integrate with third-party services, or both, you need to be able to visualize your API architecture, identify risks within it and enforce security policies. 

This blog explains why API visualization and API security policy enforcement are critical elements of API security, and the roles they play in securing API calls.

API security in a nutshell

APIs are the glue binding the internal microservices within an application. They also integrate applications with third-party resources.In accomplishing both of these tasks, APIs can introduce a variety of security risks. Data shared via APIs can be stolen due to authentication and authorization issues or a buggy API service. The API itself could become an attack vector which threat actors use to compromise an application or access sensitive resources managed by the application. 

API security can be particularly challenging because APIs are designed to be more or less invisible by default. For example, you could be working with an application that calls another application, and that transition should be seamless to the end-user. In API security, often there is not a map detailing how these applications communicate.

The three steps to securing API calls: Visibility, scoring, and enforcement

Admins have to achieve the visibility necessary to monitor and enforce API security. This work boils down to three main steps:

Visibility

The first step to improving your API security policy is making API activity visible. Visibility means understanding which internal and external APIs an application is using, which resources those APIs are accessing and how APIs are securing data transfers. Applications don’t typically expose this information by default. In a best-case scenario, engineers may be able to sort through logs to trace what an API was doing after an incident has already occurred. But that approach, falls short of delivering the real-time visibility that teams need to detect and stop API security issues before they turn into breaches. That’s where API discovery and monitoring tools come in. 

As the image below shows, it’s possible to track API activity in real-time using tools like Cisco’s Panoptica: What makes Cisco’s Panoptica solution especially valuable is that understanding what APIs are doing doesn’t require special instrumentation or additional development efforts. Teams can take any application and trace internal and external API calls without requiring extra work from developers.

Risk scoring

Once you’ve discovered APIs, the next step in securing API calls is determining which APIs present a potential security risk, and how severe that risk is. This is achieved through API security scoring. By examining traces and (where supported) specifications like the OAPI spec, engineers can correlate risks to specific API calls -- an important advantage because a call like “POST /pets” may carry a different risk from “Get /pets/({petid})." 

Engineers can then generate granular alerts based on activity within API calls as the calls take place. For example, a team could configure different alerts for API calls that are used to send an email as compared to those that send an SMS. Alerts can be conditioned based on API security rules provided within specifications, making it easy to identify instances where API calls violate best practices from a security standpoint.

API security policy enforcement

With API visibility and scoring data, teams can establish policies that govern which API calls the gateway will permit, based on specific application components. By extension, engineers can reduce the attack surface by disallowing unnecessary API calls. 

For example, a microservice that handles internal database requests could be barred from communicating with external APIs that it would not have a legitimate reason to call. Enforcement also makes it possible to disable APIs that present security risks due to issues such as failure to adhere to specifications. With this enforcement in place, teams can prevent developers from using APIs that the organization hasn’t approved. They can also reduce the risk of attackers using insecure APIs to take control of applications.

API security in action

Let’s consider a payment API. This screenshot displays the results of the spec analysis: There are two possible methods to perform the payments:

• POST /PaymentAuth which is marked with critical risk
• POST /PaymentAuthNew which is marked with medium risk

In particular, POST /PaymentAuth is critical because of the following issue: Which means that the payment does not require authentication. We would like to prevent this call from being made. We could create a policy, such as the one below, that prevents all calls to the payment API from being made: Or we could be more granular and define a policy to block the specific critical call while allowing the others. As the traffic is encrypted, we should first to enable HTTPs traffic inspection. The resulting policy blocks only the specific critical call. In the following screenshot, we can see it is enforced by blocking the call to payment.

Better API security policy through the three pillars

In a perfect world, applications would never use insecure APIs internally or externally. But in real-life scenarios, it’s difficult to ascertain which APIs an application is using and how it’s using them, let alone ensure that those APIs are secure. To address these risks, developers and IT teams need tools that allow them to visualize, assess and manage API security risks in real-time. 

Rather than settling for post facto investigations that take place after a breach has occurred, teams can deploy tools like Cisco’s Panoptica to understand the API security risks they face, as well as to manage them based on granular, call-by-call enforcement rules. For more information or to access a free trial, visit Cisco Panoptica.