For the financial industry, API blindness in the future will ensure that cybersecurity in the financial sector gets worse before it gets better. Gartner estimates it will continue to get worse before reaching a fever pitch in 2025, but if you ask me, it’s already concerning.
The security tools and the methodology by which we’ve implemented them over the last two decades simply aren’t built for the API-first world we’re living in. These tools were never built on understanding business logic and can’t tell us who’s doing what, via what interfaces, and to and from which ecosystems. They were never meant to, yet many CISOs incorrectly believe these old systems can protect new frontiers. As they say, a fish may be great, but ask it to climb a tree, and you’ll see it struggle.
Because of this, Gartner predicts that a frightening half of all API interfaces will be completely unmanaged by 2025. I believe that’s already the case; it’s shocking how many times I’ve spoken to a CISO or DevOps leader who either outright couldn’t tell me how many APIs they have or, worse still, how many admit to more than 80% of their APIs being unmanaged.
With all that in mind, here’s my advice on how the financial industry can weather the API storm coming in the near future.
Move fast, but move smartly
Banks and financial defenders will find themselves up against many security challenges in 2023 won’t be novel challenges but rather challenges that emerge from changing operating environments due to digital transformation.
Currently, APIs are in a unique position; they’re considered a niche in the security ecosystem, accounting for more attack surface than user interfaces (UIs) and 91% of today’s web traffic. Just as e-crime became ‘crime’, and e-fraud is now just ‘fraud’, one day API security will be called what it is – Modern Web Application Security. But until that happens, adopting APIs and microservices will continue to dramatically outstrip the defender’s ability to see what their company is exposed to, let alone protect it.
This type of shift is nothing new, and we know from the last thirty years that adoption will always outpace security. But until security catches up, financial institutions will find themselves between a rock and a hard place. Either they a) slow down in the name of security, leaving the competition to move forward, innovate, and rob them of new opportunities, or they b) throw caution to the wind, race ahead into the unknown, and hope for the best.
My advice? Be the second mouse. The first mouse races headlong into danger and gets the business end of a mousetrap. The third mouse moves too slowly and is cautious in its approach, but the cheese is gone by the time she gets there. The second mouse fares best.
Assume nothing, question everything
Just as you shouldn’t assume your current security suite is built to account for APIs, don’t make the similar mistake of thinking that your control procedures cover APIs, either. I’ve seen countless financial organisations engage in annual penetration testing as required by the FFIEC or other regulatory regimes, only to overlook a known threat such as Log4J.
Log4J, as an example, has been known for a year now, so there is no excuse to remain exposed to it. Yet, upon discovering it, many companies overlooked their APIs when battening the hatches. They don’t know their APIs are exposing it and don’t tell their penetration testers to enumerate or test their APIs.
Unfortunately, many financial organisations view penetration testing as vulnerability management, depending on them to find every weakness, but that isn’t the reality.
While penetration testing may include some discovery and attack surface mapping, by and large, penetration testers rely on the company hiring them to tell them the scope of the tests and only have a limited time to assess the provided scope.
For companies unaware of their entire API attack surface (which is already the majority and increasing), they aren’t providing APIs and endpoints to the penetration testers as part of the known scope, leaving these blind spots unassessed.
And just as we shouldn’t assume their crystal ball will give them the information you don’t ask for, you also shouldn’t believe they have the skill to deliver what you need. Many penetration testing companies today don’t have experience or appetite regarding APIs, and it’s up to you to question whether they’re the right partner for the job or if there’s a better, API-focused partner out there.
No air cover for bad API security – even if driven by regulatory mandate
API adoption is not only driven by competitive pressures but also by mandate – whether intentionally or not. Multiple regulatory challenges drive digital transformation and API adoption without explicitly saying “API”.
Whether the mandate is increased data sharing for customer choice or enhanced sharing of medical records for patient care, the regulations don’t specifically say ‘create and publish APIs’, but APIs are the backbone of modern application development. The continued proliferation of these interfaces is the result. Separate the “What” from the “How” – the only logical way to comply is via microservices and APIs, and these mandates will continue to drive architectures this way for a long time.
That said, it doesn’t mean the regulators will give any leeway for poor API security. While they’ve been somewhat behind the curve, as have the security teams struggling to keep up, that is starting to change. I recently had a group of 8 examiners from three financial services regulators at my booth at a show getting a primer on API security.
From a standards perspective, the first shoe to drop was the introduction of the new PCI-DSS 4.0 security standards, which for the first time, dictates that covered businesses must include API abuse and attacks on business logic in scope of their control set and penetration tests. Transition to the new standards is mandatory during the next two years, so if PCI and API security cover you aren’t on your radar yet, getting these interfaces covered as part of your testing and security program needs to be a priority in the future.
Unfortunately, many CISOs will be told during budget season to delay this to 2024, JUST BEFORE the mandatory deadline, which means that these interfaces, and the back-end systems and data they expose, will be unmonitored and untested until the very last minute that someone else told them to take the threat seriously.
That’s a real litmus test for how an organisation views cybersecurity – if your institution only engages in the necessary measures when a regulator tells it to do so, it will always be behind the curve. The PCI standards didn’t add these requirements for fun – they were added because these interfaces and attacks on business logic pose a risk they need everyone in the ecosystem to address.
The bottom line
Gartner predicted years ago that APIs would be the #1 attack surface in 2022. Still, most institutions are unaware of attacks against their APIs, even those with otherwise mature security programs.
Under-resourced security teams are often forced to take a compliance-based approach to their security rather than one based on risk, a fatal flaw that comes back to bite them. While security resources aren’t cheap, try a lack of security if you think security is expensive. In today’s world, if you’re waiting for someone else to tell you how to manage your risk, it’s more likely that someone else will exploit it first – at your expense.
This doesn’t mean your teams must become API security experts; they must know one. Security and technology teams must get their arms around their API ecosystem now to get the processes and tooling in place to catch up and keep up and break the compliance-based, reactive approach. That’s 3rd mouse thinking, and they will never get your business where they need to go. There will be more APIs in your ecosystem next week and next month than today, and this growing problem will never be easier to solve than it is today.
–
About the Author: Chuck Herrin is the CTO of Wib.