ICT Conference, Kladovo - 15.05.2015

TDE vs. PCI DSS v3.0, SECTION 3.4

Author: MSc EE, Darko Mihajlovski – Head of IS Department

Co-author: MSc PM, Kiril Buhov – Head of IT Department

Co-author: MSc.B, Jani Nikolov – Head of PCS Department

The Full Story

IMPLEMENTATION OF

TRANSPARENT DATA ENCRYPTION (TDE) AND ADDITIONAL COMPENSATIONAL

CONTROLS

AS

ALTERTATIVE METHOD REGARDING ENCRYPTION OF PAN NUMBERS IN MICROSOFT

SQL DATABASE

(PCI DSS V3.0, SECTION 3.4)

Content

1. INTRODUCTION

2. PCI AND THE ART OF THE COMPENSATING CONTROL

i. WHERE ARE COMPENSATING CONTROLS IN PCI DSS?ii. WHAT A COMPENSATING CONTROL IS NOTiii. HOW TO CREATE GOOD COMPENSATING CONTROL

3. APPROACH TO THE PROBLEM

4. SQL SERVER 2008 TRANSPARENT DATA ENCRYPTION OFFERS FULL DATA ENCRYPTION

i. USING MANUAL KEY MANAGEMENT

…………… And much, much, more .. rest of „ it “ …….

PCI DSS sense

The Message…

Proper” TDE implementation should cover the 3.4 requirement from PCIDSS v3, where it demands the following: 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

The Problem …

The use of encryption to render cardholder data unreadable is a highly effective and readily accepted way to security data

The problem occurs when the System/Application/Software Vendor tells You that encrypting the PANs is not a possible option.

Thinking Out of the Box…

The Art of Compensating Controls

Compensating controls are a standard part of any security posture.

But what makes an effective compensating control?

Every compensating control must meet four criteria before it can be considered for validity.

• meet the intent and rigor of the original PCI DSS requirement,

• provide a similar level of defense as the original PCI DSS requirement,

• be "above and beyond" other PCI DSS requirements,

• and be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement.

Where are compensating controls in PCI DSS

Compensating controls are not specifically defined inside PCI, but are instead defined by you, and assessed by Your QSA

Thankfully, the PCI Council provides an example of a completed compensating control in Appendix C of the PCI DSS

Compensating controls are ultimately accepted by acquirers or the card brands themselves, so even after putting all of this information together you could face the rejection of your control and a significant amount of expense re-architecting your process to fit the original control.

This is where an experienced QSA can really help you ensure your control passes the "Sniff Test." If it smells like a valid control, it probably will pass.

What a compensating control is not ?

Compensating controls are not a short cut to compliance.

In reality, most compensating controls are actually harder to do .....

.. it is up to the QSA performing the assessment to decide to accept the control initially

MS TDE ...

MS TDE Benefits

Implementation of TDE does not require any schema modifications.

Since the physical data files and not the data itself are encrypted, the primary keys and indexes on the data are unaffected, and so optimal query execution can be maintained.

The performance impact on the database is minimal.

Microsoft estimates the performance degradation for TDE to be 3-5%, while cell-level encryption is estimated to be 20-28%. Of course, the impact well may vary, depending upon your specific environment, and volume of data.

The decryption process is invisible to the end user.

MS TDE Disadvantages

• Use of TDE renders negligible any benefits to be gained from backup compression, as the backup files will be only minimally compressed. It is not recommended to use these two features together on the same database.

• TDE does not provide the same granular control, specific to a user or database role, as is offered by cell-level encryption.

• TDE is available only with SQL Server 2008, Enterprise Edition and so will probably not be available to all installations within your environment.

SQL SERVER 2008 TDE

Choosing to enable TDE, consider:

TDE only secures data at rest and does not help to secure the communication

the certificate used to encrypt the data is required during any attempt to decrypt the data

complete and accurate backups of the certificate are required to minimize the risk of data loss

Backups of the database itself will be encrypted and will require the certificate as well

In the case of SQL Server, the TDE Database Encryption Key must be replaced at least once per year

Using Manual Key Management

Any user that can backup keys and certificates should have write access to the backup folder location, but be denied read access to that location

Users with access to the key and certificate backup folders should be denied access to any backups of the database

The user who backs up the database should not be the same user who backs up the certificates

The key must be stored utilizing tamper evident media, or in a tamper evident container.

In some instances something as simple as a pressure-sealed envelope may suffice, placed under dual control.

Physical Keys

Metal Safety Box

Metal Box 1 Metal Box 2

PasswordsLeft part

(in Person 3)

Right part

(in Person 4)

Physical KeysPerson 1 Person 2

Person 5

in the environment, it should be fulfilled the following, too:

SA disabled when using Windows auth. mode

BUILTIN/Administrators group not a member of sys-admin role

Use of signed modules

Role based access

Hard segregation of duties, with matrixes of segregations, evidences and etc.

Hardening of the Database configuration, as reference - Compliance with the Microsoft SQL 2008 Server Hardening Guide, Version 1.0.0, 19 May 2011

in the environment, it should be fulfilled the following, too:

SQL Hardening – another 280 controls:

i. Operating System and Network Specific Configuration

ii. SQL Server Installation and Patches

iii. SQL Server Settings

iv. Access Controls

v. Auditing and Logging

vi. Backup and Disaster Recovery Procedures

vii. Replication

viii. Application Development Best Practices

ix. Surface Area Configuration Tool

Thank You

darko.mihajlovski@halkbank.mkTel.: +389 2 3240 804, Mob.: +389 71 30 55 31

kiril.buhov@halkbank.mkTel.: +389 2 3250 999, Mob.: +389 70 32 77 33

jani.nikolov@halkbank.mk Tel.: +389 2 3250 966, Mob.: +389 71 327 917

Questions