Sergey Galushko - Fotolia
Establish a data classification model for cloud encryption
Not all data requires the same level of encryption. Use data classification to gauge your security needs, including for workloads that span on-premises and cloud environments.
Data encryption might seem like a given in any IT security strategy, but it still requires proper management techniques to get right. Encryption in the cloud is no exception.
In fact, encryption requires a fair amount of resources to implement. Enterprises, for example, must capture data at a given time -- as close to its point of creation as possible -- and take a series of actions to carry out encryption. What's more, encryption and decryption introduce latency, which organizations need to minimize for many workloads.
Of course, none of these challenges mean an organization should overlook encryption altogether. Rather, they should follow the guidelines below to make it a little easier to manage.
Implement a data classification model
Data classification is a good way to deal with the challenges of encryption and avoid unnecessary latency. It's also especially helpful to handle data and information that spans a complex hybrid cloud architecture.
For example, let's say an organization works with both customers and vendors. Many of those vendors also have vendors of their own. The organization also has a mix of direct employees, contractors and consultants. There is a constant flow of data across this value chain and the organization needs to ensure that only the right people can access the right bits of information.
While some enterprises define up to five classes of data, the data classification model for this simple example will probably use one of the following three:
Open/public. Most of the organization's internal information, such as training documents for new employees, can be classified as open or public. This class of data is not worth encrypting.
Commercial in confidence. Information that the organization shares with its customers or suppliers is more sensitive than the internal data we classified as open. For example, much of this information will be contractual, and you don't want an agreement with one vendor to be seen by another vendor. This data can be classified as commercial in confidence, and IT teams should encrypt it as early as possible.
For your eyes only. For information that's even more sensitive than that in the commercial in confidence class, such as financial information regarding a possible merger or acquisition, it's best to classify as for your eyes only. This is information that could negatively affect a company's bottom line if seen by unauthorized parties. Again, IT teams should encrypt this class of data as early as possible before they store it, particularly in a cloud-based storage system.
More data classification strategies
It's common for some organizations to try to apply a data classification model to existing documents. This is possible, but it can result in false positives and negatives, where, for example, information that should be classified as for your eyes only does not trigger the system and gets classified instead as open. Instead, it's better to start with templates.
For example, rather than having a user create a new form in his or her chosen office suite, provide a menu of options to choose from ranging from more formal documents to just a blank doc.
Behind the scenes, a data classification model should include metadata that sticks with the newly created document throughout its life. This requires an organization to permanently link the document with immutable metadata -- which is where information management systems, such as those from M-Files and FileHold, come into play.
By having users choose a template with its associated metadata, data can then be encrypted as required before it hits any storage media, whether that is a local device, an on-site system or a cloud platform. Anything that isn't open/public -- sticking with the example above – will then be encrypted or dealt with using virtual private networks (VPNs). This approach can also help a business determine if data should primarily be held on premises or in the cloud.
Fall back on your VPN
For low-latency data streams, one option is to have unencrypted data flow across an encrypted pipe, such as a VPN. VPNs are a good way to pass data between organizations if you lack an agreed-upon encryption approach -- the data will still look encrypted and is protected from outside access.
Be sure to fully monitor the VPN, as well as those who use it. Pattern matching can help identify where brute force, distributed denial-of-service or other malicious activities are present. Also, make sure you can easily block not only individuals, but whole groups -- such as employees, contractors and consultants -- if needed.
Once the basic metadata is created in an immutable manner, users can add extra metadata for further classification. For example, a document that has immutable metadata of commercial in confidence could have extra immutable metadata of supplier contract.
Never assume that a cloud platform or SaaS application will handle the intricacies of encryption for you; unless your entire cloud environment operates under a VPN connection, there will be data transported via a public connection from users' devices to cloud applications -- where it's susceptible to potential attacks.
Enterprises should also consider data leak protection and data rights management to keep data secure as it spans on premises and the cloud.
