The last several years have brought a significant increase to the number of regulations and requirements companies must meet to protect the ever-increasing data types we gather. Tokenization and encryption are two methods that secure and protect payment and sensitive data. It’s no longer a matter of “if” a business needs to secure data – it’s a matter of how they will do it.
Organizations must find ways to effectively and efficiently combine the myriad of financial and payment, Personal Health Information (PHI), and Personally Identifiable Information (PII) protection efforts into a single, holistic data protection plan that considers how data is entered, how it is transmitted and how it is stored.
Two of the most common and effective security solutions for securing and devaluing data are encryption and tokenization. This blog reviews the differences between encryption and tokenization, the types of data that require devaluation, and considerations when choosing a payment and data security solution.
Encryption vs. Tokenization – What’s the Difference?
Encryption, simply put, is taking a known piece of data and locking it up so that the data can only be retrieved with a key. In more technical terms, encryption uses an algorithm and a key to take the data and make it unreadable. Of course, this key must be controlled, typically called key management, to keep the data safe. If your data is “123,” and you encrypt the data with key “ABC,” resulting in “98zy65x,” and protect the key properly, all an attacker will be able to see is 98zy65x, which is useless to them.
Quantum Computing and its Implications on the Payments Industry
For a more detailed discussion on encryption types, including Asymmetric versus Symmetric encryption, view our payment security brief, “Quantum Computing and its Implications on the Payments Industry”.
Tokenization is taking a known piece of data and replacing it with a new random value. For example, the value “123” could be replaced with an unrelated value, such as “978.” In Tokenization vs. Encryption we’ll explore the two ways to tokenize data.
The older of the two methods maps a token in a database so that it can be retrieved, which is typically referred to as vaulted tokenization. This approach requires the database be properly secured and has limitations on scalability. The newer approach is known as vaultless tokenization and allows for greater speed and scalability. Vaultess tokenization is similar to encryption in that it also requires an algorithm to retrieve the original data. Both types of tokenization have value to organizations depending on different use cases and data security requirements.
Using Bluefin’s ShieldConex® for Data Protection
For a more detailed discussion on tokenization types, including Vaulted versus Vaultless tokenization, download our white paper authored by QSA Foregenix.
Tokenization vs. Encryption of Data Types – Transmitting, Storing and Protecting
As payments and data have moved to the digital space, the threats to online systems and processes have risen dramatically. Not only is a breach exposing clear-text data bad for customers and the brand, but it can be catastrophic from a regulatory perspective. These considerations are forcing organizations to look at what types of data they are gathering, how they are transmitting and storing that data, and how they are protecting each data piece.
Consideration: What Kind of Data are you Gathering?
The most common data types that may need protection include:
- Bank account and credit card information
- Social Security, driver’s license and passport numbers
- Medical or health information
- Names and signatures
- Address and telephone numbers
- Unique account names or personal identifiers, including email addresses
- Education or employment information
Unlike payment data, privacy data cannot be as easily narrowed down to cardholder data (CHD) or Account Data as payment security has done. However, as long as your organization can define what type of data needs protection, the same methods used to protect payment data – encryption and tokenization – can also be leveraged to protect privacy data.
Because these data types need to be protected and used by your organization, approaches such as format-preserving encryption (FPE) and format-preserving tokenization (FPT) rise to the top as some of the best options. Especially if the same tokenization solutions can be leveraged across both privacy and payment data. FPE and FPT offer a way to gain the benefits of encryption or tokenization and maintain existing data processing needs. Both FPE and FPT can create a new value of the same length and character boundaries for the different data types that payment data and privacy data encompass.
Consideration: How are you Transmitting and Storing Data?
COVID-19 forced millions of businesses to pivot to a mobile and Ecommerce model. But with that pivot came more payment and data acceptance endpoints for hackers to target.
The movement of sensitive data includes the initial input of data at the point-of-sale (POS) or online, and then the transmission of that data between any two systems, regardless of what the need for movement is. This data can be transmitted as clear-text data, or as encrypted data. When sending un-encrypted or clear-text data that is sensitive, it is possible to encrypt the channel or tunnel over which the data is transmitted. Additionally, the point where the data originates and the point where the data is sent then have to handle this clear-text data appropriately.
There are multiple challenges in doing this, so when possible, sending either fully encrypted or tokenized data makes this process much simpler and more secure. From a security perspective, what remains in this scenario is to secure the keys and the authentication processes.
P2PE in POI Environments: Scope, Cost, Benefits and Implementation
For a more detailed discussion on encrypting data at the POS, including PCI-validated point-to-point encryption (P2PE), download our white paper authored by Verizon.
There are different reasons to store sensitive data. If you have a defined business need to store sensitive data, then you need to encrypt and tokenize that data and limit who has access to the data. Looking at CHD as an example, PCI has specific and strict requirements for how to store sensitive data. One of the best ways to reduce the scope of your compliance reviews is to minimize or reduce what data you store, and where you store that data. Tokenization can be leveraged in many cases to maintain access to data as needed, and still remove the data from your environment.
Nacha and PCI Payment Security: Navigating the Crossover in Compliance with 2021 Nacha Data Regulations.
For a more detailed discussion on how PCI requirements map to sensitive data protection, download our payment security brief.
Encryption or Tokenization Considerations When Choosing a Solution
There are several key components a business must consider when formulating a payment and data protection strategy.
- The ability to secure multiple data types, including financial data such as CHD and ACH Account Data, and privacy data such as PHI and PII
- The capacity to secure data with multiple security technologies, including encryption, tokenization, EMV for POS / 3DS for Ecommerce
- An option to secure multiple types of data input, including physical access (CP) such as card-present via devices, attended and unattended, and virtual access (CNP) such as web/Ecommerce, call centers, and mobile
- The capability to leverage iFrame technologies and secure hosted fields to support in-page tokenization
- The requirement implement into IT environments that have multiple segments and different infrastructures
- The technique to simplify the scope of data secured within an environment
- Availability to support multiple third-party vendors
- The change to apply each of the above in a single solution, including centralized management and awareness of all data, secured
Bluefin’s P2PE and ShieldConex® Solutions
Bluefin’s payment and data security suite offers a full, omnichannel approach to security at the POS and online. Our PCI-validated P2PE solutions for the POS and ShieldConex data security platform for online data can be quickly implemented through several options to secure both CHD at the POS, and CHD, ACH, PII and PHI intake online.
PCI-validated P2PE leverages the PCI P2PE industry standard to secure payment data immediately upon dip, tap, swipe or key entry in a PCI-approved P2PE payment terminal. ShieldConex leverages industry standard tokenization and hardware-based encryption methodologies that can take input from any online format and allow the flexibility to use and access the data without exposing the data insecurely. ShieldConex is vaultless, meaning that Bluefin never stores any of the sensitive data. Only the organization using ShieldConex can access the original data in a secure, scalable, and fast way.
With a cloud-based approach, ShieldConex can easily be integrated into multiple IT environments and through different third parties connected to an organization’s infrastructure, working with P2PE in the process. Key benefits include:
- Omni-channel tokenization
- FPE and FPT
- iFrame technology for in-page tokenization
- A global approach that supports direct and partner integrations
- Flexible access to all data types while maintaining data security
- Reduction of scope for security and compliance regulations and frameworks
- Scalability for changing data security needs
- High speed, secure access to sensitive data
Using ShieldConex in conjunction with P2PE adds the protection of physical data entry needs and offers industry-standard encryption for additional data types, particularly payment data. Doing this all under one integrated solution offering can dramatically reduce the scope and simplify the management of multiple security and compliance frameworks.
Contact us for more information on how Bluefin leverages our encryption and tokenization solutions for omnichannel payment and data protection.
