The banking, financial service, and insurance (BFSI) industry is among the most tightly regulated, especially when it comes to data privacy. As organisations within the sector transform their IT infrastructure to meet customer demands, the threat landscape has likewise expanded, introducing new vulnerabilities and threat actors.

While phishing scams and credential stuffing continue to persist, a new target for cybercriminals has emerged. The scary part is, most organisations are in the dark about it.

“In banking, of course, we typically are employing multi-factor authentication for customers logging into their banking portal (to thwart credential stuffing),” said Karl Mattson, Chief Information Security Officer, Noname Security, during a fireside chat entitled “API Security for Financial Services – Dealing with New Attack Surfaces”, which is part of the BFSI Frontiers 2022 online conference, organised by Jicara Media.

However, it is a different arena altogether when it comes to application programming interfaces (APIs).

“What we focus on is identification. But with APIs, it’s very important for us to also model the expected behaviour of the user, and a user usually being a machine identity, how is that identity usually being used? Can we statistically validate that the transaction or attempt is in line with historical patterns, and use machine learning to identify when those identities are being misused?,” the Noname CISO said.

Dealing with APIs

Although APIs have opened new revenue streams for plenty of verticals, many IT professionals don’t even know the exact number of APIs they have.

This is where the vulnerabilities begin to take shape.

“When we sponsored an independent research, and in particular focusing on man-in-the-middle attacks, we found that 54 out of the 55 mobile applications tested by our independent tester had easily found vulnerabilities in those APIs. So we are, as a security profession, behind in securing our API as well. It doesn’t take a sophisticated attacker right now to break through,” Mattson observed.

Despite the seeming disadvantage, the CISO said tools and strategies are available to empower enterprises against API vulnerabilities.

“We can put in the hands of the good guys the very robust tools that can really lock in an API footprint without hiring an army of consultants. We can change the equation to make it very difficult to compromise an API with the smart employment of automation,” Mattson said.

“An API is a relatively small software asset. It’s structured data, usually. So the number of things that can be done to circumvent an API’s controls is finite. We can model almost all of that behaviour with automation today. Placing that automation in the hands of a security team, we can empower that team in a very short period of time to be able to counter a very sophisticated, patient attacker,” he added.

Because IT and security teams, especially in the BFSI sector, already have a lot on their plate, recent developments in Noname Security’s labs include automating testing during the software development cycle, Mattson said.

“What we’re targeting is the ability of the security team to perform meaningful testing on APIs early in the development lifecycle that’s far less burdensome than it was before. Rather than source code being tossed over to the security team and penetration-tested, we can do all of that testing automated within the developers’ normal workflow. That should ease pressures on security teams to staff up, when they can employ a reasonably strategic, targeted use of technology that automates a key part of a process that’s usually manual,” he remarked.

Complex landscape

For security and application teams in a bank, for example, more often than not, they are only aware of the APIs that are public-facing, which are part of a mobile or web application, Mattson said.

“For every public-facing API, usually right behind it, there is a cluster of API calls that are triggered with invoking the first API. To retrieve a bank balance via API, for example, isn’t just one API call; it’s a whole series of API calls that happen internally to the network to retrieve the user data. So even though only one API is public, any of those APIs and that sequence of events could be compromised, that ultimately lead to data theft,” he explained.

Meanwhile, for organisations which are moving to cloud-based services, it is important to consider that their control plane is also being moved into an API-based one.

“A great example would be serverless functions or containers. You name the cloud workload, and API is the mechanism for controlling that workload. So when we have this mobile application discussion, that is usually the first thing in our heads, but we also have to keep in mind that we’re also creating this API sprawl in the infrastructure layer. It’s that infrastructure layer that also can easily be misconfigured. Whereas one of those APIs could be unauthenticated, it could be public-facing unintentionally. Those are the kinds of things that we need to be factoring in together to look at the whole of the API ecosystem,” Mattson noted.

The CISO further shared advice for organisations adopting a multi-cloud strategy.

“All the public clouds share a common denominator: that their core workloads all are utilising APIs as the primary mechanism for communication. But what you have is varying degrees of telemetry, and it’s not just for APIs. Just even thinking about vulnerabilities and access control, it’s hard to manage three different programs for three different clouds or four different clouds— it adds so much complexity. That’s why whether it’s API security or other clouds, categories of cloud security, if you’re going into a multi-cloud environment, it is sensible to have a control plane that is agnostic or inclusive of each of the clouds,” he suggested.

Mattson said that the following are included in the control plane:

• API security
• Access control
• Data security

“Each cloud individually has some really great features. But then you go to the next cloud in a multi-cloud environment. And then all your good work is for nothing, because you have to start over again in building a new stack for that cloud. We strongly believe that you can build an API security control plane that includes data centres and also multi-cloud environments. That gives the security team a single vantage point across the whole environment,” he concluded.