Imagine trying to protect your web application farm, while needing to integrate with all the different web servers’ backend stacks on a one-to-one basis. This requires a WAF that understands systems such as Nginx, Apache, IIS, and Tomcat. You will effectively start a project that will never end due to the complexities associated with protecting each backend stack. Moreover, you will be bogged down with logistics; rapidly protecting your applications and integrating one-to-one with your stack is practically impossible. This is not the standard operating procedure with Imperva. Our solution has evolved to simplify the process; our protective layer effectively secures your applications while fundamentally agnostic to your backend stack. In other words, there is no need to integrate one-to-one with the different web servers in the stack.

This scenario begs the question – why is the integration strategy for [API Security]() so complex? Most of today’s enterprise customers are too involved in the logistics of discovering their API endpoints. This process usually involves integrating with various layers of their network and [different API gateways](), which is a lot of effort for just API discovery. How can this process be complicated when APIs are fundamentally part of the application delivery stack?

The struggles associated with implementing API security have largely been proliferated with the help of pure-play API security vendors. These vendors struggle to find a way to seamlessly provide API Security without depending on other systems to provide them with the logs. To address the problem, vendors have forced organizations to integrate with various modalities, including API gateways, load balancers, and network aggregators, to have visibility into API data. This design philosophy, however, is flawed. The best place to get this information is to directly integrate at the choke point of all traffic to capture both application and API data.

Here are the essential points when developing an integration and operations strategy around API security:

1. There is no way to capture all API traffic without directly being in line of all your traffic. Organizations should follow the simple and efficient design philosophy and directly integrate at the choke points of their overall traffic.

2. If you are unable to capture your API traffic at the edge, then the next best option is an integration strategy that is not dependent on disparate modalities, such as API gateways. The service-mesh already provides you with the means to efficiently use inbuilt proxies to capture all your traffic, including API.

3. If you depend on direct API gateway integration to give you visibility into your shadow APIs from Shape IT, API discovery is effectively made redundant. Given that API gateways see all the traffic that is sent through it, with limited effort, you should be able to produce a list of all API endpoints and you should not require another unnecessary integration to do so.

## Shifting the design philosophy

Achieving visibility into API endpoints through discovery and classification should follow the same design philosophy as your application security. Begin with any internet-exposed APIs. This should be done by creating a seamless integration point at the edge of a network and application stack, to provide sufficient protection from bad actors.

Next, expand your security strategy to include internal APIs, also known as the East-West APIs. If you have a modern application stack that is built on a service-mesh, then the integration will be seamless. This integration can be set up through a proxy, such as Envoy in Kubernetes, which is built into the service-mesh.

Finally, remember that APIs have been around for decades. Don’t let a vendor trick you into thinking that they are the new exotic interface. APIs have always been part of application development (in some form) with the initial XML RFC, which facilitated SOAP published in 1998. While they have evolved to different versions, such as RESTful and GraphQL, you shouldn’t have to develop a new strategy that is completely detached from your overall application protection strategy. The best approach is using service providers that have API security built on top of existing application security layers. This approach reduces the headaches of integration, helps you to understand your risks, and provides a consolidated, efficient way to limit API exposure.

## Best practices to accelerate API security

To improve your ability to protect your exposed APIs, an outcome-driven design philosophy is important. This approach means you can achieve API security without overextending your team. Use the following best practices to identify solutions that will support that outcome.

**1: No code changes**

Vendors should not require any code change in order to secure your exposed APIs. When code changes are required within your Continuous Delivery and Continuous Integration (CI/CD) lifecycle to support a solution, it introduces unnecessary complexities. Code changes slow down the speed of the CI/CD in addition to introducing the risk that these changes will cause issues, or not be enough to support the API security product. Avoid solutions that require changes to your underlying code to achieve visibility into your APIs.

**2: Frictionless deployment**

Infrastructure and security teams should be able to implement a robust API security control without any dependency on developers. Collaboration between developers and security teams can be enhanced through a frictionless deployment model whereby the security team can provide the development team visibility into API endpoints through automatic discovery and classification. This approach includes providing developers with updated API specification files, as well as the option for additional code analysis during continuous integration and continuous delivery process (CI/CD).

**3: No compromise on real-time protection**

There should be no dependencies to protect exposed APIs in real-time. Near-real time or queuing jobs that are conducted through integration with other edge solutions are inadequate when protecting APIs. This approach is critical. Whenever an API security partner suggests that their solution will reduce your mean time to remediation, you should seek clarity to understand why protection is not provided in real-time on par with your application protection framework.

**4: Consolidate your application and API protection strategies**

Do not be fooled into thinking that you do not need a [Web Application Firewall]() (WAF) for API security. A direct integration with API gateway is not required to discover and protect your APIs. WAFs are not “outdated technologies” and are still invaluable in API protection. Look no further than the [OWASP API Security Top 10 vulnerabilities](); an enterprise WAF will provide protection for six out of these vulnerabilities. With a natively integrated API security service that is built on application security framework through a WAF, enterprise API endpoints can be rapidly protected by leveraging advanced WAF capabilities.

WAF is essential to develop an integrated protection through a [Web Application and API Protection]() (WAAP) Platform.

## What we do at Imperva

At Imperva, we provide a holistic approach to protecting critical Applications and APIs in real-time through our WAAP platform. Additionally, for customers that are beyond the edge, Imperva provides a solution to discover your APIs within your datacenter and protect them in real-time using our award winning WAF Gateway. This approach simplifies the pain of API Security for our global customers while also accelerating their time to achieving their goals.

Imperva leverages advanced capabilities within the stack to provide proactive controls in stopping attackers in the reconnaissance phase. For example, [Imperva’s Reputation and Behavior Intelligence]() engine provides accurate indications that an actor is nefarious, based on classification of the source IP & ASN, fingerprinting of the client application, and closely monitoring the behavior of the user during the session. These advanced techniques shift the responsibility of securing critical APIs from reactiveness response to anomalies, toward a proactive response strategy that automatically detects anomalies and responds to threats in real-time and without dependencies or reliance on other systems.

The post [Gain Control of Rapidly Securing Your Critical APIs Without Worrying About Your Backend Stack]() appeared first on [Blog]().Read More