Datastore Agnostic Encryption with Full Disk Encryption

Tyler DuzanProduct Manager

2

Who Am I?

• My name is Tyler Duzan• Formerly an operations engineer for

more than 12 years focused on security and automation

• Now a Product Manager at Percona• Have assisted organizations in the

healthcare, hosting, and finance industries reach certified compliance with PCI, HIPAA/HITECH, HITRUST, SOC II, and FEDRAMP

3

Outline

1. Bio & Outline2. What is “Data at Rest” Encryption?3. What Do Compliance Standards Say About This?

• EU GDPR, PCI DSS, HIPAA / HITRUST, SOC II TSP, FEDRAMP / CSA CSM• Is “Data at Rest” Encryption Sufficient?

4. Layers at Which You Can Encrypt Your Data• Why Full Disk Encryption is the First Step• How is FDE “Datastore Agnostic”?

5. Using Linux Unified Key Setup (LUKS) to Implement FDE6. Datastore Specific Options7. Q&A

What Is ”Data at Rest” Encryption?Click for subtitle or brief description

5

The Three States of Data

Data can be in three states:• ”At Rest”

• This is when the data is not being read or written to and is resident on persistent physical storage medium such as a hard disk. While “At Rest” data must be protected against the threat of physical theft. This will be the focus of our presentation today.

• “In Motion”• This is when data is traveling across a network or is sitting resident in memory during a read

or write operation. During this state data has not yet been persisted so must be protected against the threat of data manipulation as well as unauthorized access.

• “In Use”• This is when data is being processed by one or more applications and also includes data

being viewed by the application user. During this state data has not yet been persisted and is exposed to endpoints where users may access it. Threats of data manipulation, unauthorized access, and non-digital theft can occur in this state.

6

Why The Focus on “Data At Rest”?

• This is the state at which data faces the least types of threats so is very often overlooked

• Despite how simple it is to protect, since the majority of data in an organization is ”at rest”, the attack surface is large

• To protect data in other states typically requires application specific implementation of security controls and techniques. Data ”at rest” can be treated generically

• Even when using the newest and coolest datastores which don’t yet implement enterprise features, it is possible to protect data ”at rest”.

What Do Compliance Standards Say?

8

EU GDPR

• GDPR expects organizations to stay in control of their data to ensure that it is accessed and processed by authorized users only when appropriate. The control requirements are covered in Articles 5, 25, and 32.

• Security obligations are covered in Articles 6, 25, 28, and 32.• Data security must be considered by design and as a default• Data must be secured via encryption or pseudonymization• The GDPR specifically calls out encryption as a security requirement for

securing your data infrastructure• Servers, including via file, application, database, and full disk virtual machine encryption.• Storage, including through network-attached storage and storage area network encryption.• Media, through disk encryption.• Networks, for example through high-speed network encryption.

9

PCI DSS

• There are two states under which PCI DSS specifies data must be encrypted. When “at rest” and when “in motion”.

• Requirement 3: “protect stored cardholder data.”• Requirement 4: "Encrypt transmission of cardholder data across open,

public networks.”• The technical requirements go into more details and specify that strong

cryptography is one recommended method to use for protection of data ”at rest”.• If full-disk encryption is used, logical access must be managed independently of

native operating system access control mechanisms. Decryption keys must not be tied to user accounts. Encryption keys used for encryption of cardholder data must be protected against both disclosure and misuse

10

HIPAA after HITECH

• With HITECH, the HIPAA regulations became more prescriptive about data protection and precedent in the market helps clarify the requirements• Information is only secured if it is encrypted or destroyed• Encryption must meet NIST 800-111 encryption requirements • If the keys are stored, they must be kept on a separate device than the data• Only FIPS approved encryption algorithms can be used

• Data must be encrypted both “at rest” and “in motion”.• Data which is unprotected (unencrypted) has stricter breach notification

requirements

11

HITRUST CSF

• Level 1 Requirements (found on Pg. 255 of v9 of HITRUST CSF) state:• “The information system protects the confidentiality and integrity of information at

rest. Covered information, at minimum, shall be rendered unusable, unreadable, or indecipherable anywhere it is stored, including on personal computers (laptops, desktops) portable digital media, backup media, servers, databases, or in logs, by using any of the following approaches:”

1. full disk encryption (mandatory for laptops and other mobile devices that support full disk encryption, see 01.x)

2. virtual disk encryption 3. volume disk encryption 4. file and folder encryption

• Level 3 Requirements add additional controls around accessing encrypted data at rest

12

SOC II TSP

• AICPA isn’t strictly prescriptive as SOC is not so much a compliance standard as a standard for how to audit for compliance with organizational controls. However, the five Trust Service Principles (TSP) engrained in SOC II have mappings to other more prescriptive frameworks.

• Security, Confidentiality, and Privacy are 3 of the 5 TSPs and can be assisted through the use of encrypting data “at rest” and building controls around how that data is accessed in your organization.

• One of the items verified during SOC reporting is “commitment”, which includes any commitments made to “encryption standards used to encrypt stored customer data”

13

FEDRAMP / CSA CCM

• FEDRAMP is not especially prescriptive, but the Cloud Security Alliance (CSA) has created controls mappings for FEDRAMP to help service providers meet the criteria in their Cloud Control Matrix (CCM)

• In CSA CCM v3 section “Encryption and Key Management” it specifies• “Encryption should be implemented for data-at-rest, data-in-transit and data-in-use”• “Strong encryption (e.g., AES-256) in open/validated formats and standard algorithms shall

be required. Keys shall not be stored in the cloud (i.e. at the cloud provider in question), but maintained by the cloud consumer or trusted key management provider”

• Additionally FEDRAMP specifies that agencies should use control-specific contract clauses with providers. A common clause is that the provider “shall provide security mechanisms for handling data at rest and in transit in accordance with [encryption standard]” where the encryption standard is specific to agency requirements

14

Is Data “At Rest” Encryption Sufficient?

• As previously discussed, data can exist in three different states in your application. Some compliance standards specifically call out which states are required to implement encryption, others are less prescriptive

• For general security requirements its important to appropriately threat model your application and understand the requirements you need to meet for your organizational controls and their technical requirements

• In general, encrypting data “at rest” is not sufficient by itself, it is just one layer in an overall security posture

• However, it is a critical piece to get right as most data in your organization is ”at rest”.

Layers At Which You Can Encrypt

16

Layers Of Encryption

1. Physical Disk / Volumea) LUKS / dm-cryptb) GELIc) Bitlocker

2. Filesystema) EncFSb) EFS

3. Databasea) InnoDB Tablespace Encryption / Transparent Data Encryption (TDE)

4. Applicationa) Custom Implementation

17

Why FDE is the First Step?

• While moving up the stack gains more control over access and granularity in how you encrypt data, it comes at the cost of increase in complexity and implementation difficulty

• Implementing FDE does not prevent you from implementing encryption on any other layer of the system

• KISS principle• FDE is battle-tested as a way to encrypt data “at rest” that both meets

compliance requirements and is effective against physical theft• FDE capabilities are built-in to every server operating system

18

How is FDE ”Datastore Agnostic”?

• There is a lot of new development happening in the open-source database ecosystem right now. This is especially true with many new NoSQL distributed datastores recently released.

• Most open-source databases only provide native encryption capabilities in their enterprise licensed editions, if it’s provided at all.

• Many of the newest datastores don’t yet have this feature-set• You can still meet basic compliance requirements for data “at rest”

encryption by using FDE no matter what database is using the underlying encrypted volume

Using LUKS to Implement FDE

20

Warnings and Caveats

• Losing access to the key means losing all of your data. It’s incredibly important that you implement proper key management in your organization and maintain backups of your key material

• When you encrypt a disk, generally speaking and specifically with LUKS, it destroys whatever is currently present on the disk or volume. Only perform the encryption steps against a fresh volume prior to putting your data in place

• In order to meet specific compliance standards ensure you review those standards and their specific implementation requirements. How the key is stored, handled, or generated can be important depending on the standards you must comply to.

21

Installation of Packages + Key Generation

• dm-crypt is included with Linux in all major distributions• You must install cryptsetup though

• yum install cryptsetup• apt-get install cryptsetup

• The cryptsetup process will create a symmetric key to use for encrypting the disk/volume with the supplied passphrase. Since the passphrase is a component of key generation and unlocks the disk it’s important that its high-entropy.• You can generate it and store it using a password manager• Alternatively try the following: openssl rand –base64 32

22

Run cryptsetup

• This will delete any data on the device, ensure you’ve made any necessary backups before running this

• cryptsetup -c aes-xts-plain -v luksFormat /dev/sda4

• The above command reads ‘create’, using the AES-XTS encryption algorithm, using the LUKS format, an encrypted volume on the disk at /dev/sda4

• You will be prompted to provide a passphrase twice, provide the one that was previously generated. This will be used each time the system needs to mount this disk

23

Initial luksOpen, Formatting, and Mounting

• Next decrypt the volume and provide a devmapper device name• cryptsetup luksOpen /dev/sda4 data

• You’ll be prompted to enter your passphrase to perform this operation• Next, you need to format the devmapper device with the filesystem of

your choice. For our purposes we’ll use XFS• mkfs.xfs /dev/mapper/data

• Finally you can mount the new encrypted device to a path of your choice. In this example we’re using it for MySQL• mount /dev/mapper/data /var/lib/mysql

• Each time you reboot you’ll need to manually luksOpen and mount the device.

24

Additional Things to Know

• After you first create a new LUKS encrypted device you’ll want to ensure you create a header backup and store this in a safe place. If the header becomes corrupted or you fail a key rotation this header can be restored to make the prior passphrase work.

• You’ll want to define and follow a policy internally for rotating encryption keys. With LUKS you can have multiple encryption keys which concurrently are able to decrypt the volume due to the way its implemented. Ensuring your perform rotations correctly is paramount for both security and compliance

• There is a blog article on the Percona Database Blog that covers this process in more detail, as well as numerous other guides.

Datastore Specific Options

26

InnoDB Tablespace Encryption

• Tablespace encryption (TE) occurs within the database engine when configured to encrypt the contents of the InnoDB table files (.ibd) on disk. This does not cause any other MySQL related date to be encrypted. It can be used in conjunction with FDE to provide an extra layer of encryption and data access control. If your requirements allow it, it can be used instead of FDE as well.

• InnoDB tablespace encryption uses a two-tier encryption key architecture, consisting of a master encryption key and tablespace keys. When an InnoDB table is encrypted, a tablespace key is encrypted and stored in the tablespace header.

• This feature relies on having a keyring plugin installed and configured and it must load before InnoDB. You can do this by setting a plugin early load in your my.cnf

• For more information refer to the article on the Percona Database Blog entitled “MySQL Encryption at Rest – Part 2 (InnoDB)”

Questions?

28

Thank You Sponsors!

29

SAVE THE DATE!

CALL FOR PAPERS OPENING SOON!www.perconalive.com

April 23-25, 2018Santa Clara Convention Center