WHY CLOUD MATTERS:
When we think about cloud, the things that usually come to mind are cost savings, outsourcing & Infrastructure as a Service (IaaS). While cost saving benefits are relevant, cloud adoption has a much larger strategic value proposition tied to the
Digitization Of Financial Institutions, summarized below.
Cloud is omni-present and will serve as a backbone to the digitization journey and adoption of the Internet of Things (IoT).
In the short term, cloud computing’s most disruptive impact will be changing the way consumers research and buy financial services by offering banks the capabilities to easily leverage social and mobile media to improve the banking experience, particularity
for the millennial, e.g. mint.com. In the long term, cloud computing will be the catalyst to
“IoT” adoption as financial services becomes more automated by the integration of devices, and internal & external networks.
Standardization and Simplification: Uber and
AirBnB are perfect examples of a competitive substitution force that has led to the inception of new business models. Similarly, in the future, banks will become more specialized, focusing on their core competencies. They
will continue to leverage other banks and non-banks for non-core services. One example would be leveraging third party businesses as one of their distribution channels. In order to achieve this future state of financial services, integration will be fundamental.
Banks will need to start focusing on standardizing their IT & business processes, not only to reduce complexity and improve Cost-To-Income Ratio, but also to increase agility and ease of collaboration and integration.
Choosing not to adopt cloud will be a major competitive disadvantage for financial institutions.
Cloud adoption in financial services is moving forward. According to Cloud Security Alliance, over 60% of Financial Service institutions have a cloud strategy in place and/or are already in execution mode. Many recent surveys conducted by various analyst
communities, however, suggest that data privacy and regulatory compliance concerns are the primary reasons among many financial institution executives for not accelerating cloud adoption for core business functions.
Data privacy and security are legitimate concerns. We are already living in a digital world and many people shop online with their credit cards and also share personal content via social networks such as Facebook etc. The point being, that today there are
technologies and regulatory frameworks in place to better manage cloud data privacy and security risks.
DEVELOPING A FINANCIAL SERVICES CLOUD SECURITY & DATA PRIVACY STRATEGY
In order to control and manage cloud security and data privacy risks, I recommend financial institutions take a holistic approach in developing a cloud strategy. The following
PLAN, IMPLEMENT and OPERATE framework could be used to develop a comprehensive cloud strategy for any financial services organization.
PHASE 1: PLAN
During the plan stage institutions need to focus on establishing policies and strategies to achieve security objectives. A key aspect of planning is to incrementally take an inventory of all business processes for each business service that could be a candidate
for modernization and cloud migration, e.g. (HR, Procurement, Mortgage, Deposit, Lending, Claims, Policy, Customer Service, and Finance & Risk). These business services and respective sub business processes and data profiles should be sorted by privacy needs
(high, medium, low) based on internal and relevant regulatory controls & requirements. A list of standards and regulations cited by
Cloud Security Alliance can be found below.
This is not an exhaustive list.
- Auditing: FedRAMP, ITAR
- Auditing Standards: FFIEC, NIST
- Banking Authorities & Regulations: GLBA, OSFI, EU Directive 2009/136/EC, EU Directive 1995/46/EC, ICO Privacy Amendment, California SB 1386 and similar laws in 46 states, US Patriot Act
- International Regulatory Framework: Basel III
- Payment Industry Application / Card Data Security Standard: PA DSS, PCI DSS
- Cybersecurity Framework: PIPEDA
- FDIC: IRS, SEC
In addition to the Data Privacy & Regulatory requirements, financial institutions must also set requirements for
Identity Management, and Auditing. The output of the planning stage would produce a holistic risk profile across multiple dimensions (described above) and would establish Data Privacy, Security & Auditing requirements for each business service.
PHASE 2: IMPLEMENT
Based on the requirements established in the planning phase, the output of this stage would be to establish and implement various solutions by striking a balance between security risks and cost benefit analysis. From a solutions standpoint, the scope of this
document focuses on three key critical areas: Cloud Deployment Models,
Data Privacy approaches and Identity Management capabilities.
a) Cloud Deployment Models:
A decision will need to be made regarding the selection of the most appropriate cloud deployment model based on the requirements established for each business service during the Plan phase. Most likely financial institutions will end up selecting a hybrid
model. There are four types of cloud deployment models,
National Institute Of Standards and Technology.
A Private cloud is a cloud infrastructure that is operated solely for an organization. It may be managed by the organization or a third party and may exist on premise or off premise.
In a Community cloud, infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by the organizations
or a third party, and may exist on premise or off premise.
A Public cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.
A Hybrid cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology that enables data and application portability.
b) Data Privacy:
Depending on the business processes and respective data profile and regulatory requirements, a key decision will be needed regarding data privacy implementation approaches.
Data Encryption and Tokenization are the two approaches used to protect sensitive data from loss and legal liability. Financial Institutions need to understand when to select encryption, and when to use tokenization to protect information. A balance
between security, cost, performance and key management must be kept as the fundamental criteria on selecting an approach.
Tokenization is a relatively newer approach to secure specific sensitive data. In Tokenization the secure data is replaced with a non-sensitive value. One can think about this non-sensitive value as metadata or surrogate data. The underlying sensitive
data is stored separately. These surrogate data values (Tokens) prevent unauthorized access to secure data such as financial information, social security information, driver’s license etc. In the tokenization process a token is created with a random set of
surrogate values and mapped with the actual underling secure data which is usually stored separately.
For example, a social security number 343-66-0000 might be assigned the token value of 000-66-1111. Once this token is assigned it will always be used when the original value would have been used.
Encryption can be described as the process of transforming data using a
cryptographic algorithm to make it unreadable to anyone except those who have access to the encryption key. Encryption is a commonly used approach to keep the data secure in motion
or at rest. Encryption is usually implemented in an end-to-end process, implying that data
is encrypted from the point of entry to the point the processing occurs.
Encryption or Tokenization, which one to use?
Encryption is a more mature approach. There are appropriate uses for both encryption and tokenization. The encryption approach provides the greatest level of data security and confidentiality. Tokenization provides greater flexibility in enabling a business
to limit the data elements that need to be protected, such as social security or credit card numbers. In order to do this successfully, however, a company must be able to identify the specific data to encrypt, which requires intimate knowledge of its data
profile and respective regulations.
Each organization will have to select an approach that is best suited for them based on their needs by keeping a balance between privacy risks, implementation costs, regulatory requirements and system performance needs.
c) Identity Management:
The importance of Identity Management cannot be underestimated as financial institutions transition from traditional “on premise” to “cloud computing”. In practical terms, a financial organization’s IT strategy would include various information technology
deployment models, including On Premise, Private, Hybrid & Public cloud strategies. Due to this complex hybrid environment, a robust strategy will be needed to authenticate the right user, render right authority, manage an account, and perform audits.
Currently there are three types of authentication approaches that need to be evaluated in designing cloud security:
Single Factor Authentication, Two Factor Authentication and Multifactor Authentication.
Single factor authentication as anything that requires a simple username and password.
Two factor authentication includes “username and password” and an additional physical item, such as a smart card. An example would be the use of an ATM machine. The user inserts a debit or credit card along with entering the security code.
Multifactor Authentication adds a third level of security, such as biometric authentication. This could include a fingerprint, retinal scanning etc. A good example would be the finger print option to log on to an IPhone.
Depending upon the security policies and requirements established during the planning stage, a combination of Two Factor and Multifactor authentication solutions should be used.
After the person is authenticated, the next step is establishing an authorization solution, which includes providing the the right level of authority to perform tasks in accordance to
the role. Leveraging a solution that can centrally manage all the authorizations regardless of the asset or location will dramatically reduce complexity and cost.
Sometimes a new hire may not have access to certain applications. Another scenario may arise where an employee is terminated and should not have access to systems. Account management is a process that keeps profiles and user accounts up to date. Standards
such as System for Cross-domain Identity Management (SCIM) and Federated Single Sign-On (SSO) can be used to actively manage distributed accounts.
Audit trails, tracking system usage, authentication and authorization are key security and regulatory requirements in financial services. Audit includes tracking failed authentications and/or unauthorized access to certain systems. Financial Institutions
need to evaluate and implement solutions that can provide centralized auditing regardless of the location or device used by the user.
PHASE 3: OPERATE
After phase 2 is implemented, the operate phase is meant to continuously review and monitor the system against the security policies and regulatory requirements established during the plan phase. Random and scheduled tests must be performed to ensure compliance
at all times. If any gaps are identified during these tests, financial institutions must immediately execute a mitigation plan to ensure compliance. It will be important to have detailed contractual agreements with the cloud service providers with Service
Level Agreements (SLA) regarding operations, auditing and breach notifications.