API Security: logic-based threats and how to combat them

The move away from the older, monolithic compute methodologies of the past towards the microservices-centric, API-based environments of the future is what characterises the modern enterprise. With digital transformation in everyone’s sights, organisations are rapidly adopting APIs for many good reasons.

APIs bring tremendous value to businesses in every sector. They’re great for promoting collaboration and partnership and allow a kind of ‘mashup mentality’ which has freed DevOps from more restrictive legacy architecture models. API traffic is growing exponentially at 30% year-on-year – accounting for an estimated 83% of web traffic today.

The security model for APIs, however, is problematic. In 2017, Gartner predicted APIs were going to become the number one attack vector by 2022, a prediction they had to revise in late 2021 as they saw the landscape explode far beyond expectations.

APIs – a novel attack surface

What are the issues facing CISOs trying to secure their APIs? Firstly, adoption is by far outpacing security. The rapid, iterative nature of API and endpoint development means code is routinely updated multiple times per week, often multiple times per day. This makes manual API security testing incredibly difficult.

Secondly, modern API attacks are mostly logic-based. They can’t be defended by traditional rules-based systems like WAFs (Web Application Firewalls), or gateways set up to monitor traditional threats, and legacy code scanning tools lack the context to chain together the paths leveraged in logic-based attacks. Traditional defences can’t protect businesses from this new attack vector.

How significant is this problem? Roughly 50% of all APIs in customer organisations are unmanaged. This is a huge blind spot and a major obstacle for security teams who find the proliferation of highly distributed compute environments often outpaces the ability to secure them.

Not hacking, exploiting inherent insecurities

You can’t defend what you can’t see, and when you change from monolithic to microservices-based architectures, we naturally expect microservices to do more than they ever have before – become more portable and scalable. This, potentially, makes applications more vulnerable, and materially changes the attack surface exposed to the outside world. This is why it’s important to look at governance tools – modern API gateways, for example, where you can enforce policies consistently across your API and mesh architectures. That’s not the end of it, though, APIs still expose application logic which makes them vulnerable to attack.

Most API attacks are not the familiar injection-based kind, and many aren’t hacks to begin with. A good example is the extraction of tens of millions of user records through the Facebook mobile app. In this instance, the assailant didn’t crack any encryption keys, didn’t hack a password, and didn’t attempt any SQL injection. The API logic allowed it and the third party took advantage of it – it was an unsanctioned usage of that API, but it wasn’t really a ‘hack’.

This happens a lot – attackers figure out the API and uncover inherent issues in the business logic. By exploiting failures such as broken object level authorization (BOLA) and broken functional level authorisation (BFLA), they don’t need to hack the APIs themselves. What we realise, therefore, is our defences must be different. Our WAFs and gateways can’t (on their own) defend against logic-based threats.

Adopting a holistic view to API security

What can we do to protect APIs before attacks damage our businesses? The problem is widespread, and still relatively new. The market is moving so quickly that Gartner recently modified its reference architecture to include API security as a dedicated layer in the stack. To give a sense of how many companies are on top of this issue, only 11% have a full-blown API security program in their organisations. So, it’s a relatively new challenge for everyone.

There are several elements that combine to solve API security problems. Firstly, it’s about gaining proper visibility of the traffic running through the stack. Starting with your traffic analysis and traffic inspection to watch what’s going on within the stack is critical. It’s not enough to observe traffic, though, you must go beyond just tracking inspection to really get into the code.

Code analysis provides the chance to not only do your standard SAS testing for API vulnerabilities, but also provides us with a useful lens through which to view third party APIs and endpoints being called from the code base. Wib’s Code Analyzer also creates a logic flow model to understand how software components interact with each other that legacy SAST tools miss. This is particularly important in large enterprises of distributed teams working on different products; closing these blind spots and applying different lenses to the data is essential. Wib, for example, provides a lens at the bottom of the VCR compliance analyser which brings visibility to a company’s compliance obligations. Managers have line of sight into which APIs serve PII, which are in scope for PCI and credit card compliance.

The third piece of the puzzle is attack simulation to identify real attacks against your APIs and endpoints, for two reasons. One, it finds current vulnerabilities and exposures you weren’t aware of. Two, it helps eliminate false positives before your security team or your DevOps team starts issuing a slew of remediation requests. So, how do we get there?

Practical Steps

In a microservices-based framework, application teams want to mitigate the complex authentication and authorization headache inherent in the model. API Gateways have been through a period of evolution in recent years, particularly as the adoption of Kubernetes has hastened. API Gateways, such as Solo.io’s Gloo Edge, allow companies to implement all these mechanisms at the Gateway event.

In a modern API gateway, teams can secure web applications with API keys or geo tokens and can put additional defences in place to prevent API abuse and block common threats. Gateways can also be used to expose threats in legacy VMs and bare metal – particularly important for many of the core datacentre systems still relied upon by the largest companies.

Finally, before selecting an API gateway, it’s worth thinking about whether adding a service mesh is part of the long-term plan. Choosing a gateway based on Envoy will make it significantly easier to adopt a service mesh (based on Envoy) – providing the capability to manage the complexities of modern, API-centric businesses. The adoption of Kubernetes and Istio in the enterprise in particular can make digital transformation simpler for a greater number of organisations.

The post API Security: logic-based threats and how to combat them appeared first on JAXenter.