With new Snowden leaks dripping out on a semi-regular basis, surveillance programs like XKeyscore and PRISM are continuing to grab global headlines and promote a wave of heightened concern about data privacy and security. Businesses are scrambling to examine their own data security programs and some are considering making drastic moves like eliminating their use of US-based cloud service providers altogether or making data transfers to the US unlawful.
As the head of a Canadian-based company with customers around the world, I have been following these global security issues intently and I believe, while debate and discussion are essential, the challenge for all of us is making sure the hype doesn’t cloud the real issue. Things like “EU-only” clouds will not guarantee privacy and security. It’s the control of your sensitive data that helps you truly keep it safe – and keep your company compliant — not where your cloud provider is located.
Depending on where you’re doing business, regulations such as the UK Data Protection Act and the German Federal Data Protection Act – which are already in place – are definitive regarding who is responsible for data, even when it’s being handled by a third party. Control is essential no matter which regulations you need to comply with. So how do you achieve data control regardless of where your cloud service provider is located? Tokenisation holds the key.
Tokenisation is a process by which a sensitive data field, such as a Primary Account Number (PAN) from a credit or debit card, is replaced with a surrogate value called a token. De-tokenisation is the reverse process of redeeming a token for its associated original value.
While various approaches to creating tokens exist, frequently they are simply randomly generated values that have no mathematical relation to the original data field. This underlies the security of the approach – it is impossible to determine the original value of a sensitive data field by knowing only the surrogate token value.
While the technique has been used for years to isolate sensitive data within in-house systems, it is now being used by enterprises to keep data from migrating “in the clear” to the cloud. And importantly, enterprises can look to critical guidelines produced by the PCI DSS Security Standards Council to ensure they are deploying tokenisation techniques that are strong and well designed for enterprise use.
How Is Tokenisation Different From Encryption?
Encryption is an obfuscation approach that uses a cipher algorithm to mathematically transform sensitive data’s original value to an obscured surrogate value (known as ciphertext). Ciphertext can be transformed back to the original value via the use of a “key,” which can be thought of as the means to undo the mathematical lock.
So while encryption clearly can be used to obfuscate a value, a mathematical link back to its true form still exists. Tokenisation, when designed in accordance with the PCI DSS guidelines, takes data control to a new level and is unique in that it completely removes the original data from the systems in which the replacement tokens reside. As such, advantages of tokenisation are:
- Tokens cannot be reversed back to their original values without access to the original “look-up” table that matches them up to their original values. These tables are typically kept in a “hardened” database in a highly secure location inside a company’s firewalls.
- It eliminates the operational complexities associated with ongoing management of encryption keys.
- Tokens can be made to maintain the same structure and data type as their original values – which is beneficial in situations where cloud data needs to maintain formats (think of dates, ID numbers, for instance).
Since tokenisation truly replaces the original sensitive data (as opposed to “masking it” as encryption does), the benefit of a token from a data residency and data sovereignty compliance perspective is apparent – the data truly never leaves the enterprise’s location! Compliance and Risk professionals in many enterprises are seeing this as a critical difference versus encrypted ciphertext, which is still reversible back to the original data if an outside party gets access to the encryption keys.
That said, if an organisation does decide to pursue an encryption approach in order to protect sensitive information going to the cloud, it needs to ensure that industry standard best practices on the use of encryption are followed. As highlighted in the Cloud Security Alliance’s Guidelines as well as numerous Gartner reports, the use well-vetted strong encryption algorithms with published security proofs (such as NIST FIPS 140-2 validated modules) is a must.
In fact, a recent Gartner report titled “Tackle Six Security Issues Before Encrypting Data in the Cloud” states that encryption algorithms that have not been internationally recognized through appropriate standards should be avoided if they do not comply with regulatory requirements.
Later, the same report states “if the encryption vendor offers options for ‘function preserving encryption’ – for example, to preserve sort – regulations may require the use of standardised and approved algorithms or proof of independent certification for the potentially weakened encryption.”A good guideline for companies is to look for solutions that support the full use of FIPS 140-2 validated algorithms from well-known, established security providers (likely already being used within the enterprise to encrypt sensitive information internally in the organisation).
There is much to gain from using data replacement and obfuscation technologies to satisfy residency requirements in order to pave the way to cloud adoption. But equally, there is much to lose if the implementation is not well thought-through. Do your homework – consider tokenisation as an approach, and question any encryption techniques that are not well vetted and broadly accepted in the industry. By charting your path carefully at the beginning of your project, you can arrive at a solution that will fully meet the needs of your security, legal, and business-line teams.