Date: 9/30/2022

Version: 1.0

Level 3 Technical Sales

Demonstration Guide

IBM Security Guardium Data Encryption

Reducing the Risk of Business Disruption and

Ransomware with Data Encryption

Contributors:

Tansel Zenginler
Worldwide Sales Enablement
Worldwide Technical Sales Enablement Leader – Data Security
Table of Contents
1 Introduction .......................................................................................................................... 3
1.1 High Level Architecture.......................................................................................................... 3
2 Demo Outline (High-Level Walk-Through) ........................................................................ 4
3 Demo Use Case.................................................................................................................... 5
3.1 Standard Data Encryption...................................................................................................... 6
3.2 Live Data Transformation .................................................................................................... 19
3.3 Ransomware Use Case ....................................................................................................... 31
3.4 Tokenization ........................................................................................................................ 42

2
1 Introduction
This document explains how to demo Guardium Data Encryption for the Reducing the Risk of
Business Disruption and Ransomware with Data Encryption use case.
This use case can be demonstrated using the Guardium Data Encryption live demo environment
available on the IBM Technology Zone portal (https://techzone.ibm.com/decisionpoints).
To learn how to prepare the demo environment, review the Demo Preparation Guide.

1.1 High Level Architecture

The IBM Security Guardium Data Encryption solution helps customers encrypt files, databases, and
applications, address data security and privacy regulations, and control encryption keys for cloud-
based data.
It is built on an extensible infrastructure; the data encryption platform features multiple data security
products that can be deployed individually or in combination to deliver advanced encryption,
tokenization, and centralized key management.
In Guardium Data Encryption (GDE), the CipherTrust Manager appliance is a single appliance that
consolidates all GDE portfolio capabilities in one single appliance including transparent encryption,
key management, cloud key management, tokenization, and application encryption.

3
2 Demo Outline (High-Level Walk-Through)
This document provides demonstration guidelines that technical sellers should use when
demonstrating the product to the client. The demo outline is as follows:
1. Start the demo with Standard Data Encryption to explain unstructured file encryption.
2. Demonstrate Live Data Transformation to protect database files.
3. Present how Guardium Data Encryption helps to protect the data against Ransomware.
4. Switch to the Tokenization tool to demonstrate format-preserving encryption at the
application level and policy-based dynamic data masking.

4
3 Demo Use Case
1. Introduction

Welcome. Today we will look at Guardium Data Encryption (GDE) and highlight how this
solution helps reduce the risk of business disruption and ransomware.
Let’s begin by talking about encryption. Encryption is the process of encoding sensitive data
so that only authorized parties can read it. There are four levels in the technology stack in
which encryption is typically employed: full-disk or media, files, databases, and applications.
In general, when encryption is employed lower in the stack, it is less likely to interfere with
operations in the layers above. For example, if the encryption occurs in the disk level, there is
very little risk of any impact on the file, database, or application layers. The file, database, and
application layers can access decrypted data and will function the same as before. However,
this simplicity comes with very little protection. Once the media is booted with the encryption
key, all the data is in the clear and at full exposure to insider and external threats. On the other
hand, if encryption or tokenization occurs in the application layer, data is encrypted right at the
source before it leaves the application or e-commerce server. While this approach offers
significantly increased security as it protects from any access that is not using the authorized
applications, it is typically more complex, costly, and time consuming to implement because
application developers need to modify every application requiring access to the encrypted
data.
Guardium Data Encryption (GDE) efficiently manages data-at-rest security across the entire
organization. GDE provides capabilities for encrypting and tokenizing data, controlling access,
and creating granular data access audit logs. With these capabilities, organizations can more
effectively combat hackers, advanced persistent threats (APTs), and insider abuse.
In this demonstration, we will start with Standard Data Encryption to protect data in files. Then,
we will discuss how GDE can help protect databases with Live Data Transformation.
Afterwards, we will simulate a ransomware attack and show how GDE will protect data against
ransomware. Last but not least, we will talk about dynamic data masking capabilities through
Tokenization. Let’s start the demonstration.

5
3.1 Standard Data Encryption
1. From the Firefox browser on the Raptor server, click on the GDE5-CM bookmark or go to the
GDE5-CM URL manually – https://gde5-cm.gdemo.com/. Login as admin / guardium.

2. In this lab we will be demonstrating transparent encryption. Click Transparent Encryption on

the main page.

In Guardium Data Encryption (GDE), the CipherTrust Manager appliance is a single appliance
that consolidates all GDE portfolio capabilities in one single appliance, including transparent
encryption, key management, cloud key management, tokenization, and application
encryption.
In the main page of CipherTrust Manager, there are different tiles available to access different
GDE portfolio capabilities. In the first scenario, we will demonstrate the different levels of
protection provided by GDE when Standard Data Encryption is implemented.

6
3. In the Clients list, select raptor.gdemo.com to review the guardpoints configured on this client.

On the Transparent Encryption page, you should see a list of registered clients. In our demo
environment, one of the clients connected to GDE system is Raptor VM. This Raptor server
should show as Healthy on the client list.

4. In this scenario, we will demonstrate the Standard Encryption Files Policy. Click on Linux-STD-
Files-Policy to review the policy rules.

When we select a client, we see the GuardPoints on this client. GDE uses the concept of
“GuardPoints” which are resources protected by a GDE access policy. A GuardPoint can
encompass a complete disk drive volume, a specific directory or an AWS S3 bucket under
which all the unstructured files or structured database files reside. Each GDE access policy is
an access control list (ACL) entry which includes five criteria that are checked when a protected
GuardPoint is being accessed. If the result of the ACL test is TRUE, then the privilege defined
in the Effect field is granted, otherwise the test proceeds to the next ACL, similar to firewall
ACLs.
In this scenario, there are two active GuardPoints configured on this client. In one of these
GuardPoints, a standard data encryption policy is applied at /GUARD/GDEGUARD/PII-Files/.
There are two PII unstructured files already encrypted in the GuardPoint.

7
5. You can review the policy rules in this page. There are total of three pre-configured policy rules.

There are five criteria that are checked when a protected GuardPoint is being accessed. The
first one is Resource Set which specifies which directories in a GuardPoint is being protected
by the policy. The second is User Sets which specify a set of users or groups who can access
the files. The third criterion is Process Sets which specify a set of executables that can operate
on the file. The fourth is When which specifies the time range when the files can be accessed.
The last criterion is the Action which specifies the allowed file action – read, write, remove,
rename or make directory.
If the result of this check is true, then GDE takes the action in Effect field. The first option is
Permitting or Denying access to the data. Another option is Apply Key to encrypt data written
to GuardPoint with Key in the KeySelection rule. The last Effect is Create log to record every
time GuardPoint is accessed.
In this policy, there are three rules configured. The first rule is for Any users in Authorized-app-
users group to have apply_key + permit access to all operations. In other words, authorized
user accounts can access the encrypted data in clear text. The second rule is for any users in
root-admin-users group to have permit access but without the apply_key effect. This means
root user will be permitted to read the file metadata but does not have the key to decrypt the
file contents. And the last rule says that any other user or process will be denied access to the
encrypted directory (aka GuardPoint).

8
6. From the Policies menu, select Policy Elements. On the Policy Elements page, navigate to
User Sets tab and then click root-admin-users.

In a policy rule, you can specify the User criteria. User allows you to specify the users that are
permitted or denied GuardPoint access. User Sets are the groups of users to make it easier to
manage the policies. So, instead of a specific user, we can have the user sets or groups to be
used in the policy rule.

7. Review the User Set and click Policy Elements\User Set link on top.

For example, in the root-admin-user set which is a group for super users and administrators,
there is only root user in our scenario.

9
8. On User Sets tab of the Policy Elements and then click Authorized-app-users.

9. Review the User Set and click Policy Elements\User Set link on top.

This is another user group where we list the application users to allow.

10
10. On the Policy Elements page, navigate to Process Sets tab. After reviewing the process sets,
click Policies menu.

Very similar to user sets, you can also specify process criteria. Process allows you to specify
the processes that are permitted or denied GuardPoint access. Process Sets are the groups
of processes to make it easier to manage the policies. So, instead of a specific process, we
can have the process sets or groups to be used in the policy rule.

11. On the Policies menu, select Linux-STD-Files-Policy and navigate to the Key Rules tab. Then
click Linux-STD-Key.

A policy comprises 'Security Rules' and 'Key Rules'. We already talked about the security rules.
A key rule defines the encryption key to apply to a specific resource set, or the encryption key
to use as the default key in the event that no other key rule matches. It defines the sequence
in which the key rules are to be executed (Order), the location of the data to be encrypted
(Resource), and the encryption key to be applied to the resource set (Key).

11
12. Review the key properties.

IBM Security Guardium Data Encryption helps not only to manage encryption but also the keys
that are being used in the encryption/decryption. You can use GDE to create agent keys, as a
secure centralized repository for storing and retrieving third-party encryption keys, and to
create key templates. Encryption keys are required for ensuring data integrity and privacy.
There are two types of keys, Symmetric and Asymmetric. A symmetric key is one that is a
randomly generated AES key used both to encrypt and decrypt information. To decrypt
information, one must have the same key that was used to encrypt it. However, Asymmetric
keys require two different keys, one to lock or encrypt the plain text, and one to unlock or
decrypt the ciphertext. Neither key can do both functions. One key is published (public key)
and the other is kept private (private key). If the lock/encryption key is the one published, the
system enables private communication from the public to the unlocking key's owner. If the
unlock/decryption key is the one published, then the system serves as a signature verifier of
documents locked by the owner of the private key.
In this screen, properties of the encryption keys can be managed. These properties include
type of object, algorithm, when to use the key, and when the key is created and modified.

12
13. Open a Terminal as root user. Change directory to the GuardPoint. Try using root user to read
one of the sensitive files and review the data. In the terminal, type:

[root@raptor ~]# cd /GUARD/GDEGUARD/PII-Files/

[root@raptor PII-Files]# ls -l

[root@raptor PII-Files]# more customers.csv

Now, let’s run some activities. In our scenario, any user in root-admin-users group will have
permit access but without the apply_key effect. This means root user will be permitted to read
the file metadata but does not have the key to decrypt the file contents.

14. Start another ssh session with an authorized user account. In the terminal, type:

[root@raptor PII-Files]# ssh [email protected]

[email protected]'s password: guardium

To demonstrate authorized users who can see clear text, we use a session with an authorized
user account. We use ssh to login to the server and we explain why we do not use just the
switch user command.

13
15. Change directory to the GuardPoint. Try using appuser user to read one of the sensitive files and
review the data. In the terminal, type:

[appuser@raptor ~]$ cd /GUARD/GDEGUARD/PII-Files/

[appuser@raptor PII-Files]$ ls -l

[appuser@raptor PII-Files]$ more customers.csv

16. Review the output.

As indicated in the first rule of the policy, any users in Authorized-app-users group will have
apply_key + permit access to all operations. In other words, authorized user accounts can
access the encrypted data in clear text.

14
17. Switch to the first terminal page where root was used. Switch user to appuser, change directory
to the GuardPoint. Try using appuser user to read one of the sensitive files and review the data.
In the terminal, type:
[root@raptor PII-Files]$ su - appuser
[appuser@raptor ~]$ cd /GUARD/GDEGUARD/PII-Files/
[appuser@raptor PII-Files]$ ls -l
[appuser@raptor PII-Files]$ more customers.csv

Now, we will try the same activity with the same user but with switch user operation. As we
see here, we cannot see the data in clear text even though we switched to an authorized app
user because GDE is aware of switch user operations. The real user here is the root, he tries
to mimic appuser. So, the policy does recognize this switch user operation and instead of
matching the first rule implemented for app users, it matches the second rule which is for the
root users. This is an additional level of security and enables GDE protect data more effectively
against attacks.

15
18. Strt another ssh session in a new terminal with an unauthorized user (dan/guardium). In the
terminal, type:
[root@raptor PII-Files]# ssh [email protected]
[email protected]'s password: guardium

Now, let’s check with an unauthorized user.

19. Change directory to the GuardPoint. Try using dan user to read one of the sensitive files and
review the data. In the terminal, type:

[dan@raptor ~]$ cd /GUARD/GDEGUARD/PII-Files/

[dan@raptor PII-Files]$ ls -l

[dan@raptor PII-Files]$ more customers.csv

In this case, the last rule in the policy is triggered. Any users/processes other than authorized
users/processes are denied access to the encrypted directory.

16
20. On the GDE GUI, click Records menu and then select Client Records.

In GDE, we can audit and report activities. Let’s check our activities in the reports.

21. Click on magnifier icon to open filter options and fill raptor.gdemo.com for Client.

We can easily filter the activities by the client name and type, severity, or other details. The
reporting and filtering capabilities of GDE enables us to identify the attacks and act against
them faster and more effectively.

17
22. Review the report.

In this report with the filter applied, we see all activities on the Raptor server. For example,
there is a record for customers.csv file that was rejected for user dan.

We reviewed the Standard Data Encryption to protect data in the files. We

examined how the policy works for different users and processes.

18
3.2 Live Data Transformation
1. Introduction

Now, we will demonstrate how GDE operates to protect database files.

GDE Transparent Encryption can alleviate the planned downtime required for initial encryption
and scheduled rekeying operations seamlessly by adding the GDE Live Data Transformation
option to deployments.
With the Live Data Transformation (LDT) capability, GDE administrators can encrypt, or rekey,
GuardPoint data without blocking user or application access to the data. In LDT, rekey means
decrypting data with the current cryptographic key and then encrypting it with a new
cryptographic key.
After enabling GuardPoints, LDT performs initial encryption or rekeying in the background,
unnoticed by users. The data stays live and available. This accelerates GDE deployments and
eliminates the need to block application and user access to data during encryption or rekey
operations, which can seriously inconvenience users and affect operational efficiency.
With LDT, the administrator can create a single Live Data Transformation policy for both initial
encryption and subsequent rekeying. The same policy applies to production access and
security rules without restricting user or application access to data. Applications have continuity
of access to GuardPoint data during LDT.
In this demo scenario, we have an Oracle database instance named ORASALES running on
Raptor server. In this environment, only the folder containing datafiles of ORASALES database
is encrypted for demo purposes.
In this scenario, we want to show that Oracle processes can continue to function even though
the datafiles are encrypted by GDE. In a normal scenario, an Oracle database should only be
accessed through valid channels which is via Oracle processes/clients. If any privileged/root
users attempt to copy or temper with the datafiles from a filesystem level, the database files
are encrypted and cannot be tempered with. All malicious attempts to copy data files out of the
server will also remain encrypted and will be of no use to the attacker without a key.
Let’s highlight the importance and value of this protection. Let’s consider an environment with
a Data Activity Monitoring and Protection solution deployed. These solutions are great for
auditing database activities. However, if there is an attacker or administrator who knows there
is data protection solution deployed, he can still access the data. He can copy the datafiles or
backup files, deploy a database with the same patch level on different server or client where
there is no protection. As he knows the details of the database, he can restore the backup or
attach the datafiles on this new database and access the data. In this scenario, we can see
the importance of backup and datafile protection.

19
2. From the Firefox browser on the Raptor server, click on the GDE5-CM bookmark or go to the
GDE5-CM URL manually – https://gde5-cm.gdemo.com/. Login as admin / guardium.

3. During this part of the lab, we will be demonstrating live data transformation which is part of
transparent encryption. Click Transparent Encryption on the main page.

In this part of the demo, we will demonstrate live data transformation which is part of
transparent encryption.

20
4. In the Clients list, select raptor.gdemo.com to review the GuardPoints configured on this client.

5. There are two Policies applied to two GuardPoints. Click on the Linux-LDT-ORA-Policy to
review the policy rules.

For the datafiles of the ORASALES database the LDT policy is used.

21
6. Review the policy.

In this LDT policy, only the Oracle processes or Oracle database administrators can access
the encrypted data files with a key. Any other privileged users such as root users will have
permission to read the directory listing and file metadata but does not have key to read file
contents. Anything non-whitelisted will be denied access from the encrypted directory.

7. From the Policies menu, select Policy Elements. On the Policy Elements page, navigate to
User Sets tab and then click Oracle-SYSDBA-Users.

22
8. Review the User Set and click Policy Elements\User Set link on top.

There are three users defined in the Oracle database admin users group. The users that start
with gdm are used in Guardium Data Protection. The last one, oracle, is the out-of-box
database administrator.

9. On the Policy Elements page, navigate to Process Sets tab and click on Oracle-Processes.

23
10. Review the processes defined in the Process Set.

These two processes are used to run the database and access the data in the database. By
using this process set, we can easily manage the allowed processes.

11. Start ssh session in a terminal with an authorized user (oracle/guardium). In the terminal, type:
[root@raptor ~]# ssh [email protected]
[email protected]'s password: guardium

Now, let’s test this policy in action. Since GDE tracks the switch user operations, we must use
ssh to login in a new session.

24
12. Switch to the ORASALES database and login with HR user. Run a command to test the
connection in the terminal, type:
[oracle@raptor ~]$ export ORACLE_SID=ORASALES
[oracle@raptor ~]$ sqlplus HR/guardium
SQL> select * from HR.EMPLOYEES where rownum <=5;

We must switch to the ORASALES database to check the database access.

13. Review the data. Then disconnect and quit from the SQL session and exit from the oracle user.

We can access the data in clear text because we use an authorized user.

25
14. With the root user in terminal, change directory to the GuardPoint. Try using dan user to read one
of the sensitive files and review the data. In the terminal, type:

[root@raptor ~]# cd /opt/oracle/oradata/ORASALES/datafile/

[root@raptor datafile]# ls -l

[root@raptor datafile]# strings o1_mf_users_jzrm6pky_.dbf | less (Note: The name of this

file may change depending on your TechZone reservation. You must try opening the datafile for
the USERS tablespace)

A privileged user such as root has permission to read the directory listing and file metadata.

15. Review the data.

However, the same user does not have key to read file contents directly from the encrypted
files.

26
16. With the root user in terminal, change directory to the other Oracle database instance Try using
root user to read one of the sensitive files and review the data. In the terminal, type:

[root@raptor ~]# cd /opt/oracle/oradata/ORCLCDB/

[root@raptor ORCLCDB]# ls -l

[root@raptor ORCLCDB]# strings users01.dbf | less

On the same Raptor server, there are two other Oracle database instances (ORCLCDB and
ORCLEDB). The datafiles for these two databases are not encrypted by GDE. In this
demonstration we see the read attempt of the unencrypted datafiles of these databases are
successful.

17. Review the data.

While the data is not presented in a structured format, we can still see the unencrypted datafile
in clear text. If attacker gained access to the database server, they could easily copy the
unencrypted tablespace file and restore the data in their database to gain all its contents.

27
18. On the Policies page, click on the Linux-LDT-ORA-Policy.

19. Switch to the Key Rules tab and click on Linux-LDT-ORA-Key.

Now, let’s examine the properties of the key that is being used in LDT policy.

28
20. Review the key properties.

In this screen, properties of the encryption keys can be managed. These include type of object,
algorithm, when to use the key, and when the key is created and modified as we discussed
before. With this screen, we can easily manage the encryption keys.

29
21. On the GDE GUI, click Records menu and then select Client Records. Click on magnifier icon
to open filter options and fill raptor.gdemo.com for Client.

22. Review the report.

In the report with the filter applied, we see all activities on the Raptor server. For example,
there is a record for the datafile of ORASALES database.

In this part of the demo, we reviewed the Live Data Transformation to protect
data in the databases. We examined how the policy works for different users
and processes.

30
3.3 Ransomware Use Case
1. Introduction

In the first two scenarios, we learned how to use GDE to protect data. Now, we will discuss
how to apply these functionalities to prevent ransomware attacks.
First, we must explain what ransomware is. Ransomware is a vicious type of malware that
cybercriminals use to block companies and individuals from accessing their business-critical
files, databases, or entire computer systems, until the victim pays a ransom. It is a form of
cyber extortion. The direct costs can be attributed to the ransom demands — if the victim
chooses to the pay the ransom — while the indirect costs are associated with the downtime,
data recovery, lost revenue, improvements to cyber defenses, and reputational damage to the
company.
This part of the demo helps you understand the anatomy of ransomware attacks and explores
the solutions available in the market today to defend against such attacks. It illustrates how
security policies in Guardium Data Encryption enable you to prevent rogue processes and
unauthorized users from encrypting your most sensitive data thereby protecting you from
ransomware attacks.
Let’s talk about how GDE prevents ransomware attacks. Access policies can be defined in
GDE to create a whitelist of “trusted” applications to prevent any untrusted binaries (e.g.
ransomware) from accessing data stores protected by GDE and to prevent privileged users
from accessing user data in files and databases. GDE access policies can enable you to block
any rogue binaries from encrypting files/databases, even if the intruder has executed
permissions for that binary and read/write permission to the target file that contains business
critical data.
Now, we can demonstrate the use case and GDE preventing the ransomware attack.

2. In the demo environment, click on Windows Server 2019 Standard SQL 2017.

31
3. Login by using guardium as the Administrator password.

4. From the Chrome browser on the Windows server, click on the CM bookmark. Login as admin /
guardium.

5. During this part of the lab, we will be demonstrating Ransomware use case. Click Transparent
Encryption on the main page.

32
6. In the Clients list, select wins2019sql.gdemo.com to review the GuardPoints configured on this
client.

We will work on the windows server for the ransomware use case.

7. There are two GuardPoints. Click on the Windows-LDT-Ransomware installed on

RansomDemo folder to review the policy rules.

There are two sets of the same PII files in two different directories for demo purposes. The first
one is under NOGUARD folder (C:\GUARD\NOGUARD\Sensitive\) and it contains PII files
unencrypted.
The other folder is Ransomdemo subfolder under GDEGUARD
(C:\GUARD\GDEGUARD\Ransomdemo\Sensitive\). It also contains PII files. It is a
GuardPoint protected by GDE policy.

33
8. Expand the Authorized-app-users user set and Windows-Authorized-Procs process set used
in the rules and review the policy.

In the policy used to guard Ransomdemo folder, we have four rules. The first rule is for the key
operations in LDT policy. The following two rules allow authorized processes and users to
access the data in clear text. The last rule denies all other users and processes. So, if the
process or user is not an authorized one, it will not be possible to access the data in clear text.

9. Click REAL Wordpad icon on desktop and select File from the menu to navigate Open.

34
10. Open VIPs text file under C:\GUARD\NOGUARD\Sensitive\.

First, we can verify that we can see the data in the VIPs file in the NoGuard folder.

11. Review the data.

As you can see, the data in the VIPs text file under NoGuard folder can be seen in clear text
through the real WordPad application.

35
12. With the REAL WordPad application on desktop, open VIPs text file under
C:\GUARD\GDEGUARD\RansonDemo\Sensitive\.

Let’s also verify the data in the VIPs file in the RansomDemo folder.

13. Review the data.

We confirm that the data in the VIPs text file under RansomDemo folder can be seen in clear
text through the real WordPad application.

36
14. Click on Wordpad Shortcut on desktop.

On this Windows server, there is a fake “Wordpad” shortcut on the Administrator user desktop.
This fake “Wordpad” shortcut is a custom program that mimics a spoofing malware attack, to
trick user to think that it is their usual authorized application but in fact is not.
When the user clicks on the fake “Wordpad” shortcut, they will realize that a custom program
will start to run, scanning for files to encrypt on the Windows server. This mimics a
Ransomware use case when Ransomware malware scans server for sensitive files for
malicious encryption and data exfiltration and demand for ransom later.

15. Review the result of the application.

37
 When the program finishes running, you will see sensitive files opened with Ransomware,
stating the files have been encrypted and a demand for ransom payment. These “encrypted”
files are in the C:\GUARD\NOGUARD\Sensitive\ directory. This shows how vulnerable it is for
PII files to stay unencrypted on the servers in case of a Ransomware malware infection.

16. With the REAL WordPad application on desktop, open VIPs text file under
C:\GUARD\GDEGUARD\RansonDemo\Sensitive\.

Let’s verify the data in the VIPs file in the RansomDemo folder which is protected by GDE.

38
17. Review the data.

As you can see, the data in the VIPs text file under RansomDemo folder can still be seen in
clear text through the real WordPad application. Because this folder is protected by GDE,
Ransom cannot access the data in this folder.

18. With the REAL WordPad application on desktop, open VIPs text file under
C:\GUARD\NOGUARD\Sensitive\.

39
19. Review the data.

However, the data in this file under NoGuard directory is encrypted. This fake “Wordpad”
shortcut, which mimics a spoofing malware attack, scanned for sensitive files and encrypted
the data. With the real WordPad, we verify that data is encrypted and request for the ransom
payment.

20. On the GDE GUI, navigate back to the main page from the icon on top.

40
21. On the GDE GUI, click Records menu and then select Client Records. Review the report.

In GDE reports, we see all activities on the Windows server. For example, there is a record for
rejected access to RansomDemo folder and its’ contents. This folder is protected by GDE, and
GDE did not allow the ransomware to access data.

In this third part of the demo, we simulated a RansomWare attack and

highlighted the importance to protect the sensitive data. We also presented the
value and ease of using GDE for this use case.

41
3.4 Tokenization
1. Introduction

In the last section of the demo, we will talk about Tokenization and Dynamic Data Masking.
Guardium Data Encryption Tokenization offers the flexibility to dynamically display only
portions of a sensitive data field based on the role of the user requesting the information. A
common instance is a call center model, where a typical operator only sees the last 4 digits of
a credit card number, while call center manager may see the entire number. This capability of
displaying partially redacted data based on a policy is called “Dynamic Data Masking”.
In the architecture with the Tokenization, there is an additional component called Tokenization
Server. Tokenization Server is a virtual appliance that creates tokens or displays source data
based on policy and role.
The supported tokenization mechanisms are random tokens and format preserving encryption.
GDE Tokenization is an agentless solution. Only application source code changes are needed
to call REST APIs.

2. In the demo environment, click on Windows Server 2019 Standard SQL 2017.

42
3. Login by using guardium as the Administrator password.

4. From the Chrome browser on the Windows server, click on the TokenServer bookmark. Login
as superuser / Guardium123! (the password was saved in the browser).

5. On the Tokenization Server, click on Users menu and select helpdesk. Review the details and
click Cancel.

In our demo, there are two users, superuser and helpdesk. These two users belong to different
user groups, hence they have different access. When we check helpdesk user, we see that
the user is active, meaning this user can make REST API calls. The helpdesk user details
show that the user does not have masking enabled, however, the permissions and data
masking is tied to the user group, not the user. This is a good practice because if you have
many users in a group, it is much easier to add users to a group with permissions already set
than to individually change each users’ permissions.

43
6. On the Tokenization Server, click on User Groups menu and select Customer Service. Review
the details and click Cancel.

Now, let’s look at the User Groups tab. When we click on the Customer Service user group,
we see that mask is set to show Last4. Last4 is a mask that was created for this scenario. It is
possible to create other masks and customize masks depending on the use case.

7. On the Tokenization Server, click on Tokenization menu and Masks submenu. Select Last4,
review the details and click Cancel.

In the Masks page, we can manage the masking rules. In our scenario, we use Last4 which
shows the last four characters from the right. This could be changed to whatever you would
like the mask to be.

44
8. On the Tokenization Server, click on Tokenization menu and Tokenization Groups submenu.
Select cts-demo-tokenizationGroup, review the details and click Cancel.

Tokenization Groups hold the key that is going to be used. In this case the key being used is
the ctsdemo-key for cts-demo-tokenizationGroup.

9. On the Tokenization Server, click on Tokenization menu and Tokenization Templates

submenu. Select CTSDEMO-MMYY template, review the template and click Cancel.

We have a couple of templates we will show in this scenario. The first template, ‘CTSDEMO-
MMYY’ has the format of the data to match and it’s going to convert the data accordingly.

45
10. Select CTSDEMO-FF1_Digits template, review the template.

The second template, ‘CTSDEMO-FF1_Digits’ is used for the numeric values, and it uses
Format Preserving Encryption.

11. Review the options in Format field. And then click X to close the popup.

There are many options that we can use as the format.

46
12. Select CTSDEMO-Random template, review the template and click Cancel.

Another template is ‘CTSDEMO-Random’ which will be used for the credit card numbers. It will
add CC as the prefix to the new value.

13. Select SAMPLE-DDMMYYYY template, review the template and click Cancel.

14. Click on Permissions menu and select helpdesk.

Permissions in GDE allow you to add permissions on a user level or group level.

47
15. Review the details.

In this demo, you can see that the helpdesk user does not have any permissions.

16. Navigate to User Group tab and select Customer Service.

But the group Customer Service does have permissions.

17. Click on Detokenize, review the details and click Cancel.

When we check the Customer Service group, we see that it has access to the cts-demo-key
needed to detokenize the data.

48
18. Open the Customer Entry Front Office Checkout Page by using the first bookmark on Chrome.

Now, let’s emulate a real-life scenario. This is the Customer Entry Front Office Checkout Page.
We will use this page to provide details and then checkout to save them.

19. Fill all the fields (When entering the credit card number, be sure to add a hyphen between every
four numbers) and click Continue to checkout.

After clicking Continue to checkout we see the tokenization screen.

49
20. Review the data.

As you see here, the data stored the full name, email address, credit card number, and
expiration date are all tokenized.

21. Open the Back Office Application by using the second bookmark on Chrome. Use the saved
credentials for superuser to login.

This is another application that we will demonstrate. This application is used by superusers
and help desk personnel.

50
22. Review the data and click Back.

Once we log in with superuser, we see the original data that was sent, because it has been
detokenized. This is possible because the superuser has complete access to the data.

23. Use the saved credentials for helpdesk to login.

Let’s check what helpdesk user will see.

51
24. Review the data.

The helpdesk user cannot see all the original data. You see that the data view for the helpdesk
user is masked; this is known as dynamic data masking.

25. Open the php My Admin page by using the third bookmark on Chrome. Use the saved
credentials for root to login.

This is the third application that we will demonstrate. This application is used by the database
administrators.

52
26. Expand VTSDemo database and click on registered_users table.

The data is stored in the VTSDemo database, in the registered_users table. In this scenario,
the database administrator cannot see the original credit card data; instead, they see the
encrypted data.

27. Click on the Insomnia icon on desktop.

There is another tool called Insomnia developed for our scenario.

53
28. Review the data and click on Tokenize - CTSDEMO.

This application demonstrates RestAPI calls. When we send the token to the Tokenization
Server in RestAPI, it detokenizes the data. It applies masking functions if there are any. For
example, we can see only the last 4 digits of the credit card, and only the year information in
a date. Email is also masked.

29. Review the data.

And this application can also simulate tokenization. When we send the data in clear text
through a RestAPI call, the Tokenization Server checks the templates and rules to tokenize
the data. In this scenario, we see how the credit cards, dates and emails are tokenized.
This is the end of our demonstration. We highlighted how Guardium Data Encryption can help
to protect your data in files or even in the databases.

We demonstrated Tokenization tool and highlighted how we can dynamically

mask the data.

54