“Digital transformation is a necessity, rather than an option.” This was a common realisation among businesses two years into the pandemic. As workers went remote, enterprises invested into technologies such as automation, video conferencing, and collaboration tools. Moreover, many have made the move from legacy solutions to cloud.

With the evolution of enterprise technology comes the parallel advancement of cyberthreats. As malicious actors raced to exploit vulnerabilities brought by last-minute digitalisation efforts, security remained to be a top concern among decision makers.

However, the biggest security threat of 2022 lies not on new and emerging technology, but on a familiar face that has been around for 15 to 20 years.

Karl Mattson, the Chief Information Security Officer of Noname Security, pointed out that the ubiquitous nature of the API, or application programming interface, makes it a very vulnerable entry point for cybercriminals.

“It’s hard to even think of a public cloud workload that doesn’t use APIs, that has its connective tissue for service-to-service communication. You have that sort of obvious digital transformation, which is the modernisation of the customer experience, and then you have the infrastructure side— both of those happening at the same time utilising APIs as the core technical building blocks,” Mattson said during a fireside chat entitled “API Security – Defending Against the Top Security Threat of 2022,” during the IT Security Frontiers 2022 online conference organised by Jicara Media.

“When businesses started to look at APIs as revenue streams, as a way to deliver entirely new sort of customer value, that’s when the security ramifications of APIs changed. Seeing at the early stages of a transformation, the degree to which they’re API-centric, really was the flag for me that I needed to have my head in API security— as a partner with those digitally-minded product and business leaders who are going in a new direction,” he added.

Because API is so prominent in enterprise tech, how can businesses shield themselves from the dangers posed by API’s very nature?

Act One: Protect the endpoint

To begin the process of tightening security controls around API, CISOs must make sure that the endpoints are well-protected.

“The end-user workstation is a good example. We protect that workstation with a stack of controls. There’s the patch level of the system, there’s the configuration, and there’s anti-malware or EDR, deployed on it. Then on the network layer, we have sort of a network IDS, IPS, with firewalls. And in APIs, just talking about runtime for a second, you really have multiple stacks of an equation that protect that endpoint, to ensure that it’s operating as intended. So when we look at the API endpoint, the two primary controllers that we think of are the web application firewall, and an API management gateway,” Mattson said.

Following the workstation endpoint is the API management plane.

“Authorisation, entitlements, authentication, and APIs are the cornerstone of security, and API is securing the identity and the authentication. And it is very common, of course, that the API gateway is where that policy is enforced,” he continued.

Last but not the least is the API endpoint itself, or the source code, which is the raw version or raw API as it is designed,” Mattson said.

“A web application firewall, and an API gateway, or API management plane— they’re only good if they’re used. We see a tremendous percentage of APIs that are not used at all, or an API gateway that is not used at all. So those controllers, when they’re absent, even if they could be effective, it’s a moot point. It’s sort of a game-over proposition,” Mattson said.

The implementation phase, however, is no walk in the park, especially if manpower is limited. How then can enterprises execute their API management plan despite such limitations?

“I know as a CISO, I can’t afford to hire 50 people to sit through change control boards. What I need to do is give my application security team or my infrastructure team an automated assist, to be able to automatically see changes coming in a development pipeline. The reason for that is so changes can be tested adequately, have automated outputs that validate checks performed against an open API spec, and then give that analyst the tools of observation, to see every API in the inventory, and to see every time it changes, and whether that change is consistent with what was expected coming through a code pipeline,” he elaborated.

Act Two: API synchronisation 

As with any other technology, when the modification of APIs does not align with the intended use case, the entire system becomes ripe for intrusion.

“A great example of that is when a developer publishes an API intending an authentication schema that is well designed and sound. However, when it’s deployed into production, the API gateways policy enforcement of that authentication is not aligned with the intent of the developer, so we have a configuration flaw,” Mattson said.

“If you’re dealing with an organisation of size – for example it’s a global corporation – when you’re talking about commonly tens of thousands of API endpoints using multiple gateways, multiple web application firewalls— you’re talking about complexity that even when a lot of the geometry around protecting APIs is well known, it would still be a luxury if the only thing that we were worried about is the most sophisticated behavioural models. But truly, most organisations are just grappling with the complexity of the challenge of configuration and asset discovery. That’s a big hill for a lot of organisations to climb,” he added.

Mattson further shared how Noname implements API security for one of its largest clients: “This particular customer has close to 100,000 APIs, and about 100 touchpoints. Those touchpoints, every time we touch that network, what we’re able to do then, is to give their security team the tools to identify the inventory and add it to the global inventory, see the inventory and immediately assess it for configuration quality and vulnerabilities.”

Act Three: Visibility

To further put their customers’ minds at ease, Mattson emphasised the importance of visibility and control over the entire API ecosystem.

“There’s a big sigh of relief with most of our customers to have the security team just have that pane of glass, or that visibility across the footprint, and know exactly where they stand. That’s the biggest challenge from an API perspective: the knowledge that I didn’t know exactly where I stood. We’re all used to assuming or carrying risk as security professionals. It’s not new that we know we don’t have a patch level up to date, for example. But it’s a different thing entirely, not to know what you don’t know. And that’s the kind of thing we can provide a large organisation with a wide diversity of geographies, a wide diversity of API endpoint types, or a wide diversity of gateway types— seeing that picture globally for the first time. And that makes a huge difference for the security team to then just make rational, informed choices about where to deploy resources,” he concluded.