Three principles regarding encryption you need to keep in mind

Encryption is a popular topic among security professionals and occasionally a polarizing one. Plenty of misconceptions surround the process, and these often skew the way people perceive its complexity.

For instance, we’ve encountered many IT and business leaders who assume that because they can’t encrypt one piece of important information (e.g., the birth date of a contact), it’s not worth encrypting any information at all. This is a ridiculous logical leap, but it’s not uncommon.

Others assume that encrypting fields makes them useless. You can’t report on encrypted fields, right? Relax! You can include them in reports perfectly fine; you just won’t be able to filter them in quite the same way you’re used to.

While everyone has his own opinion about what users should see when they look at an encrypted data point, it’s important to note that platform encryption occurs at the disk level. It’s basically fully transparent to end users when done correctly.

There’s also disagreement about which of the platform encryption schemes is more secure. A lot of people think that deterministic encryption is less secure than probabilistic schemes, and I respectfully disagree. Deterministic and probabilistic schemes use the same algorithm and generally do the same things. The former just allows for a little bit more system functionality.

These misconceptions aren’t inherently problematic, but they can negatively impact organizational security if they persist for too long.

Perception and reality

Encryption isn’t a solution – it’s a tool. If you assume that buying encryption will allow you to hide data from internal users, you’re missing the point. Disk-level encryption has nothing to do with internal user visibility – it’s just one component of what should be a comprehensive approach to data security to protect against database-level data loss.

In order to deploy encryption effectively, security professionals first need to have a complete understanding of the information they have in their system. Then they need to classify that information in a way that shows exactly which fields need encrypting, and which might not, in accordance with the organization’s policies.

Inevitably, you’ll run into platform limitations when you decide to encrypt fields. Always make sure you fully understand the side effects of encrypting before you proceed with it. Take these warnings seriously but know that encryption is not as complex and scary as you might think. Plus, plenty of tools are available to help you streamline the process.

If you’re a CIO or security leader wondering whether you should include encryption as part of a robust organizational security strategy, here are three principles to keep in mind:

1. Context matters

Oftentimes, data on its own isn’t valuable, but when it resides next to other data, that could change. For instance, if you have a table or object called “Social Security Number” that contains 600 million Social Security numbers and nothing else, there’s very little value in that. It’s just 600 million nine-character numbers. When each of those numbers sits alongside a first and last name, however, that’s a whole different story. Always consider how data is co-located with other data before proceeding with encryption.

2. Classify, then encrypt

Understanding context is possible only with thorough data classification. The prototypical client will buy a platform encryption tool and declare that every field must now be encrypted. Pump the brakes! You don’t need or want to encrypt every single field. Instead, follow this approach: “Stop, think, assess, and proceed.” It’s critical to understand the side effects of encryption before you encrypt; otherwise, you’ll create more work for yourself at best and a very big problem at worst. Don’t dive into the deep end of the pool if you can’t swim.

3. Keep the end in mind

It bears repeating: encryption is just one component of your organization’s broader security posture. Have a baseline objective for platform security and some way to measure progress toward that objective. For example, if you want to improve the security of your Salesforce instance, you first need to locate gaps or deficiencies. Talk to your security, compliance, and legal teams about how you’re using Salesforce and how you want to use it in the future.

What’s keeping you from getting there? Don’t begin making changes until you know what you want in terms of data protection. Data inventory is a good starting point, and a platform like Salesforce has many of the features and functions you need to ensure your organization’s data is secure. Take advantage of those before implementing your own well-intentioned ideas.

Encryption can be a valuable security tool and might not be quite as complex as you’ve heard. However, it’s not a security panacea and you shouldn’t treat it like one. Instead, understand what you want your security posture to look like at a high level and decide whether encryption can help you achieve that. Understanding the misconceptions about the process will help you to make the best decision possible and just maybe will save you from some serious headaches.