You’ve probably heard the phrase “Don’t put all your eggs in one basket.”
This comes up a lot as I talk with executives and boards of directors at financial institutions across the country. While the phrase has merit, using it as a basis for your technology strategy can have unintended consequences.
The logic seems sound – diversify your risk, right? However, when it comes to your IT infrastructure strategy, spreading your reliance across multiple technology providers actually increases risk while reducing effectiveness.
Let’s unpack why you should reconsider the concept of diversification and risk when it comes to your technology strategy.
There are some situations in which having multiple providers perform the same function has merit. For example, you should have multiple telecommunication providers. However, each technology provider also introduces risk.
First, more providers leads to more complexity, and as complexity goes up, so does risk.
Years ago, I worked for a financial institution that followed a “best of breed” strategy. On the surface, it sounds great. However, in practice, this strategy creates the need for more integration.
For example, using separate providers for online banking, mobile banking, authentication, account opening, money movement, etc., creates the need to integrate each of these disparate solutions. Besides increased risk, this approach also results in higher costs – both at the point of initial integration and in ongoing maintenance expense.
More providers, means more potential points of failure.
Increasing providers effectively increases your attack surface, giving the bad guys more potential points of entry. Hackers will go after the point of least resistance. They don’t need to break into your main network. Instead, they only need to find the weakest link in your vendor network. Once they get a foothold, they can use that to springboard onto your network.
Consider a financial institution relying on five different technology providers, for example. If each vendor has a 5% probability of being breached, the likelihood that at least one gets hacked can be calculated like this: P (at least one breach) = 1 – P(none) = 1 – (0.95^5) = 22.7%.
That means the financial institution has a 22.7% chance of experiencing a vendor-related cybersecurity breach. Doubling the vendors to 10 increases vendor risk and puts that institution at a 40.1% chance of experiencing a vendor-related cybersecurity breach: P (at least one breach) = 1 – P(none) = 1 – (0.95^10) = 40.1%.
While the exact probabilities may be hard to determine, what is clear is that increasing the number of vendors increases your risk of a data breach.
Besides increasing your attack surface, each additional vendor brings potential visibility challenges. Leveraging a Security Information and Event Management (SIEM) tool to capture and analyze data feeds from all corners of your network can help identify potential issues within your environment.
However, you don’t have visibility into your vendor’s security stack, creating visibility gaps in your security posture. Plus, each vendor involved has less visibility, which reduces the effectiveness of their security systems, resulting in your environment being less secure.
When multiple vendors are involved, you will inevitably see more finger-pointing. Who is responsible? Who should have caught the security flaw? Who owns the outcome and will ultimately pay if you are unable to serve your accountholders and lose business?
Consider what you might do if you have an ATM that stops working. You likely have an ATM vendor, a telecommunications provider, a security vendor who manages your firewalls, a core provider, a server-hosting provider, someone who manages your network, etc.
If you’re lucky, you can get everyone on a call to troubleshoot and narrow down the problem. Yet, more often than not, key resources may be unavailable, and you have to settle for what you can get. This delays resolution, and in the meantime, your accountholders suffer.
It’s a classic case of having too many cooks in the kitchen.
Consider what you might do if one of your applications runs slow.
You might have an application vendor, a telecommunications provider, a different vendor who manages your local area network (LAN), a separate vendor who manages your firewalls, and another who manages your wide area network (WAN) – plus the vendor who developed the integration between other third-party applications, and possibly even application support from those other third parties.
You would likely start with the initial application support and work your way across the different layers from application through the transport and network layers, needing to pull in the vendors with their limited visibility of their piece of the system. This time-consuming task is all too common.
Contrast this with having a provider with full visibility across your network. Utilizing multiple telecommunications providers makes sense to provide resiliency at the transport level. This gives you multiple “pipes” for your data to flow.
Then to provide full visibility, you need to be able to track packets as they move from your applications across your LAN and WAN. Even better is having this data flowing within a provider’s private cloud while utilizing virtual desktop infrastructure (VDI) to provide both increased security and visibility.
Many financial institutions have already moved to the private cloud model with VDI along with a managed Network-as-a-Service (NaaS) solution. Each environment is different, and you may be at a different point in your technology journey.
Regardless of where you are in your journey, understanding the inherent trade-offs between vendor diversification and technology risk management will help you make more informed decisions when determining what’s best for your institution.
Are you interested in learning more about how you can protect your institution and your accountholders? Connect with a Jack Henry™ technology expert!
Stay up to date with the latest people-inspired innovation at Jack Henry.
Learn more about people-inspired innovation at Jack Henry.
Who We Serve
What We Offer
Who We Are