For today’s businesses to grow and provide new services to their customers, they need to become more agile and interconnected. This requires them to open up access by third parties to information that allows them to more quickly provide the features and functionality that their customers are always clambering for.
For instance, now banks need to provide younger populations with the services they want when they want them. If banks are not prepared to quickly provide content, facilities and features to their user base, they may have trouble retaining business. To maintain this “stickiness” banks will have to provide an open banking API reference for the FSI service providers to be able to utilize, to allow them to provide customers with what they need.
In the financial services industry, particularly in Australia, we have an open banking API that allows third-party application services or providers to get access to user information. These APIs allow services to be presented to users in many different ways that are more beneficial for them. But when the banks create this open API, they're essentially allowing third parties (that users don't know) to have access to account details that could be used in harm’s way.
For that reason, many users may not wish to have account details made publicly available to a third party other than their bank. But new markets for banking, such as Generation Y or millennials, are more accustomed to providing personal information without much reflection. These segments are comfortable sharing on Facebook and they tend to use other social media with abandon. For example, if you look at mobile banking users, they've all got a Instagram, Twitter or Facebook. In fact, the banks increasingly use social media to try and win over the next generation of customers, and so that mindset is not about to change any time soon.
So, from an API perspective, this could create an absolute great hole for any would be attacker to get access to a user’s information if they could somehow discover that access condition. This risk makes it paramount to protect the identity or the key that is used to access that open banking API. In this new world, we can’t just think of machines in terms of microservices, containers, virtual systems, or otherwise. In reality, they will become the APIs of tomorrow and we will need to protect these identities.
See how APIIDA is developing an automated to protect machine identities within APIs - for the first time.
But protecting API machine identities may be challenging as they fall outside the direct influence of the bank. In this sense, they may represent an attack vector because the bank has to trust that the information coming from the third party is really coming from that entity. So, we see with inside the bank, they can control the protection of their machine identities, even verifying their authenticity. But now banks have to somehow enforce that third-party application developers do the same and protect the identity that they're using to initially authenticate with the bank.
So, that in itself is opened up the risk surface for banks. Instead of just having a perimeter that's protected externally and has limited public facing keys, banks now have thousands of developers out there all who would have access to those APIs by signing up and getting a key. In this scenario, how would the bank enforce the protection of that key at that third party?
With third-party developers all over the world, it’s difficult for the bank to control who can get access to a system where the API key is stored. Because this key is used to provide the API connectivity to the bank, then it is incredibly valuable to attackers. This makes it more important than ever that organizations require their partners to protect all types of machine identities.