Unfazed by Capital One breach, KeyBank begins migration to cloud
The day Capital One announced that data tied to 100 million customers had been breached within Amazon Web Services, KeyBank's Keith Silvestri and a colleague gave a previously scheduled presentation on their cloud computing plans to Key's top executives.
“They didn't want to see anything in our [slide] deck, they just wanted to talk about the breach,” said Silvestri, who is the Cleveland bank’s chief technology officer. “Our perspective is that that breach could happen at any data center at any company. It had nothing to do with the fact that Capital One is in the cloud with AWS. It was an insider threat and a compromise of Capital One's firewall rule sets.”
Undaunted by Capital One’s experience, KeyBank is preparing to move a large data analytics program and a petabyte-sized data lake to Google’s public cloud. It is also using software from Google to migrate applications to a private cloud.
“We think that the cloud has matured over the last three years or so,” Silvestri said. “The industry is really accepting that the cloud providers are enterprise-ready and that the security, cost-efficiency and time to market are there.”
Like any company that adopts cloud computing, Key seeks cost savings and the ability to quickly turn on and use someone else’s servers, instead of buying and installing their own, to meet spikes in activity or launch new products.
“Banks are judged by their efficiency ratio,” Silvestri said. “If you don’t take advantage of infrastructure as a service, you're going to be left behind.”
Online banking, data analytics, data lake in clouds
KeyBank already uses cloud (software as a service) applications like the Salesforce customer relationship management software, Workday human resources and payroll software and ServiceNow workflow software.
It runs about 300 applications, including online banking and corporate banking, in a private cloud that has the flexibility of the public cloud, Silvestri said. If there is a surge in traffic on Thanksgiving, for instance, it can be scaled across many java virtual machines.
For the past three and a half years, KeyBank has been running these applications in Red Hat’s OpenShift container software.
In the first step of the new cloud initiative KeyBank announced Thursday, it will move its online banking platform from OpenShift to Google’s Anthos container software. Soon after that, it will migrate its corporate banking platform to Anthos in the on-premise cloud. Eventually, everything that today runs in OpenShift will move to Anthos.
Containers are a big part of KeyBank’s cloud strategy, both for its on-premise cloud and its use of public clouds.
Software containers are kind of like virtual shipping containers within which applications can be developed, run, managed and moved from one hardware server to another or to and from public and private clouds, regardless of the operating system of the underlying server (e.g. Windows or Linux) or cloud provider.
“We look at containerization as the methodology that allows you to take all the applications that you have built over time and make them cloud-ready,” Silvestri said.
Containerized applications can be moved to Google’s, Amazon’s or anyone else’s cloud.
“Containerization also lets programmers be programmers,” Silvestri said. “When you don't containerize applications, the programmer needs to think about the operating system, the patch levels, the security and everything else that goes around it. When you containerize an application, they don't need to worry about any of that.”
Why the switch from OpenShift to Anthos? Silvestri said he prefers the upgrade path Google offers for its software over Red Hat’s. And Anthos will help the bank work with multiple cloud providers. KeyBank already has contracts with Google, Amazon and Microsoft.
“Maybe Google doesn't want to hear this, but Anthos allows you to move your workloads from Microsoft Azure to Google Cloud Platform, Amazon Web Services or another cloud,” Silvestri said.
The bank is currently testing Anthos and hopes to go live with it on premise in connection with its online banking platform in the first quarter of 2020.
Next, KeyBank plans to migrate its Teradata data-analytics system to Google’s public cloud-based BigQuery.
The Teradata system was nearing the end of its life, and the bank faced a choice of either buying 130 new servers and continuing to house Teradata on premise, or putting the system in Google’s cloud and saving the bank millions of dollars a year, Silvestri said. Using the Google system, the bank pays by the query rather than hosting and running all those servers internally. This initiative should also be completed in 2020.
The bank further plans to move its Hadoop data lake, which holds more than a petabyte of data, to the Google cloud platform.
Later, KeyBank may move software application testing into Google’s cloud.
Other banks are also embracing cloud computing in spite of the recent AWS breach, according to James O’Neill, investment partner at Motive Partners, a private-equity firm that invests in fintech companies. Until two years ago, he was Celent’s cloud computing guru.
In 2012, cloud computing was “still sort of a science project for banks,” and five years ago, though some banks were experimenting, “there was still an assumption that the cloud itself was not highly secure and therefore the bank had to be really careful about what and how it deployed in a cloud,” he said.
Today, many large organizations have confidence in the underlying security of the cloud, he said.
“The U.S. Department of Defense is using the cloud for data management,” O’Neill said. “Many high-profile banks are using it. It’s now acknowledged in the industry that there’s nothing fundamental to a cloud deployment that makes it less secure.”
Banks are increasingly moving noncore computing to the cloud — things like data analytics, data warehouses, and data lakes, he said.
”What I haven’t seen a lot yet — and perhaps this is the next wave — is movement of core banking systems themselves to the cloud.”
Banks still have a responsibility to deploy securely to a cloud, O'Neill said.
“Just because the cloud is safe, that doesn’t mean you don’t encrypt your data while it’s in transit to a cloud and when it’s sitting in the cloud,” he said.
He also recommends data-field masking (for instance, only showing the last four digits of a credit card or Social Security number) and access control to make sure credentialed users can only see data they are entitled to see based on their job and status within the company.