Security Best Practices for Migrating your Database to the Cloud

Security Best Practices for Migrating your Database to the Cloud

What is/was your biggest hesitation in moving databases to the cloud?

More and more organizations are moving applications and databases to IaaS/PaaS environments in order to enjoy the benefits of cloud computing while still preserving application flexibility and control. However, many enterprise IT departments have serious concerns about moving their more sensitive servers and data to the cloud. These concerns are the same whether they are migrating from MySQL or SQL Server, or migrating to Amazon Web Services AWS , Window Azure, Google Compute Engine, VMware VCloud, IBM Cloud (Softlayer) or any other cloud hosting service.

They have good reason for concern: industry experts agree that there is no question that moving sensitive data into the hands of third-party cloud providers expands and complicates the risk landscape in which companies operate every day: 

• The Cloud Security Alliance states that data breaches are the top cloud computing security threat.
• The IBM Security Services 2014 Cyber Security Intelligence Index reports 1.5 million monitored cyber-attacks in the US alone in 2013, a figure that is accelerating due to the growing use of cloud infrastructure, among other factors.
• The Ponemon Institute’s recent study, “Data Breach: The Cloud Multiplier Effect,” clearly indicates that IT and security professionals believe that migrating to cloud services dramatically increases the likelihood and economic impact of data breaches by several magnitudes, due to a lack of confidence in the security of data in the cloud.

These reports are reinforced by a consistent stream of news stories about hacked company data. High-profile examples include:

• eBay: Hackers gained access to over 145 million user records, forcing eBay to issue a security warning and encourage its hundreds of millions of customers to change their passwords.
• Target: Hackers swiped the credit and debit card information of up to 40 million Target customers.
• LinkedIn: Data thieves made off with more than 6 million passwords.
• Subway: Hackers stole credit card data of Subway customers, enabling them to ring up over $3 million in fraudulent charges.
• Sony: Hackers accessed the personal information of 77 million PlayStation user accounts.
• South Carolina Department of Revenue: State tax data belonging to 6.4 million consumers and businesses was compromised.
• More: AT&T, Neiman Marcus, Heartland Payments, Living Social, Zappos, AOL and the list goes on…

While migrating application components to the cloud is challenging enough, migrating database servers can prove to be far more difficult, especially in terms of security. Application and Web servers usually require protection from integrity and availability threats, areas for which sufficient mitigating controls are available in cloud technologies. But databases usually require protection against confidentiality threats as well, not to mention adherence to data-related laws and regulations.

This article outlines the most important aspects to consider when migrating a database to the cloud.

Stage 1: Understanding the Scope

What data are you moving?

It is crucial to understand the content and context of the data as it moves to the cloud. Cloud computing adds a number of risks and attack vectors for your risk management plan to consider. Different types of data encompass different challenges. If you are moving PII or other regulated data, such as credit cards or personal health information, you will need to make sure that the migration does not affect your regulatory compliance.

Tools that provide eDiscovery options can help to identify sensitive database content, to understand the regulatory aspects and to assist in classification of the data according to risks.

Who is accessing the database?

In order to fully understand the security aspects of a database, you need to examine who is accessing the database and for what purposes. Remember to think beyond regular user access. For example, administrative tasks should be mapped out to ensure that granular access controls will be maintained after moving to the cloud.

If the application uses external data sources, you may require new controls, such as data-in-motion encryption and data integrity validation, in order to retain data confidentiality and integrity as this data moves from those sources into the database.

Questions to ask when mapping out who needs access to your database:

• Which applications access my databases?
• Which source IPs access my databases?
• Which users access my databases?
• When are users and applications accessing my databases?
• What types of database commands are each type of user and application allowed to execute?
• Which types of data can each user/application access, and which should be blocked?

Tools such as database activity monitoring (DAM) can be a huge help in mapping database access from different sources (users, administrators, third-party contractors, applications, etc.). Once the database access is mapped, you will have a better understanding of your cloud database security requirements.

To where are you moving the data?

Understanding the environment into which you are transitioning plays a great role in securing your data. Not all IaaS/PaaS providers offer the same security capabilities. Migrating your data into a database managed by a cloud provider poses different challenges than installing your own database infrastructure. When weighing your cloud provider options, make sure that you fully understand the security aspects involved. For example:

• What physical and network security infrastructure is in place?
• Who has administration access to the database?
• Can you allow/disallow granular access to different data and database resources?

This is a good opportunity to mention that the location of the data is important. Different geographic locations could mean different regulations, laws and standards, factors that could affect your hosting provider choice. 

Stage 2: Build your Security Strategy

Once the mapping phase is done, you will have a much clearer picture of the required security policies and how to achieve them. The next step is to plan the security controls. Here are some challenges that businesses need to address:

The shared responsibility challenge

The first challenge of moving to the cloud is understanding who is responsible for what. In IaaS, the borders are clear, but in PaaS they are more blurred. As a rule of thumb, your provider is responsible for protecting the infrastructure components, but all instance and application security is up to you. If you are using a managed database environment, your provider will also be responsible for the availability of the database, but it will not provide protection against confidentiality and integrity threats – that is up to you. Here is a summary of areas that the organization is still responsible for:

1. Protecting the data as it moves to the cloud – Data-in-motion encryption, such as SSL or VPN, should be used to protect the data as it moves in and out of the cloud. This is also a good opportunity to remember that it is a common best practice is to encrypt the traffic between the application server and the database server.
2. Hardening instances – With IaaS, the customer is responsible for securing the operating system. This including hardening processes, patches, security software installation and following the database vendor’s security guidelines. When working with PaaS and managed databases, this is usually the responsibility of the provider.
3. Protect management console access – The IaaS management console, with its wide range of permissions and capabilities, is the most intimidating attack vector in the cloud, as companies have learned the hard way. The use of best practices such as MFA, role-based access to dashboard functions and a data recovery plan to an external location are mandatory for addressing this attack vector.
4. Account for application security – When building applications in IaaS and PaaS environments, most components of the Security Development Lifecycle (SDLC) are the customer’s responsibility. Make sure to include cloud-specific threats in your threat modeling.
5. Prepare plans for availability, backups, DR and BC – Most IaaS vendors will provide you with the tools for creating an adequate backup and DR strategy within the boundaries of the provider. However, the customer is responsible for deploying the tools required by these requirements. Deploying DR to a different cloud provider (or local network) often requires additional tools and integration work. 

Compliance challenges

Compliance in the cloud can be challenging for a variety of reasons. For example: The cloud adds more complexity because the scope of regulatory compliance now includes infrastructure under the responsibility of a third party. Different jurisdictions have different laws and regulations, which may all have to be met. Cloud technology sometimes limits the visibility into internal systems and mechanisms. And not all auditors understand cloud computing.

In order to reduce compliance efforts, it is very important to select a provider that holds compliance certification for the environments you will be using. Most providers invest heavily in compliance for their datacenters, so this should not present a real problem.

Once the provider infrastructure is compliant in terms of its own responsibilities, it is up to the customer to ensure that his application environment can also achieve compliance certification. In general, when talking about compliance in relation to databases, the following controls should be considered: 

• Understanding where the data is:  You cannot protect something if you don’t know where it is. Regulated data should be mapped to exact locations.
• Separation of duties:  It is necessary to implement mechanisms for (1) separation between production data and test environment data, (2) separation between non-regulated applications and regulated applications, and (3) segregation of duties between the different roles involved with handling the data.
• Access controls should be in place:  All access to sensitive data should be governed, monitored and approved. This includes user access, administration tasks and application access.
• Identity Management: A cornerstone for building effective access control is implementing an adequate identity management solution. This includes provisioning and de-provisioning of accounts, authentication mechanisms and RBAC.
• Encryption and encryption alternatives: Some regulations force you to encrypt data in motion. Some require you to encrypt the data at rest (or you may want to do it voluntarily in order to reduce required compliance efforts). While encrypting communications is usually relatively easy, encrypting databases at rest can be challenging. Different encryption methods solve different aspects of the problem. Encrypting at the storage or volume level can protect the data from hardware theft, but not from abuse via application manipulation. The higher up the application stack, the more challenging encryption gets. Sometimes, encryption alternatives such as tokenization or data masking are more effective and efficient.
• Detecting, preventing and mitigating attacks: You may be required to demonstrate the means to detect and prevent attacks on the database (e.g., SQL injection attacks). This requires the development of adequate controls and audit infrastructure.
• Operational security:  There are regulations that emphasize ongoing security efforts. Procedures should be developed to govern asset management, change management, production access, periodic vulnerability scanning, adequate remediation procedures, user access audit, management operation, and event response procedures. All of those requirements must be planned according to the capabilities of the cloud provider. Ongoing monitoring of security events can be challenging in cloud environments: while most IaaS vendors offer solid audit data on management operations, traffic logs and network visibility options are typically much more limited and may require additional efforts (e.g., third-party software) to overcome these limitations.