How APIs Changed Bank Security From Castles to Strip Malls

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.

Banking’s Single Pane of Glass

Imagine looking at all the elements and complexities of a given business through a clear and concise “single pane of glass: one easily manageable web interface that has the horizontal capability to do anything you might need, all in one platform.”

It may sound too good to be true, but “single pane of glass” systems could soon become a reality within the mortgage industry. Underwriters, processors, loan originators and others who work at a mortgage or banking institution in other capacities must manage and maintain a plethora of different third-party software solutions on a daily basis.

It’s complex to simultaneously balance dozens of vendor solutions to monitor services, using different management console reports and processes for each. This cumbersome reality is one of the most significant challenges bankers face.

There are proven solutions and approaches to rationalizing these operational processes and streamlining interactions with customers, clients and new accounts. In the parlance of a technologist, these are called “single panes of glass,” better understood as multiple single panes of glass.

That does exist if you’re talking about a single product. Herein lies the problem. Heterogenous network users are using single third-party platform solutions for each service they need, with a result that one would expect. Too many single panes of glass — so much so that each becomes its own unique glass of pain.

How can banks fix this problem? Simply put, people need a single view of their purposed reality. Every source of information and environment, although different, needs to feed into a single API (application program interface). This is more than possible if banks use artificial intelligence and machine learning programs and API frameworks that are updated to current, modern standards. They can unify everything.

Ideally, one single dashboard would need to be able to see everything; this dashboard wouldn’t be led by vendors but would be supported by a plethora of APIs. Banks could plug that into an open framework, which can be more vendor-neutral, and you now have the option to customize and send data as needed.

The next hurdle the industry will need to overcome is that the panes of glass aren’t getting any bigger. Looking at pie charts and multiple screens and applications can be a real pain; it can feel like there isn’t a big enough monitor in the world to sift through some data spreadsheets and dashboards effectively.

With a “single pane of glass” approach, banks don’t have to consolidate all data they need. Instead, they can line up opportunities and quickly access solutions for better, seamless collaboration.

Focusing on one technology provider, where open-source communication can make integration seamless, might be a good adoption route for bank executives to consider in the short term while the industry adapts to overcome these unique challenges.