How APISecOps Protects Against API Abuse

In this post, we'll talk about what API SecOps is, including the fundamentals of it and the personas involved. Then, we'll discuss how API, microservice, and policy lifecycles integrate to produce a secure service in production, and why collaboration and API-First Design are essential for APISecOps success.

Introduction

API security is a subject that's top of mind for many from builders up to the C-level — or it should be. Gartner reported API data breaches would be the most common attack vector in 2022, and the number of attacks is predicted to double by 2024.

Combine these API security concerns with the fact that organizations are steering toward multi-platform, hybrid cloud, and even multi-cloud solutions (see: CNCF 2021 Annual Report) and it's enough to make you wonder: how can we manage the sprawl of APIs in a secure and operationally efficient manner?

Essentially, we need an API management strategy that allows development, governance, and operations teams to work collaboratively to deliver business, security, and operational requirements together.

Because at the end of the day, a business needs the following:

• To have confidence that APIs running in production are secure and meet stakeholder requirements
• To have a process to publish those APIs that is efficient, resilient, and reliable
• To know that all APIs are accounted for and clearly documented

In other words, we need to shift towards an APISecOps practice.

What is APISecOps?

APISecOps is short for API design, security, and operations. The solution centers around the four core fundamentals:

• Centralization: Centralize API operations and inventory to a single control plane. Irrespective of cloud provider or platform, all APIs can be managed together.
• Governance: A governance team should be enabled to define custom policy-as-code to evaluate API specifications and make sure they meet security standards.
• API Design-First: Development teams should design the API upfront before any code is written in order to align with governance — and business stakeholders. This is key as it is the entry point to all the automation, and the documentation.
• GitOps: The API specification itself — which serves as documentation, governance, and API administration — should all be handled via GitOps best practices for speed, resiliency, and reliability in the process.

The diagram below provides the 10,000-foot view of an APISecOps solution.

An end-to-end API SecOps solution

The approach begins with API Design-First where the developer builds the API spec in Insomnia, Kong's API design and testing suite, using OpenAPI Spec (OAS) best practices and security standards defined by the business.

When the API spec is ready, it will be passed to an automated governance process driven by Kong's Inso CLI tooling. The Inso CLI is designed for API pipeline automation; it will lint the API spec and translate the spec directly to the Kong Declarative manifest (i.e., the decK manifest).

Once governance tests have been completed, and with the decK manifest in hand, the manifest will be automatically synced to Kong Konnect, the centralized API management platform, performed by Kong's decK CLI tool. The decK CLI is similarly designed for API pipeline automation and is used to manage Kong Konnect and Kong Gateway configuration declaratively.

The depiction above focuses on the end-to-end delivery of an API. It's easy to visualize how the three personas (Developers, Governance, and Operators) collaborate, and how the process aligns with the four fundamentals of APISecOps.

But in retrospect, every API has a corresponding microservice and policies. And all the lifecycles (API, Microservice, and Policy) need to work synchronously to deliver a secured service to production.

Let's dive a bit deeper into this topic to understand how and why these three lifecycles need to be integrated.

How API, microservice, and policy lifecycles integrate

If we were to envision how the APISecOps, DevOps, and even PolicyOps lifecycles integrate, it would look something like the diagram below.

PolicyOps

What's important to understand is that policies themselves need to have a lifecycle to build, test, and be approved by the governance leaders.

The PolicyOps lifecycle is critical because, as you can imagine, untested or unreviewed changes could harm the final product. Therefore, the governance team has a lifecycle to put policies into action and are incorporated into the APISecOps lifecycle when ready.

API SecOps

Here, we've expanded the view of APISecOps to include multiple stages of testing.

Let's dive more into the "Mocking" testing phase that is specifically highlighted. This is a great idea because we're giving stakeholders the opportunity to test, live, that the API behaves as expected from business, security, and operational angles. It provides confidence to move forward. It also increases productivity because the developers aren't wasting time building code that could be tossed out.

DevOps

DevOps begins when all stakeholders have confidence in the plan, which they've been able to see through the initial stages of APISecOps.

The development team is now going to build out the backend code. The code promotion scheme aligns with the approved API spec until finally the service as a whole, both the API spec and supporting code, are released to production.

Collaboration and API-First Design in API SecOps

What exactly is the takeaway from all of this? (No, the first takeaway isn't that our engineering organization has work to do.) It's that collaboration and API design-first are keys to success in APISecOps.

Collaboration

Teamwork, collaboration, whatever you want to call it — it's the first key to success. Because at the end of the day, Developers, Governance, and Operators all matter. Poor policies mean an insecure API. A poorly documented API spec means a lack of security. And poorly developed backend code follows suit: insecurity.

API First Design

The second takeaway is that the process begins with API Design-First.

Shifting toward an API Design-First approach may feel like an impediment at first. But from this vantage point, all teams can answer the questions that they value most:

• Governance: Is this API going to be secure when it's out in production?
• Business/Development: What is this API going to do, and can I find some documentation?
• Operations: Is this API going to operationally behave as expected, and is it documented?

Conclusion

In summary, in an APISecOps strategy, API Design-First is breaking down the barriers of communication and improving the productivity of the business as a whole.

We've covered how to integrate Governance, API Design-First, and GitOps into an APISecOps strategy. But how do we now deliver this when APIs are rapidly becoming scattered across multi-platform, hybrid cloud ecosystems? Check out this APISecOps tutorial as we discuss Centralization in the APISecOps Hybrid Cloud solution and how a Kong / Red Hat Openshift strategy comes into play.

Interested in getting a practical demo of APISecOps with Kong Konnect and ROSA? Check out the tutorial in the Kong APISecOps repository on GitHub.