The application programming interface, or API, has become one of the principal building blocks of the modern digital economy.
APIs are at the center of modern application architectures and system design; over 90% of the world’s internet traffic passes through them. For banks, APIs are the conduit that connects institutions to customers, partners and each other. Their responsiveness and agility drives innovation while dramatically lowering the cost of application development and integration. In addition to remaining competitive and innovative, API adoption and the microservices that use them are key to addressing regulatory requirements for open banking, such as PSD2.
But there’s a problem, and it’s a familiar one: With new technology, adoption tends to outpace security. It is the same situation with each new generation of tech solutions: adoption leads and security lags a few steps behind. This is happening right now with APIs — and banks should be anxious.
But anxiety is frequently taking second place to blissful ignorance. Most chief information security officers in financial services don’t understand the full implications of the API economy and are not measuring their institution’s exposure to its risks. It’s a major blind spot; you can’t secure that which you can’t see or don’t understand. Within the same organization, the CISO and the DevOps (a portmanteau of “software development” and “IT operations”) team commonly don’t really speak the same language. DevOps teams can often see the issues, but CISOs are not as alert to them. This gap in understanding means many back-end systems and critical infrastructure could be exposed to a cyberattack.
Regulators and auditors are catching up on the implications of architectural and attack surface changes and have yet to update their audit or examination methodologies. They are learning what questions to ask, from the basics around API ownership to detailed metrics and matters of governance around operating effectiveness. But some are still hazy about what an API even is, let alone why it might pose a problem.
Complexity is the Enemy of Security
Part of the difficulty is the complexity of legacy IT stacks that most banks are sitting on. Unfortunately, there’s rarely a financial return on a bank retiring a mainframe or decommissioning legacy systems. This leads to IT and security teams being responsible for maintaining and securing several generations of different technology, from ancient “Big Iron” mainframes and AS/400s right up to modern, fully API-driven digital banking platforms. The discipline and focus on system life cycle management is a continuous challenge. Migrations are complex and you can’t just switch off old systems — that’s like changing a plane’s engine mid-flight.
The complexity of securing and managing these multiple generations is immense; most banks don’t have the skills or resources in-house to do it. Complexity is the enemy of security, and the complexity of modern computing environments is only increasing. For chief information officers, chief technology officers and CISOs, it’s difficult enough to keep up with the current complexity. While Gartner estimates that APIs will become the No. 1 attack vector this year, API threats are just coming onto the radar as an area of focus.
Why are APIs at Risk?
The benefits of migrating to an API-first, microservice-based architecture are so strong that their adoption is inevitable. The advantages of APIs are manifest in terms of being able to easily collaborate with other companies, share data and simplify all kinds of integrations that weren’t possible before. The problem is that yesterday’s security model wasn’t built for this architecture.
Think of the security model for old monolithic web applications like a castle with a moat: a gate with a drawbridge that means one way in, one way out. Your services sit behind your defenses inside the castle. The microservice and API-first model changes that attack surface to more of a strip mall: external doors on each store. Data is highly distributed, but the castle’s security methods were never designed to monitor or protect this approach.
In many cases, security teams are not even aware that this is happening; this is even more common where there are third parties involved. Third-party dependencies are very common in banking, and it’s extraordinarily difficult to get appropriate visibility into critical supply chain vendors that banks rely on for key operational and control processes.
All this begs the question: If the adoption of APIs is inevitable, how will banks manage them safely? Security programs must evolve to address API challenges directly. Without management and appropriate security designed for them, APIs expose your bank’s essential data while the “guards at the front gate” have no idea what’s going on.