What is Data Security?

Encryption and Decryption Process

Types of Encryption
Tokenization
Encryption vs Tokenization
Other Data Security
Encryption and Tokenization currently present in Bank
Vulnerabilities current present in Bank

What is data security?

Data security is the practice of protecting digital information from unauthorized access, corruption, or theft throughout its entire lifecycle.

It’s a concept that encompasses every aspect of information security from the physical security of hardware and storage devices to administrative
and access controls, as well as the logical security of software applications. It also includes organizational policies and procedures.

Data security—Those controls that seek to maintain confidentiality, integrity and availability of information

“Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on.”
– Edward Snowden

Why is data security important?

When properly implemented, robust data security strategies will protect an organization’s information assets against cybercriminal activities, but
they also guard against insider threats and human error, which remains among the leading causes of data breaches today.

Data security involves deploying tools and technologies that enhance the organization’s visibility into where its critical data resides and how it is
used. Ideally, these tools should be able to apply protections like encryption, data masking, and redaction of sensitive files, and should automate
reporting to streamline audits and adhering to regulatory requirements.
Encryption Definition

Encryption is the process of using an algorithm to transform plain text information into a non-readable form called ciphertext. An algorithm and an
encryption key are required to decrypt the information and return it to its original plain text format.

Encryption and Decryption Process

Key Elements of Encryption Systems

1. Encryption algorithm—A mathematically based function that encrypts/decrypts data

Encryption algorithm Attacks can also be mounted against the robustness of the underlying mathematical algorithms to speed up the brute
forcing process.
 2. Encryption keys—A piece of information that is used by the encryption algorithm to make the encryption or decryption process unique.
Similar to passwords, a user needs to provide the correct key to access or decrypt a message. The wrong key will decipher the message into
an unreadable form.

3. Key length—A predetermined length for the key. The longer the key, the more difficult it is to compromise in a brute force attack.
Key length Because the amount of time required to search for the correct key depends exponentially on its length, it is fundamental to
choose the key adequately to ensure the overall security of encryption scheme.

Encryption schemes are susceptible to brute force attacks in which an attacker repeatedly tries to decrypt a piece of ciphertext using all the possible
encryption keys until the correct one is found (i.e., brute forcing stops when the ciphertext does not decrypt to a non-sense message).

Types of Encryption

Symmetric Encryption

There are two primary approaches to encryption: symmetric key and asymmetric key encryption. In symmetric key encryption, one key is used to
both encrypt and decrypt the information. Symmetric key encryption is analogous to the key used to both unlock and lock the door to a house. The
big drawback of this approach is that if the key is compromised, it can be used to unlock, or decrypt, all of the data it was used to secure. For this
reason, asymmetric key encryption was developed to allow multiple parties to exchange encrypted data without managing the same encryption key.
Asymmetric Encryption
In asymmetric key encryption (also called public-key encryption), two different keys are used for the encryption and decryption processes. The public
key can be freely distributed since it is only used to lock the data and never to unlock it. For example, a merchant can use a public key to encrypt
payment data before sending a transaction to be authorized by a payment processing company. The latter company would need to have the private
key to decrypt the card data to process the payment. Asymmetric key encryption is also used to validate identity on the Internet using SSL certificates.
Regardless of what type of key is utilized, users of encryption typically practice regular key rotation in order to reduce the likelihood of a compromised
key being used to decrypt all sensitive data. Rotating keys limits the amount of data that’s encrypted using a single key. In the event that an encryption
key is compromised, only data encrypted with that key would be vulnerable.

Until now, one of the drawbacks of encrypting data within applications is that encryption breaks application functionality such as sorting and
searching. Because cipher text is in a different format from the original data, encryption may also break field validation if an application requires
specific formats within fields such as payment card numbers or email addresses. New order-preserving, format-preserving, and searchable encryption
schemes are making it easier for organizations to protect their information without sacrificing end user functionality within business-critical
applications. However, there is usually a tradeoff between application functionality and the strength of encryption.

Encryption Schemes and Their Relative Strengths and Weaknesses

In the aftermath of the unauthorized release of sensitive National Security Agency (NSA) documents in 2014, the focus on encryption for enterprise
data in the cloud, and for software-as-a-service (SaaS) providers, has risen to the forefront of many information security conversations. Industry
analysts have labeled this trend the “Snowden Effect,” and it has resulted in dramatic shifts in cloud-related security requirements and, in extreme
cases, hindered the adoption of cloud services themselves.
As Edward Snowden’s revelations add concern to preexisting compliance and privacy requirements, companies are increasingly looking for encryption
capabilities that protect their data in the cloud via company-owned encryption keys, while still preserving the functionality of the underlying cloud
applications. Enterprises have chosen to leverage cloud services because of their simplicity and cost-effectiveness. However, concerns over
government inspection of data, service provider breaches, and insufficient access controls have driven increasing use of cryptographic techniques
for protecting data in the cloud.

The increased demand for enhanced data security has driven the adoption and implementation of several
new(er) encryption algorithms such as searchable, format-preserving, order-preserving, and homomorphic
encryption schemes. While this demand has spurred innovation and led to some creative solutions, it has also created widespread confusion and
misleading vendor claims as to what is truly feasible from a data protection standpoint.

This paper aims to help practitioners understand the tradeoffs when using different types of encryption, and choose the right schemes for protecting
cloud storage applications. We consider the setting where only the client holds the key; hence, we focus on symmetric key encryption, as opposed
to public key schemes.

Regular (Unstructured) Data Encryption

- hide all useful information about the data

- no one can tell if two ciphertexts correspond to equal messages
- provide data integrity and sender authenticity
 - should be used for the most sensitive data requiring the highest security

- strong security severely impacts application functionality

- several features of a SaaS application typically cease functioning. Specifically, search, document preview, graphically rendered report data,
logical operations, and mathematical calculations

Selective Encryption

- only encrypt sensitive data to ensure regulatory compliance, while leaving other data unencrypted to preserve as much of the application
functionality as possible.
- often used to encrypt data within collaborative content-sharing applications, intranets, or extranets
Format-Preserving Encryption (FPE)

- encryption method that preserves the length and the format of the original text.
- application’s field validation rules still function correctly, while the underlying data remains encrypted.
- cannot provide data integrity and sender authenticity.

Searchable Encryption
 - common security weakness: equality of keywords is leaked, making certain statistical attacks possible.

Different approaches to enable secure search for keywords for cloud services

Keyword extraction
keyword search preserved on encrypted documents
Word-by-word
Partial searches will not function. Complete words or strings must be passed intact to succeed

Local search tokenization

functions by creating a local plaintext index of search words as data and sent to a cloud provider.
search terms entered by a user are looked up against the local search index, which then returns the results

Search by prefix
Search for keywords by specifying a common prefix
For example, when a user searches for ‘McD*’, they may be looking for McDonald’s, McDougal, and McDouglass.

Order-Preserving Encryption (OPE)

Able to index, search, and sort encrypted data in external servers

Data Tokenization
involves creating tokens for each plaintext, storing the data and tokens locally, and then passing the tokens to the cloud application
local storage for the data and the corresponding tokens should be protected.
database must also be accessible by users, and thus may cause issues for remote or mobile user

Fully Homomorphic Encryption

method of encryption that allows for encrypted ciphertexts to be computed over by an untrusted party.
Tokenization definition

Tokenization is the process of turning a meaningful piece of data, such as an account number, into a random string of characters called a token that
has no meaningful value if breached.
Tokens serve as reference to the original data, but cannot be used to guess those values. That’s because, unlike encryption, tokenization does not
use a mathematical process to transform the sensitive information into the token.

There is no key, or algorithm, that can be used to derive the original data for a token. Instead, tokenization uses a database, called a token vault,
which stores the relationship between the sensitive value and the token. The real data in the vault is then secured, often via encryption.

The token value can be used in various applications as a substitute for the real data.

If the real data needs to be retrieved – for example, in the case of processing a recurring credit card payment – the token is submitted to the vault
and the index is used to fetch the real value for use in the authorization process. To the end user, this operation is performed seamlessly by the
browser or application nearly instantaneously. They’re likely not even aware that the data is stored in the cloud in a different format.
This is an example only that illustrates one possible tokenization process for following PCI DSS Payment Card Industry – Data Security Standard. Each
solution should be individually evaluated to understand its particular processes and data flows. The steps illustrated in this example include:
1. A requesting application passes a PAN Primary Account Numbers PAN stands for Primary Account Number, and it is a key piece of cardholder
data you are obligated to protect under the PCI DSS, along with necessary authentication information, to a tokenization system.
2. The tokenization system verifies the authentication information presented by the requesting application. If this check fails, the tokenization process
fails, and information is logged for monitoring. Otherwise, the process continues to Step 3.
3. The tokenization system generates—or retrieves if already exists—a token associated to the PAN and records both to the card data vault, following
PCI DSS Payment Card Industry – Data Security Standard requirements for PAN storage.
4. The tokenization system returns the token generated or retrieved in Step 3 to the requesting application.
The advantage of tokens is that there is no mathematical relationship to the real data they represent. If they are breached, they have no meaning.
No key can reverse them back to the real data values. Consideration can also be given to the design of a token to make it more useful.

For example, the last four digits of a payment card number can be preserved in the token so that the tokenized number (or a portion of it) can be
printed on the customer’s receipt so she can see a reference to her actual credit card number. The printed characters might be all asterisks plus those
last four digits. In this case, the merchant only has a token, not a real card number, for security purposes.

Tokenization vs Encryption

Tokenization and encryption are often mentioned together as means to secure information when it’s being transmitted on the Internet or stored at
rest. In addition to helping to meet your organization’s own data security policies, they can both help satisfy regulatory requirements such as those
under PCI DSS, HIPAA-HITECH, GLBA, ITAR, and the EU GDPR. While tokenization and encryption are both effective data obfuscation technologies,
they are not the same thing, and they are not interchangeable. Each technology has its own strengths and weaknesses, and based on these, one or
the other should be the preferred method to secure data under different circumstances. In some cases, such as with electronic payment data, both
encryption and tokenization are used to secure the end-to-end process.

Encryption Tokenization

Mathematically transforms plain text into cipher text using an Randomly generates a token value for plain text and stores the
encryption algorithm and key mapping in a database

Scales to large data volumes with just the use of a small encryption Difficult to scale securely and maintain performance as database
key to decrypt data increases in size

Used for structured fields, as well as unstructured data such as entire Used for structured data fields such as payment card or Social
files Security numbers

Ideal for exchanging sensitive data with third parties who have the Difficult to exchange data since it requires direct access to a token
encryption key vault mapping token values
 Encryption Tokenization

Format-preserving encryption schemes come with a tradeoff of Format can be maintained without any diminished strength of the
lower strength security

Original data never leaves the organization, satisfying certain

Original data leaves the organization, but in encrypted form
compliance requirements

Other Data Security

Hashing
▪ process of converting an input of variable length to a fixed size array of numbers and letters using a mathematical function.
▪ one-way function where a unique message digest is generated from an input file or a string of text. No keys are used.
▪ Output can’t be reverted to the original message.
▪ Examples of hashing algorithms: SHA-1 (digest 160 bits), SHA-2 (512bits), MD5 (128bits), Tiger (64 bits), etc
▪ The objective of using hashing is to verify data (i.e., protect data integrity)

Hashing vs Encryption

The table below lists the differences between hashing and encryption:
 Encryption Hashing

Encryption is a two-way function where information is scrambled

Hashing is a one-way function where a unique message digest is generated from
using an encryption key and unscrambled later using a
an input file or a string of text. No keys are used.
decryption key.

Hashing is the process of using hash functions on data to map it to a fixed size
The message is encoded in a way that only authorized parties
output. It’s similar to a checksum and is used for verifying file integrity. Hashing
can access it. It’s used to prevent unauthorized users from
is useful where you want to compare an entered value with a stored value without
reading data from a file by rendering it into an unreadable form.
needing to read the original content of the file.

The resultant encrypted string is of a variable length. The resultant hashed string is of a fixed length.

Output can’t be reverted to the original message. The best hashing algorithms
The original message can always be retrieved by using the
are designed in a way that makes it virtually impossible to retrieve the original
appropriate decryption key.
string from the hash value.

There are two primary types of encryption: Symmetric key

encryption (or private key encryption) and Asymmetric key Examples of hashing algorithms: SHA-1 (digest 160 bits), SHA-2 (512bits), MD5
encryption (or public key encryption) Examples of encryption (128bits), Tiger (64 bits), etc
algorithms: RSA, AES, DES, etc.

Purpose of encryption is to transmit data securely (i.e., protect

The objective of using hashing is to verify data (i.e., protect data integrity)
data confidentiality)

Data Masking
▪ process of replacing original production data with structurally similar, inauthentic data.
▪ The format of the data remains the same, but the values are altered.
▪ The alteration may take place through encryption, word or character shuffling, or substitution.
▪ is a one-way process that retrieves the original data or reverse engineering to obtain the original data impossible.
Encryption and Tokenization currently present in Bank

◎ Secure Sockets Layer (SSL) encryption

◎ Transport Layer Security (TLS) encryption
◎ Secure/Multipurpose Internet Mail Extensions (S/MIME)

Use cases for encryption

Today, SSL encryption is commonly used to protect information as it’s transmitted on the Internet. Using built-in encryption capabilities of operating
systems or third party encryption tools, millions of people encrypt data on their computers to protect against the accidental loss of sensitive data in
the event their computer is stolen. And encryption can be used to thwart government surveillance and theft of sensitive corporate data.

While encryption can be used to secure structured fields such as those containing payment card data and PII

Personal Identifiable Information (PII) is defined as:

Any representation of information that permits the identity of an individual to whom the information applies to be reasonably inferred by either direct
or indirect means. Further, PII is defined as information: (i) that directly identifies an individual (e.g., name, address, social security number or other
identifying number or code, telephone number, email address, etc.) or (ii) by which an agency intends to identify specific individuals in conjunction with
other data elements, i.e., indirect identification. (These data elements may include a combination of gender, race, birth date, geographic indicator, and
other descriptors).

, it can also used to secure unstructured data in the form of long textual passages, such as paragraphs or even entire documents.

Encryption is also the ideal way to secure data exchanged with third parties and protect data and validate identity online, since the other party only
needs a small encryption key. SSL or Secure Sockets Layer, the foundation of sharing data securely on the Internet today, relies on encryption to
create a secure tunnel between the end user and the website. Asymmetric key encryption is also an important component of SSL certificates used to
validate identity.
What is an SSL certificate?

An SSL certificate is a digital certificate that authenticates a website's identity and enables an encrypted connection. SSL stands for Secure Sockets Layer,
a security protocol that creates an encrypted link between a web server and a web browser.

In short: SSL keeps internet connections secure and prevents criminals from reading or modifying information transferred between two systems. When
you see a padlock icon next to the URL in the address bar, that means SSL protects the website you are visiting.
The process works like this:

1. A browser or server attempts to connect to a website (i.e., a web server) secured with SSL.
2. The browser or server requests that the web server identifies itself.
3. The web server sends the browser or server a copy of its SSL certificate in response.
4. The browser or server checks to see whether it trusts the SSL certificate. If it does, it signals this to the webserver.
5. The web server then returns a digitally signed acknowledgment to start an SSL encrypted session.
6. Encrypted data is shared between the browser or server and the webserver.
7. This process is sometimes referred to as an "SSL handshake." While it sounds like a lengthy process, it takes place in milliseconds.

When a website is secured by an SSL certificate, the acronym HTTPS (which stands for HyperText Transfer Protocol Secure) appears in the URL. Without
an SSL certificate, only the letters HTTP – i.e., without the S for Secure – will appear. A padlock icon will also display in the URL address bar. This signals
trust and provides reassurance to those visiting the website.

Since its inception about 25 years ago, there have been several versions of SSL protocol, all of which at some point ran into security troubles. A revamped
and renamed version followed — TLS (Transport Layer Security), which is still in use today. However, the initials SSL stuck, so the new version of the
protocol is still usually called by the old name.
Encrypt: Your message stays encrypted and doesn’t leave Microsoft 365. Recipients with Outlook.com and Microsoft 365 accounts can download
attachments without encryption from Outlook.com, the Outlook mobile app, or the Mail app in Windows 10. If you're using a different email client
or other email accounts, you can use a temporary passcode to download the attachments from the Microsoft 365 Message Encryption portal.

Encrypt and Prevent Forwarding: Your message stays encrypted within Microsoft 365 and can’t be copied or forwarded. Microsoft Office attachments
such as Word, Excel or PowerPoint files remain encrypted even after they’re downloaded. Other attachments, such as PDF files or image files can be
downloaded without encryption.

TLS (Transport Layer Security) is a cryptographic protocol that enables authenticated connections and secure data transport over the internet via HTTP.
A direct evolution of Secure Socket Layers (SSL)

How is this different from the current level of encryption in Outlook.com?

Currently, Outlook.com uses opportunistic Transport Layer Security (TLS) to encrypt the connection with a recipient’s email provider. However,
with TLS, the message might not stay encrypted after the message reaches the recipient’s email provider. In other words, TLS encrypts the connection,
not the message.

Additionally, TLS encryption didn’t provide the ability to preventing forwarding.

Messages encrypted with Microsoft 365 stay encrypted and remain inside the Microsoft 365 Personal. This helps secure your email when it’s received.

Want to add a padlock to your email messages? You can use S/MIME (Secure/Multipurpose internet Mail Extensions in Outlook Web App to increase
the security of messages. A digitally encrypted message can only be opened by recipients who have the correct key. A digital signature assures
recipients that the message hasn’t been tampered with.
Get a certificate.

The first step to use S/MIME is to obtain a certificate, also called a digital ID, from your organization’s administrator. Your certificate may be stored
on a smart card, or may be a file that you store on your computer. Follow the instructions provided by your administrator to use your certificate.

How do I verify the signature of a digitally signed message?

A ribbon icon in the message list or reading pane indicates a digitally signed message.

Secure/Multipurpose Internet Mail Extensions (S/MIME) is another encryption standard that uses both public and private-key encryption to offer a
high degree of security.

The objective of this data encryption is to prevent Message Tampering, Repudiation, Eavesdropping, Privacy Invasion, Unprotected Backups, Identity
Theft

Use cases for tokenization

The most common use case for tokenization is protecting payment card data so that merchants can reduce their obligations under PCI DSS.

>>what chinabank products or systems uses tokenization??

>> check audit of credit card – ASCEND
>>does it meet the PCI DSS standards?

Review of ASCCEND System

Payment Card Industry – Data Security Standard (PCI DSS ) Remarks

 Protect cardholder data
3.4 Render PAN unreadable anywhere it is stored (including on portable digital
media, backup media, and in logs) by using any of the following approaches:
• One-way hashes based on strong cryptography, (hash must be of the entire
PAN)
• Truncation (hashing cannot be used to replace the truncated segment of
PAN)
• Index tokens and pads (pads must be securely stored)
• Strong cryptography with associated key-management processes and
procedures.
Primary Account Numbers (PANs) are stored in plain-text
format in the Bank’s Data Warehouse and Credit Card
Repository.
Non-compliance with PCI DSS requirements may potentially
result to liability shift against the Bank, should a fraudulent
transaction take place.

Encryption can also be used to secure account data, but because the data is still present, albeit in ciphertext format, the organization must ensure
the entire technology infrastructure used to store and transmit this data is fully compliant with PCI DSS requirements. In 2011, the Payment Card
Industry Security Standards Council (PCI SSC), the organization responsible for enforcing PCI DSS, issued a set of tokenization guidelines. While the
guidance has not yet been added to the official PCI DSS standard, qualified PCI assessors now accept tokenization as a viable solution to meet
requirements under the standard.

Increasingly, tokens are being used to secure other types of sensitive or personally identifiable information, including social security numbers,
telephone numbers, email addresses, account numbers and so on. The backend systems of many organizations rely on Social Security numbers,
passport numbers, and driver’s license numbers as unique identifiers. Since this unique identifier is woven into these systems, it’s very difficult to
remove them. And these identifiers are also used to access information for billing, order status, and customer service. Tokenization is now being
used to protect this data to maintain the functionality of backend systems without exposing PII to attackers.

Review of VAPT Process

 Risk Status
# Vulnerability Risk
Rating as of April 30, 2021

1 IPMI (It is a hardware solution for controlling High Vulnerable – 5 Possible to remotely harvest password
and managing servers) v2 Password Hash hashes and also allows cipher zero to
Disclosure authenticate to the IPMI interface.

2 SMTP (Simple Mail Transfer Protocol and its High Vulnerable – 2 Possible to remotely harvest password
primary purpose is to handle the sending, hashes and also allows cipher zero to
receiving, and relaying of email) authenticate to the IPMI interface.

SMTP EXPN/VRFY verbs enabled

The remote SMTP server answers to the EXPN
and/or VRFY commands.

The EXPN command can be used to find the

delivery address of mail aliases, or even the full
name of the recipients, and the VRFY command
may be used to check the validity of an account.

Your mailer should not allow remote users to

use any of these commands, because it gives
them too much information.

If you are using Sendmail, add the option :

O PrivacyOptions=goaway

in /etc/sendmail.cf.
 Service Multiple Vulnerabilities

3 FTP (process that involves the transfer of files High Vulnerable – 13 The servers are running on an unencrypted
between devices over a network. FTP was not Fixed - 1 protocol, FTP, where sensitive information
built to be secure. It is generally considered to such as credentials are in cleartext.
be an insecure protocol because it relies on
clear-text usernames and passwords for
authentication and does not use encryption.
Data sent via FTP is vulnerable to sniffing,
spoofing, and brute force attacks, among other
basic attack methods) Service is enabled

4 Telnet (Telnet is inherently insecure. Credential High Vulnerable – 11 The servers are running on an unencrypted
information (usernames and passwords) Fixed - 1 protocol, Telnet, where sensitive
submitted through telnet is not encrypted and information such as credentials are in
is therefore vulnerable to identity theft. cleartext.
However, users can establish an Secure Shell
connection instead to prevent this type of
intrusion) Service is enabled

5 SSL/TLS Certificate is Expired Medium Vulnerable – 29 The certificate becomes invalid, and will no
Fixed - 1 longer be able to run secure transactions on
SSL certificates do expire once their validity the website.
period is over, from 1-2 years

After an SSL certificate expires, you will no

longer be able to communicate over a secure,
encrypted HTTPS connection.
 All the information will be transmitted in
plaintext, leaving your (or your customer's)
data exposed to any attacker listening in on the
network.
6 SSL/TLS Certificate using Weak Hashing Algorithm Medium
7 SSL/TLS Weak Protocols Supported Medium
TLS 1.2 is currently the most widely-used
version of the SSL/TLS protocol, TLS 1.3 (the
latest version) is already supported in the
current versions of most major web browsers.
While TLS 1.0 & TLS 1.1 are known to be very
vulnerable, the TLS 1.2 protocol is considered
to be much more secure and is thus
recommended for use
8 SSL/TLS Weak Ciphers Supported Medium
Organizations should avoid TLS versions 1.1
and below and RC4 encryption, as there have
Vulnerable – 99 The affected servers uses an SSL certificate
chain that has been signed using a
cryptographically weak hashing algorithm
(e.g. MD2, MD4, MD5, or SHA1). These
signature algorithms are known to be
vulnerable to collision attacks.
Vulnerable – 156 The targeted server accepts connections for
cryptographically weak SSL/TLS protocol
versions, SSLv3, TLS 1.0. SSLv3 and TLS 1.0
are vulnerable in many implementations to
a couple well-known attacks such as BEAST,
POODLE (Padding Oracle On
Downgraded Legacy Encryption). There's
also some crypto issues in TLS 1.0, such as
cryptograhpic initialization vectors (IV's)
being predictable in some implementations
as well (EOL: June 30,2018).
Vulnerable – 182 The remote host is running with the
Fixed – 8 following weak cipher which has multiple
vulnerabilities such as:
- medium strength cipher
- RC4 ciphers
 been multiple vulnerabilities discovered that - weak key strength ciphers
render it insecure. The best way to ensure - export ciphers
strong transport layer security is to support TLS - anonymous ciphers
1.3, which is the most secure and up-to-date - null ciphers
version of TLS

Choose only cipher suites that offer at least

128-bit encryption, or stronger when possible.

Encryption and tokenization are both regularly used today to protect data stored in cloud services or applications. Depending on the use case, an
organization may use encryption, tokenization, or a combination of both to secure different types of data and meet different regulatory requirements.

As more data moves to the cloud, encryption and tokenization are being used to secure data stored in cloud services. Most notably, if a government
agency subpoenas the data stored in the cloud, the service provider can only turn over encrypted or tokenized information with no way to unlock
the real data. The same is true is a cyber-criminal gains access to data stored in a cloud service.

Tokenization and encryption are often mentioned together as means to secure information when it’s being transmitted on the Internet or stored at
rest. In addition to helping to meet your organization’s own data security policies, they can both help satisfy regulatory requirements such as those
under PCI DSS, HIPAA-HITECH, GLBA, ITAR, and the EU GDPR. While tokenization and encryption are both effective data obfuscation technologies,
they are not the same thing, and they are not interchangeable. Each technology has its own strengths and weaknesses, and based on these, one or
the other should be the preferred method to secure data under different circumstances. In some cases, such as with electronic payment data, both
encryption and tokenization are used to secure the end-to-end process.