Integrating security into the API dev pipeline

Security cannot be an afterthought. To be effective, security must be incorporated into the full API development pipeline, from design through development, test, deployment and production.

Learn how to protect your APIs and applications, applying processes and tools to address API vulnerabilities beyond the OWASP Top 10, to keep your APIs, and their underlying services, safe.

Agenda

• Why security needs to be implemented across the API lifecycle
• How API protection is shifting from traditional to adaptive methods
• Multi-level API security
• Components of secure API delivery

Speakers:

• Rohit Andani, SME, F5 Cloud Services, https://www.linkedin.com/in/rohit-andani-27a53025/

• Jon Scheele, Founder & CEO, blue connector & Organiser, apiConnections, https://www.linkedin.com/in/scheelejon

Summary:

Gartner recently published research on the challenges that organisations are facing with APIs. Security is one of the biggest challenges for organizations as they develop and manage an API-based operation, closely followed by a lack of skills.

APIs have become a major medium for data breaches, and it is happening because of inadequate observability. Organisation struggle to identify how many API calls they are really receiving, and how these calls are being handled by their API gateway. And if it is really handled by the API gateway, what level of security protection do we have in order to cross validate that the API is sharing the right data that is authorised, and that requesters are adequately authenticated and data validated.

To address this, it's important to understand the API lifecycle framework and why it is important to include security. There are three different personas that are playing a major role in the API lifecycle. The first is the team responsible for building, testing and managing the code. The second persona is the DevOps; once the testing is completed, how do you really deploy this code in the production environment? And how do we really make sure the publishing of this code? Last but not least, there are the API Managers, who are actually doing the rest of the operational tasks. A key challenge for all these roles is to monitor the API throughout the lifecycle. This is hampered by a lack of observability.

Let's straighten out the API development lifecycle we saw earlier. Instead of deploying security only in the API gateway, at the end of the lifecycle, we want to "Shift Left" so that security is incorporated earlier in the cycle, and at each subsequent stage.

The OWASP Top 10 API vulnerabilities provide a great framework for protecting APIs through such things as rate limiting and authentication. But API is protection must not be limited to the OWASP Top 10. Hackers are well aware that organisations are now taking measures to protect against these vulnerabilities, so they are taking new approaches. We now regard OWASP Top 10 measures as traditional protection.

Because most of APIs are business-to-business (B2B), where you integrate your API's with another business, the next level is to modernise authentication.

And because hackers are now innovating, introducing new approaches, in order to protect those attacks, we need to have an adaptive security solution. We need a solution that with analyse the behaviour of API requests, to determine whether an attack is taking place, then adapt to respond to that attack. This requires a step change in observability.

A lot of organisations use a traditional architecture based on front-end systems such as web applications connecting to APIs protected by an Edge Gateway. And then the communication between these API's to the different services in the back-end is happening in plaintext or without a security channel. For example you may have a checkout service connecting with a payment service. As soon as I click on the checkout, I should redirect myself to the payment service. Each of these is considered an API endpoint and requires an API gateway and appropriate control. The Edge Gateway which is in this diagram, sitting somewhere in the left, is not adequate in order to provide the security control to backend APIs. Because this is not the capability of this gateway. This gateway is predominantly designed to handle the traffic which is coming from the front end towards your API infrastructure. But what happens when these APIs are talking to each other, the East West control? Most organizations lack the observability of what their apps are really doing, how many apps are really infected.

So this is the problem with the traditional architecture where the organization predominantly depends on a gateway level product in order to protect the API schemas.

Exposing an API on the internet is a very easy task. But it's a challenge to define what are the security criteria for these API's, which are published to the internet as well as for the partner ecosystem, because your partner may define a different set of policies, different sort of authentication, versus what a public network really needs. So you have to also tweak the product accordingly, in order to ensure that the public facing API's will get more production, and the partner ecosystem API's will get, of course, the same production, but with a different level of controls.

So multiple levels of security are needed to protect against these different levels of threat.

To deliver a secure API ecosystem requires monitoring of traffic between the components of the architecture, not just at the edge.

Configuring security for all the components of the architecture is done through definition files.

In this demo, we show how the solution analyses the behaviour of the API requests, and adapts to address new malicious attacks.

Watch the full recording of Rohit's presentation:

Resources

Securing Your Apps in Kubernetes with NGINX App Protect https://www.nginx.com/blog/securing-apps-in-kubernetes-nginx-app-protect/

Deploy a new version of the NGINX Plus Ingress Controller https://github.com/MattDierick/RTD-NGINX-App-Protect-UDF/blob/master/source/class4/module1/module1.rst