MICROSOFT SQL SERVER - Townsend Security · self-encrypting drives, ssds, etc file system...

ENCRYPTION &KEY MANAGEMENTMICROSOFT SQL SERVER

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Organizations large and small, public and private, are faced with daily

challenges to protect their sensitive digital assets. These might include

intellectual property, business plans and strategies, and sensitive data

of employees, customers, vendors, and stakeholders. The loss of this

sensitive data can be devastating to the organization and in some cas-

es represents a catastrophic loss. There is no alternative to a digital

existence and cybercriminals, political activists, and state actors have

become more and more adept at stealing this information.

Microsoft SQL Server has become a ubiquitous storage mechanism for

all types of digital assets. Protecting these data assets in SQL Server is

a top priority for business executives, security specialists, and IT pro-

fessionals. This eBook looks at various ways to protect sensitive data

in SQL Server databases using encryption – the most widely recog-

nized and accepted way to protect these assets. Of course, it should

be noted that encryption is only one part of a larger digital security

strategy. Getting data security right means deploying a wide set of

protection technologies and human procedures. Here we are only

looking at the critical security control of encryption.

Patrick Townsend, Founder & CEO,Townsend Security

“

”

Page 2

CHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskereCHRISTOPHE KEREBEL My Twitter : @chriskere

http://bit.ly/1TTGa7Q

http://on.fb.me/1RELHbG

http://bit.ly/1QKRDT5

http://bit.ly/1U7ngcV

Page 3


ENCRYPTION IN THE BROADEST SENSE MEANS

obscuring information to make it inaccessible to un-

authorized access. But here we will use the term in its

more precise and common use – the use of well ac-

cepted encryption algorithms based on mathematical

proofs and which have been embodied and approved

as international standards.

Many approaches to encryption

do not meet minimal require-

ments for security and compli-

ance. Our definition of encryp-

tion excludes:

• Homegrown methods developed by even ex

perienced and talented programmers.

• Emerging encryption methods that are not yet

widely accepted.

• Encryption methods that are widely accepted

as secure, but which have not been adopted

by standards organizations.

• Data substitution and masking methods not

based on encryption.

An example of an encryption method that does meet

our criteria would include the Advanced Encryption

Standard (AES) which is sometimes knows as Rijndael,

Triple Data Encryption Standard (3DES), RSA, and Ellip-

tic Curve encryption methods.

ENCRYPTION

In the context of protecting data in a SQL Server data-

base, the most common encryption method protecting

whole databases or an individual column in a table is

AES. All key sizes of AES (128-bit, 192-bit, and 256-bit)

are considered secure and are appropriate for pro-

tecting digital assets. Many organizations chose 256-

bit AES for this purpose due to the larger key size and

stronger security.

One major additional benefit of using an industry stan-

dard such as AES is that it meets many compliance

requirements or recommendations for the use of in-

dustry standard encryption. This includes the PCI Data

Security Standard (PCI-DSS), HIPAA, FFIEC, and the EU

General Data Protection Regulation (EU GDPR).

EBOOK:THE ENCRYPTION GUIDE

DOWNLOAD





http://info.townsendsecurity.com/ebook-the-encryption-guide-0?utm_campaign=eBOOK%3A%20SQL%20Server%20Encryption&utm_source=eBook%3A%20SQL%20Server%20Encryption



Page 4


IT IS NOT POSSIBLE TO DISCUSS AN ENCRYPTION

strategy without discussing the protection of encryp-

tion keys. An encryption strategy is only as good

as the method used to protect the encryption keys.

Encryption algorithms such as AES and Triple DES are

public and readily available to any attacker. The pro-

tection of the encryption key is the core to the security

of the encrypted data. This is why security profession-

als consider the loss of the encryption key as equiva-

lent to the loss of the digital assets. Once an attacker

has the encryption key it is trivial to decrypt and steal

the data.

Generating strong encryption keys and protecting

them is harder that it might at first appear. The gener-

ation of strong encryption keys depends on the use

of random number generation schemes, and modern

computers do not excel at doing things randomly.

Specialized software routines are needed to generate

strong encryption keys. Encryption keys must also be

securely stored away from the data they protect, and

yet must be readily available to users and applications

that are authorized to access the sensitive data. Au-

thenticating that a user or application is authorized to

an encryption key is a large focus of key management

systems.

Over the years standards and best practices have

emerged for encryption key management and these

have been embodied in specialized security appli-

cations called Key Management Systems (KMS), or

KEY MANAGEMENT

Enterprise Key Management (EKM) systems. The

National Institute of Standards and Technology (NIST)

has taken a lead in this area with the creation of Spe-

cial Publication 800-57 entitled “Recommendation for

Key Management”. In addition to this important NIST

guidance, the organization publishes the Federal

Information Processing Standard (FIPS) 140-2 “Security

Requirements for Cryptographic Modules”. To serve

the needs of organizations needing independent certi-

fication that a key management application meets this

standard, NIST provides a validation program for FIPS

140-2 compliant systems. All professional key manage-

ment systems have been validated to FIPS 140-2.





Page 5


When protecting sensitive SQL Server data with en-

cryption, look for these core principles of key manage-

ment:

• Encryption keys are stored away from the data

they protect, usually on specially designed

security devices or dedicated virtual services.

• Encryption keys are managed by individuals

who do not have access to the data stored

in the SQL Server database (Separation of

Duties).

• Encryption key management requires more

than one security administrator to authenticate

before performing any critical work on keys

(Dual control).

• Key retrieval requests from users and

applications are authenticated using industry

standard methods.

• Encryption management and key usage are

logged in real time and logs are stored on

secure log collection servers.

• Encryption key management systems

have been validated to FIPS 140-2 and the Key

Management Interoperability Protocol (KMIP).

These are just a few of the core requirements for

deploying a professional key management solution to

protect your SQL Server data.

PODCAST:SQL SERVER ENCRYPTION OPTIONS

DOWNLOAD

KEY MANAGEMENT (CONTINUED)





http://info.townsendsecurity.com/sql-server-encryption-options?utm_campaign=eBOOK%3A%20SQL%20Server%20Encryption&utm_source=eBook%3A%20SQL%20Server%20Encryption



Page 6


ONCE WE MAKE THE DECISION TO ENCRYPT

data in our SQL Server database we then have to

decide where to implement that encryption. We have

a number of choices on how and where to implement

encryption. We could implement it using self-encrypt-

ing hard drives, or file or volume level encryption, or

in applications that use the SQL Server database. It

might help visualize these options by imaging a Five

Layer Cake like this:

At the very lowest level we have the disk drives that

store our data. At the next level up we have the file

input/output facilities provided by the operating sys-

WHERE TO IMPLEMENT ENCRYPTIONSECURITY & THE FIVE LAYERS

tem. Then we come to the database level where SQL

Server lives. Above that is the layer of our applications

that read and write information into the database. And

finally at the highest level we have the network layer

services that connect our endpoints.

Choosing where to implement encryption has securi-

ty implications. Generally, the higher the layer where

we implement encryption, the better security we can

achieve. But there is not a hard-and-fast rule about

this. There are some tradeoffs at each layer. The only

certain thing we can say is that not implementing en-

cryption leaves us terribly exposed to loss!

SELF-ENCRYPTING DRIVES, SSDs, ETC

FILE SYSTEM (FILE/FOLDER/VOLUME)

DATABASE

APPLICATION

NETWORK SERVICE





Page 7


AT THE VERY LOWEST LAYER OF OUR CAKE WE

have the physical storage mechanisms for our data.

This is a hard disk drive, flash storage, or a disk array.

It doesn’t matter if we are using cloud infrastructure,

traditional IT systems, flash storage, or a converged

technology. Data comes to rest on a physical storage

device.

Encryption can be implemented at

this layer. Self-Encrypting Drives,

or SEDs, are a good example of

this. Almost all disk drive manufac-

turers offer SEDs in their product

line. Even if you are deploying SAN

storage systems these can be de-

ployed with Self-Encrypting Drives.

SEDs insure that all data written to the disk, in fact

everything written to the disk, is encrypted. By default

each drive has an encryption key stored on the drive

and the drive firmware uses it to perform encryption

of the data stored on the drive. Key management may

optionally be used at the disk management level to

implement protection of the encryption key.

Encryption at Layer 1 provides the most basic protec-

tion. In essence, it helps prevent data loss if the drive

is removed from the system and it is subsequently lost

or stolen. Because the drive does not distinguish any

right of a user to the encrypted data, it is considered

the least effective level of encryption security.

LAYER 1

SELF-ENCRYPTING DRIVES, SSDs, ETC

Layer 1 encryption is implemented by hardware man-

ufacturers and is not something that an organization

can implement on their own. You must purchase disk

hardware or SAN storage from a manufacturer that has

implemented disk encryption in their solution. Most

disk drive manufacturers now provide self-encrypting

drives in their product lineup and it is not difficult to

source SEDs for the underlying storage of your SQL

Server database system.

Encryption key management varies a great deal from

one vendor to another. In some cases no key manage-

ment is provided, or a simple one-key implementation

is provided. However, as SED and SAN technologies

have evolved we are starting to see true key man-

agement capabilities in SED and SAN storage, usually

based on the KMIP standard.

Cloud service providers (CSPs) vary a great deal in

their implementation of disk level encryption. Many

larger CSPs offer encrypted drives as a default, al-

though some only offer this to their virtual private

cloud customers. Smaller ISPs may offer encrypted

drives at an additional cost, or not support this at all.

Customer control of encryption keys for disk encryp-

tion is non-existent and presents a challenge for orga-

nizations around key custody.

Encryption & Tokenization:

Key Management:

Secure Communications:

Logging:

Authentication

eBook

Podcast

Video

Blog

White Paper

Solution Brief/Data Sheet

Case Study

Resource Kit





Page 8


ENCRYPTION AT THE FILE SYSTEM IS THE NEXT

level in the hierarchy and is usually accomplished by

taking advantage of available operating system hooks

for file input and output. Layer 2 encryption may be

done at the file level, or for all files in a folder, or for all

folders on a volume. Typically, a block of data being

written to disk by a database or an application is in-

tercepted and encrypted on the fly. When data blocks

are read from the disk the data is decrypted and pre-

sented to the application.

With some file system encryption solution additional

security controls may be added. For example, the user

requesting the data read from disk may be validated

to insure proper authorization. However, many file

input/output systems defeat the ability to perform this

check by optimizing file I/O operations.

Generally the level of security with Layer 2 file system

encryption is a bit better than just disk encryption.

Encryption key management is often implemented

in more secure ways. There is, however, no granular

control over the actual sensitive information being

accessed, no ability to apply selective data masking or

access controls.

The Windows operating system now supports file and

volume level encryption with BitLocker. You will also

find a number of commercial systems that provide this

level of encryption. There are still operating systems

such as IBM Enterprise servers (IBM i or AS/400) and

LAYER 2

FILE SYSTEM (FILE/FOLDER/VOLUME)

IBM System z Mainframe where file system encryption

is not available or very minimal.

At Layer 2, encryption key management is still a major

challenge. Windows BitLocker does not implement

standard key management interfaces. Due to the

weakness in key management support the native Win-

dows BitLocker solution is not preferred by Enterpris-

es. Commercial solutions do a better job of address-

ing key management and are preferable for Layer 2

encryption.

Cloud service provides vary a great deal in the types

of file, folder and volume encryption services they

offer. For customers of Microsoft SQL Server this

layer of encryption will be managed in their Infrastruc-

ture-as-a-Service implementations of Windows SQL

Server.





Page 9


IN OUR LAYERED VIEW OF THE LANDSCAPE FOR

encryption, the database is at Layer 3. Almost all com-

mercial databases now support some type of encryp-

tion in the database itself and this includes SQL Server

since SQL Server 2008. This includes the encryption

of the entire table space which is called Transparent

Data Encryption, or TDE. And it includes the encryp-

tion of data at the column level which is called Column

Level Encryption or Cell Level Encryption (CLE). SQL

Server supports both of these approaches for Enter-

prise editions of the database.

Encryption at the database layer provides some dis-

tinct advantages:

• Encryption is optimized for database perfor

mance in way that is not possible in Layer 2 file

system encryption solutions.

• Encryption key management may be better

integrated into the encryption implementation.

• Encryption services are better integrated

with other database access control services

resulting in fewer security gaps.

There is still no standardization in SQL Server or other

database systems in how encryption is defined and

implemented. This means that database portability

remains an issue for organizations that desire to retain

a level of independence from the database vendor.

LAYER 3

DATABASE ENCRYPTION

In cloud environments SQL Server encryption is sup-

ported through Infrastructure-as-a-Service implemen-

tations and works exactly as it would in a traditional IT

data center.

WHITE PAPER:Encryption & Key Management for Microsoft SQL Server

DOWNLOAD





http://info.townsendsecurity.com/encryption-key-management-sql-server-microsoft?utm_campaign=eBOOK%3A%20SQL%20Server%20Encryption&utm_source=eBook%3A%20SQL%20Server%20Encryption



Page 10


IN OUR LAYERED VIEW OF THE ENCRYPTION

landscape the application is Layer 4. Application

encryption involves the use of an encryption library

and a key retrieval service, or an encryption service

provided by a vendor’s HSM

or a cloud service provider.

Encryption at the application

layer fundamentally means

that you are encrypting data

before inserting it into a

database or other storage

mechanism, and decrypting it

after you retrieve the data. It

provides a very granular level

of control of sensitive data

and allows for the application

of user accesses controls,

program access control, data

masking, and other security

controls. Many feel that application layer encryption is

the most secure way to protect data.

There are now many choices of encryption libraries for

use with SQL server. If you use SQL Server Extensible

Key Management (EKM) with Transparent Data Encryp-

tion, Microsoft uses their own AES encryption librar-

ies to perform encryption of the table space. If you

use SQL Server EKM Cell Level Encryption, you have

some choices in what encryption library you use. Most

developers will use the native Microsoft .NET AES

software library as it performs very well and is readily

LAYER 4

APPLICATION ENCRYPTION

available. Of course, if you are not using the SQL EKM

support, you still have access to the .NET AES encryp-

tion libraries.

If your applications are imple-

mented in a language such

as Java, PHP, Python, Perl or

other application language,

you have access to very good

encryption libraries provided

by the language. For exam-

ple, Java includes native AES

encryption libraries that you

can use for application layer

encryption. Other languages

offer similar support. It is now

rare that you would need to

look beyond the encryption

facilities of the development

language or operating system libraries to encrypt your

data in SQL Server.

With a Layer 4 encryption strategy you must also ad-

dress encryption key management. Key management

is not addressed by language or operating system

facilities in an adequate manner. This means looking

to a key management solution from a vendor or from

a cloud service provider. There are many vendors of

encryption key management that integrate well with

the Microsoft environment and SQL Server. These

offerings span traditional Hardware Security Mod-

“Encryption at the application

layer fundamentally means

that you are encrypting data

before inserting it into a

database, and decrypting it

after you retrieve the data.

Many feel that application

layer encryption is the most

secure way to protect data.”





Page 11


ules (HSMs), VMware instances, and native dedicat-

ed cloud offerings. Typically you will use a vendor’s

software library to retrieve a key, or you can use the

Key Management Interoperability Protocol (KMIP) to

retrieve a key. KMIP provides a vendor neutral method

of key retrieval, but may not offer the level of auditing,

high availability failover, and other features that are

important for enterprise customers.

Lastly, we should not overlook the option of using an

encryption-as-a-service mechanism. Many key man-

agement HSMs, VMware instances, and cloud key

management offerings also provide encryption as a

service. That is, you can send data to the key server

to be encrypted or decrypted and returned to your

application on a secure connection. This is often a

preferred method in more exposed environment like

web applications or kiosks as the encryption key is not

exposed in the process. With encryption as a service

care must be taken that the key server provides ade-

quate performance.

Generally cloud service providers and Infrastruc-

ture-as-a-Service implementations work at the applica-

tion layer as expected. With some Platform-as-a-Ser-

vice (PaaS) offerings it is important to review how well

the PaaS environment supports encryption and key

management.

APPLICATION ENCRYPTION (CONTINUED)

MORE INFORMATION

WEBINAR:ENCRYPTION & KEY MANAGEMENT WITH MICROSOFT SQL SERVER

VIEW WEBINAR





http://info.townsendsecurity.com/encryption-key-magement-sql-server?utm_campaign=eBOOK%3A%20SQL%20Server%20Encryption&utm_source=eBook%3A%20SQL%20Server%20Encryption



Page 12


THE FINAL LAYER THAT CAN PROVIDE

encryption for SQL Server resides at the network layer,

with some variations in the implementation. A Layer 5

approach inserts an application in front of SQL Server,

either as a node on the network layer, or as an imple-

mentation on the client side. This type of implemen-

tation encrypts data on the way to the server hosting

SQL Server, and decrypts the data after it leaves SQL

Server. A small number of third party vendors provide

this type of service.

LAYER 5

NETWORK SERVICE ENCRYPTION

In SQL Server 2016 Microsoft introduced Always En-

crypted, a client side architecture that encrypts data

at the client before it is transmitted to the SQL Server

database. This facility may be attractive to cloud cus-

tomers as all of data is encrypted before being stored

in the cloud. The issues of key custody are therefore

minimalized, as is the security risk in the cloud. Of

course, the Always Secure implementation is respon-

sible for both encryption and key management. For

some customers Always Encrypted will not be appro-

priate due to the limitations in the SQL functionality.

SUMMARY

MICROSOFT CUSTOMERS HAVE MANY CHOICES in how they ap-

proach encryption of sensitive data in Microsoft SQL Server databases.

Encryption is readily available in the Windows operating system (.NET

framework) and in the many languages used to build applications that use

SQL Server. The many choices mean that customers can readily find the

security they need at an affordable price. Compromises related to perfor-

mance and key management are no longer necessary, and the maturity

of the many vendor solutions takes the risk out of a SQL Server encryp-

tion project.





Page 13


“A very cost effective solution in terms of performance,

manageability, security, and availability. As a result, my company

was quickly able to implement full database encryption leveraging

the AKM as our key management solution in weeks. Comparable

solutions could have taken months.”- CERTAIN

TOWNSEND SECURITY IS HELPING MICROSOFT

SQL Server customers with Alliance Key Manager. The

solution includes the Key Connection for SQL Server

application to help Microsoft users implement Trans-

parent Data Encryption (TDE) and Cell Level Encryp-

tion (column level encryption) without the need for

application development. This application installs as

a service on SQL Server and provides the Extensible

Key Management (EKM) provider software. With inte-

grated support for multiple, redundant AKM key serv-

ers Microsoft customers can deploy encryption rapidly

and without programming.

Alliance Key Manager is FIPS 140-2 compliant and

in use by over 3,000 organizations worldwide. The

solution is available as a hardware security module

(HSM), VMware instance, and in the cloud (Amazon

Web Services, Microsoft Azure, and VMware vCloud).

Townsend Security offers a 30-day, fully-functional

evaluation of Alliance Key Manager.

ALLIANCE KEY MANAGER

30-DAY EVALUATION

ALLIANCEKEY MANAGER

REQUEST EVALUATION

• FIPS 140-2 and KMIP compliant enterprise key manager

• Available as an HSM, VMware, or in the cloud (AWS, Microsoft Azure)

• Affordably priced, with no restric tions on server connections or client side applications

• Meet compliance regulations like PCI DSS, HIPAA, FFIEC, and more





http://info.townsendsecurity.com/akm-for-SQL-Server

http://info.townsendsecurity.com/akm-for-SQL-Server

http://info.townsendsecurity.com/akm-for-SQL-Server?utm_campaign=eBOOK%3A%20SQL%20Server%20Encryption&utm_source=eBook%3A%20SQL%20Server%20Encryption

Page 14


TOWNSEND SECURITY CREATES DATA PRIVACY

solutions that help organizations meet evolving

compliance requirements and mitigate the risk of data

breaches and cyber-attacks. Over 3,000 organizations

worldwide trust Townsend Security’s NIST and FIPS

140-2 compliant solutions to meet the encryption

and key management requirements in PCI DSS,

HIPAA/HITECH, FISMA, GLBA/FFIEC, SOX, and other

regulatory compliance requirements.

CONTACT TOWNSEND SECURITY

www.townsendsecurity.com

@townsendsecure

724 Columbia Street NW, Suite 400

Olympia, WA 98501

360.359.4400

ABOUT TOWNSEND SECURITY





http://bit.ly/24VG2rN


http://bit.ly/24VG2rN

Date post:	21-Jun-2018
Category:	Documents
Upload:	doantruc
View:	220 times
Download:	0 times

MICROSOFT SQL SERVER - Townsend Security · self-encrypting drives, ssds, etc file system...

Documents