In financial services, our job is to manage risk. Ideally, every IT system and application should stay exactly the same (since the last time you passed an audit) so that you don’t have to re-do work. 

Unfortunately, in the age of cloud, stasis is no longer an option. So how do we, as IT professionals in financial services, accelerate AWS migration with the minimum amount of disruption to our existing governance processes?

In this eBook, we’ll outline concrete steps and real case studies for finance companies that have migrated legacy applications from on-premises to AWS in less than 6 months – often in less than 90 days. We’ll show you how to set up a framework that makes migrating legacy applications easier from start to finish without major restructuring of your applications. 

Download the Full PDF of this eBook Here

Finance on AWS

From large financial organizations to FinTech startups, most companies have made significant investments in cloud technology. In fact, 72% of US finance executives say they are either using cloud-based solutions or plan to do so in the future. Many of them have already migrated workloads to AWS. AWS now counts Capital One, FINRA, Nasdaq, and Pacific Life among its customers. Nearly 40% of companies are adopting a cloud-first strategy. What’s the draw?

Agility and scalability are frequently cited as the top reasons for cloud migration. Long gone are the days when you build an application and run it unchanged for years, and “digital transformation”, which often implies a mix of application modernization and cloud adoption, is now a mainstream concept. A cultural shift in favor of customer-obsession and pressure from nimble FinTech startups has pushed the entire finance industry to adopt cloud technologies relatively quickly, despite their risk-averse nature. 

AWS has also actively courted financial institutions by strengthening security and governance controls that the industry needs. AWS has achieved nearly every compliance standard a finance organization could want, and there’s reason to believe that they hold themselves to a higher standard than many corporate datacenters. Beyond basic encryption, firewall, and logging services, there are now  new services like Amazon Macie, a tool that leverages machine-learning to detect anomalies, and Amazon Security Hub, a tool that gives you a high-level view of security alerts and compliance status across your AWS accounts. 

The AWS Migration Process for Finance

Once a financial services company or bank decides that it wants to migrate to AWS, the normal process is as follows: 

This process is more or less consistent for any application type. Let’s dive into each step more deeply. 

Step 1. Discovery and Education

The first step in any migration project is to bring together key stakeholders to discuss and finalize your goals for moving to the cloud.

After helping thousands of organizations move to AWS, the AWS team created the AWS Cloud Adoption Framework (AWS CAF) to provide guidance for each unit in your organization. According to AWS, the CAF helps each business unit understand how to update skills, adapt existing processes, and introduce new processes to take maximum advantage of the services provided by cloud computing. The AWS CAF is organized into six focus areas to help organize your efforts:

By breaking down the process into focus areas, each business unit can better plan for the impact of cloud adoption. 

The AWS CAF is usually delivered in the format of a live, in-person workshop facilitated by an approved AWS CAF workshop partner like Logicworks. 

The ultimate goal of the AWS Cloud Adoption Framework is to unify stakeholders and create an action plan designed to move your team from cloud goals to cloud implementation.

Governance and the Shared Responsibility Model

For many finance organizations, the “Governance” portion of the Cloud Adoption Framework can be the most challenging area. Governance, Risk, and Compliance teams are unfamiliar with the responsibility model for operating on AWS and often skeptical about security controls they don’t directly manage. The most important part of the Discovery and Education phase is educating compliance teams about the AWS Shared Responsibility Model. 

By migrating to AWS, you have a shared security responsibility. This shared model means that AWS manages the infrastructure components from the host operating system (virtualization layer) down to the physical security of AWS’ datacenters. It is your responsibility to configure and secure AWS-provided services. In other words, AWS controls physical components; you own and control everything else. As AWS states repeatedly, “AWS manages the security of the cloud; security on the cloud is the customer’s responsibility.” 

The same line of demarcation applies to IT controls. Customers on AWS shift the management of some IT controls to AWS which results in a shared control environment. AWS manages controls associated with the physical and architectural infrastructure deployed in the AWS environment; the customer is responsible for network controls (Security Group configurations), access controls, encryption, and any control not directly managed by AWS.

In short, running on AWS is very similar to running your applications in a rented datacenter. You are still responsible for common security operations tasks and for using AWS services in a secure manner.

Physical Security and Environmental Controls

If you are concerned about the security of AWS’ datacenters, any customer can access a copy of AWS’ SOC 2 Type II report, which provides significant detail about physical security and environment controls. This report, ISO 27001, and dozens of others are available for review by audit and compliance teams if you visit AWS Artifact. If an auditor requests specifics regarding the physical controls of your system, they can reference the AWS SOC 2 Type II report. AWS does not allow datacenter tours, as independent reviews of datacenter security are also part of the SOC, ISO 27001, and other audits.Physical Security and Environmental Controls

Data Privacy

AWS customers retain control and ownership of their data, and customers can move data on and off of AWS storage as required. AWS does not leverage any third-party providers to deliver services to customers and therefore does not provide any customer information or access to data to any other provider. Customers must control access to applications and data through the AWS Identity and Access Management service.

Client environments on AWS infrastructure are by default logically segregated from each other and have been designed to prevent customers from accessing instances not assigned to them. AWS has both instances that are dedicated to a single customer (Dedicated Instances) and instances hosted on shared infrastructure. AWS is responsible for patching the hypervisor and networking services, while customers patch their own guest operating systems, software, and applications.

PCI Compliance on AWS

PCI-DSS is usually a baseline security requirement for most finance companies. 

New AWS customers often ask if AWS is compliant with PCI DSS. The answer is yes. AWS’ physical datacenters are PCI DSS Level 1 Certified; however, that does not mean any application running on AWS is PCI compliant. AWS provides services that facilitate compliance, but all IT controls above the level of physical infrastructure are a customer’s responsibility. 

The Payment Card Industry Data Security Standard (PCI DSS) is a security standard that applies to all entities that store, process, or transmit cardholder data or sensitive authentication data. Although the standard was created to protect card payment data, PCI DSS is built on standard security principles, including topics like encryption and access controls that apply to many types of data. Companies seeking PCI DSS compliance must manage their own compliance certification. If any system with cardholder data or sensitive authentication data is deployed on AWS, your auditor can rely on AWS’ Attestation of Compliance for certain physical security controls, but only for services in scope for PCI DSS. 

In 2016, only 55.4% of companies met all PCI compliance standards. While this number is up 7% from 2015, it still translates to nearly half of retailers, IT services companies, payment software providers and hospitality organizations not adequately protecting credit cardholder information. Additionally, 44.6% of companies fall out of PCI compliance within nine months of validation. 

Want to keep reading the rest of this eBook? Read the remaining 10+ pages by downloading it here.