A Hierarchy Of Data Security Controls

For most enterprise IT security professionals, there are some common reasons that we need to protect a given data set. For the most part, they fall into a few easy categories:

• Meeting a compliance or regulatory requirement
• Implementing best practices
• Minimizing the chance of a data breach of PII
• Protecting sensitive financial data, intellectual property or secrets
• Or complying with a customer or supplier requirement

However, the controls needed to comply with the requirements sometimes aren’t so clear. The decision about which controls to implement needs to be the result of a risk/benefit calculation which depends on the priorities of the organization, the risks that need to be mitigated against as well as the time and budget required for implementation. With some exceptions for cloud environments (which we’ll cover shortly) the difficulty of implementation grows with the level of protection provided.

What I’ll cover here is a brief overview of the layers where protections can be applied, which data security risks can be mitigated at that protection layer, and then the data security controls that can be used to provide the risk mitigation needed, along with some background about implementation difficulty for each control type.

Data Security Protection Layers, Risks, and Controls

The physical layer: The lowest level of protection is applied at the physical media level – the actual flash or conventional disks, or other storage media that contain the information that needs protection. Protecting data at this level typically only protects against the physical loss, theft or improper retirement of the media. The controls used are typically full disk encryption (FDE), KMIP key management of encryption for arrays or SAN systems or encryption of a tape or a VM image.

For laptops and transportable physical media (like tapes), this level of encryption is a great control. If the encrypted item is lost, stolen or thrown away, there’s no risk of exposure. As the keys for decrypting the data are inaccessible or elsewhere, no access to the media is possible. But it’s a poor data security control for use with systems that need access to sensitive information within a data center or cloud environment.

As soon as the system authorized to access the information is booted and in operation, no limits on access to data are provided by this level of solution. A compromise of the system can easily result in an immediate compromise of the sensitive data it has access to.

Yes – In a data center, this control can be implemented quickly (if turned on at deployment) and easily used to meet some compliance and regulatory requirements for protecting data. However, it’s an ineffective “check box” rather than useful protection in these environments.

The system layer: The next level of protection available is at the system level. Applying file or volume level encryption plus access controls and/or privileged access management.

File or volume level encryption and access controls protect against users at the system level having improper or unnecessary access to sensitive data. At their base level, they can be applied to protect against system level roles and privileged user access (even root users on Linux/Unix systems), LDAP/Active Directory roles/users, Hadoop users/groups/zones and container users and groups. These controls typically allow users and process that require access for their work or operation to see cleartext; all others see only ciphertext. Here’s an example for protecting a database file: Access to the database file is only authorized from a signed database process and user. All others are authorized to see only metadata or ciphertext.

This helps to meet needs for organizations with compliance requirements that mandate access controls or need to meet data breach safe harbor criteria so that if data is lost, and the encryption keys are not, no breach of private data is deemed to have taken place. Usually, these tools also include a secure audit and management capability required by best practices or compliance standards.

File level encryption and access controls are also a critical component of data security when deploying to Infrastructure as a Service (IaaS) cloud environments. When deployed with enterprise premises key management capability, they ensure that information stays under enterprise control, by excluding privileged access from cloud admin level users and controls. This also protects against compromise at the cloud provider or even a failure of the cloud provider, as without access to the encryption keys, no access to an enterprise’s data in the cloud is possible.

Privileged access management tools provide primarily complementary capabilities to file/volume encryption and access control solutions (with a typically rich set of features for managing how privileged users work). The solutions are complementary because PAM solutions lack an enforcement control to ensure that if information is improperly accessed it can’t be used, such as that provided by file/volume level encryption and access controls.

Last, file and volume level encryption and access controls are fairly quick and painless to deploy. Typically no changes to operations and user workflows are required. Once deployed, protection is in place, and operations otherwise continue “as usual.” They are often the best compromise of protection level and deployment/operational ease for existing applications because of this transparent operation - reducing attack surfaces available for system level threats with quick rollout and minimal impact on application operation and use.

Application and Database layer protections: While file level encryption and access controls protect well against system level threats, they are not designed to protect against improper access to data from within an application or database environment. To mitigate this next level or risk, tools that allow encryption of data, and access control from within applications and databases are needed.

These are best implemented when applications are first developed or are refreshed, as they typically require either application or database configuration changes (or both), that can be challenging to implement for a critical application while in operation. These controls include:

• Application encryption
• Database column encryption
• TDE Key Management
• Tokenization
• Data masking
• Database Access Monitoring

Each serves a separate need –

• Tokenization (for instance) is used both to take servers using credit card data out of audit requirements by replacing data with a “token” that represents the information, as well as for meeting needs to such as obscuring driver’s license numbers, national identity or insurance numbers, social security information. Controls coded within applications ensure that only authorized users can see real data, rather than a token.
• Application encryption is used to make it easy for programmers to add encryption to application data files or database columns when building new applications.
• TDE key management ensures that the master encryption keys used with native Oracle and SQL encryption capabilities are managed in a secure and compliant manner – ensuring that these database encryption methods aren’t compromised by poor key management.
• And database access monitoring watches patterns of access to information within the database by users to recognize accounts that may have been compromised.

The Cloud SaaS and Service layer: for the most part, Cloud SaaS applications are like a black box to enterprise customers. They can only use the service, not control how their information within the SaaS application is used, stored or protected. However, in the last few years, SaaS applications like Salesforce, Microsoft Office 365, AWS S3 storage and others have started to offer the capability to encrypt data within their environment, with enterprises keeping and controlling their encryption keys.

The result – regardless of where the data is physically stored, the enterprise controls access to it via control of their encryption keys. Cloud vendors are effectively barred from accessing enterprise data, and compromises or legal action at the cloud provider’s location can’t compel access to their information either. However, as SaaS vendors increasingly add this capability to their offerings, a new problem arises. As the typical enterprise now uses 25 to 50 or more SaaS applications (see this year’s Thales Data Threat Report), managing encryption keys and lifecycles can become a challenging problem.

To meet this need BYOK and cloud key management applications are available that make it easy to manage encryption keys and key lifecycles to meet compliance, best practice, and regulatory requirements.

Last note – This summary should give you a good starting point in deciding which security controls are required based on the needs of your organization. And “Yes” Thales has a strong, cost effective and well implemented