Enterprise Encryption White Paper

7/28/2019 Enterprise Encryption White Paper

1/8

White paper

2 Wht is eypto? Key Exchg d Mgmt

Symmetric Encryption

Asymmetric Cryptography

Hashing Algorithms

Points of Encryption

5 Protecting Data in Motion

6 Pottg Dt t rst

us Systms

7 Protecting Data on Servers

7 Arrival of Windows 8

8 CDW: A Security Partner at Gets IT

Table of Contents

EntErprisE..

Encryption..

Its critical to understand how a deense-in-depth strategycan protect the most precious inormation asset: data.

Executive SummaryOrganizations run on inormation, and or many, inormation

is their most valuable asset. Keeping inormation sec ure in a

highly connec ted and highly mobile world has become a toppriority. Encryption o inormation is commonly cited as a

proactive deensive measure.

By encrypting inormation, an organization has greater

deenses against loss o sensitive data. Encryption

strengthens the secu rity posture and is oten required by

regulatory, privacy and compliance regimes.

However, encryption by its very nature can c reate

challenges. Entities with mixes o public and p rivate

networks, virtual private networks (VPNs), applications,

load balancers and layers o servers which is to say most

can easily miss spots where encryption should be applied ormisuse encryption.

aking the time to dene an enc ryption strategy gives I

administrators a clear expec tation o what their roles and

responsibilities are. By classiying se nsitive or regulatory-

driven data, security-killing ambiguity can be avoided,

providing the best deense in depth and strongest security

posture available.

tWEEt tHis!
http://twitter.com/intent/session?return_to=%2Fintent%2Ftweet%3Ftext%3D%2520Enterprise%2520encryption%2520white%2520paper%2521%2520http://tinyurl.com/ag537bn%2520%40CDWNewshttp://twitter.com/intent/session?return_to=%2Fintent%2Ftweet%3Ftext%3D%2520Enterprise%2520encryption%2520white%2520paper%2521%2520http://tinyurl.com/ag537bn%2520%40CDWNews


2/8

EntErprisE Encryption2

Wht is eypto?Beore diving into when to use encr yption, its useul to have

a brie review o the most signicant terms and concepts in

encryption, especially as they pertain to enterprise security.

Because many o the algorithms in encr yption have changed

over the past ew years, security experts who have not

ocused on encr yption may want to veriy that they are up to

date with algorithms and concepts.

In the enterprise context, the term encryption broadly

includes at least ve specic technologies:

Key exchange algorithmsSymmetric (private) encryption algorithmsAsymmetric (public) encryption algorithmsHashing algorithmsDigital certicates and public-key inrastruc ture (PKI)Although the speci c algorithms in each change rom time to

time, the core ideas remain the same.

Best Practices TableKey Exchange and Management

Most encryption o data is done using symm etric (private key)

encryption, meani ng that both the sender and receiver o the

data must have the same key in hand.

When encrypting data at rest (such as in a database or in a le

system), a single long-lived encryption key has to be c reated

and managed in some way. Where and how the key is stored

varies dramatically rom product to product.

In many cases, the key is locked using a PIN -type

mechanism, s uch as a password or even a our-digit numb er.

When evaluating key management systems, the strength othe key can be compromised i the key management system is

not well designed or does not require a long enough key itsel.

For example, i a 256- bit key is protected in a key

management system with a our-digit PIN, the enc ryption

could be compromised by someone gue ssing the our-digit

PIN or simply brute-orcing the PIN (trying each o the 10,000

combinations). In some cases, such as when using smartcards,

the key management system is hidden in some sel-protective

hardware. Tis can reduce the likelihood o a brute-orce

attack on the key management system, because the sel-

protective hardware might destroy its copy o the key ater

some number o incorrect attempts.

Although most data at rest key management systems

are easy to understand and evaluate, data in motion key

exchange is more opaque to application managers. Indeed,

most network and application ma nagers are unaware how

their keys are exchanged, simply hiding behin d the hope that

Secure Sockets Layer (SSL) or ransport Layer Security

(LS) in the case o network trac will magically keep data

rom prying eyes.

a eog Dsog

Key

mgmtWell-understood keymanagement systems

Short personalidentication numbers(PINs) or protectinglong keys

Key

exchange

DieHellmankey establishmentprotocols

One-sided keyestablishment, ascommonly used inSecure Sockets Layer(SSL) and ransportLayer Security (LS)

Symmtypto

Advanced EncryptionStandard (AES)encryption

Data EncryptionStandard (DES), 3DESencryption, RC4encryption

Symmtky szs

256-bit AES keys Eec tive key sizesshorter than 128-bits

asymmtyptogphy

Rivest-Shamir-Adleman (RSA)algorithm with keysizes greater than1,023 bits and greaterthan 2,047 bits orlong-term critical keys

RSA with key sizesshorter than 1,024 bits

Elliptic curve

yptogphy(ecc)

Use o ECC when

mobility is important

For signing and key

agreement i there isno specic mobilityor perormancerequirement

Hshalgorithms

Secure HashAlgorithm2 usingSHA-256 or SHA-512

Message-DigestAlgorithm or MD5(strongly) and SHA-1(where possible toswitch to SHA-2)

Wireless

styWi-Fi ProtectedAccess 2 (WPA2)with AES

WPA, non-AESencryption and allpredecessor systems

a d-to-d ypto sttgytakes the following steps:

Sets both minimum and maximum requirements or whatdata should be encrypted, when it should be encrypted and

how it should be encrypted

Describes how keys are managed and controlled, and howkey disclosure or loss is handled

Denes specic situations in which data does not need tobe encrypted, or should not be encrypted

Covers common operational procedures (such as backups)and exceptional operational procedures (such as disaster

recovery), along with associated policies

Provides guidelines or encryption and hashing algorithms,certicate management, key lengths and other

cryptographic parameters

tWEEt tHis!


3/8

800.800.4239 | CDW.com

Te best prac tice or all key exchanges is to require that a

DieHellman algorithm be used or key management and

exchange or any network application. Te IP Secur ity (IPSec)

protocol, used or most site-to-site and some remote access

VPNs, does this by deault. But the very pop ular SSL and LS

protocols do not.

In act, key exchange is one o the dirty little secrets o

SSL and has led to airly spectacular secu rity ailures in thepast. For instance, one o the most popular web browsers

selected poorly chosen ran dom number generators to create

encryption keys, making a brute-orce attack simple.

Generally, key exchange in SSL (and LS) is chosen by the

server based on a list o options oered by the client. Security

experts generally classi y one-way key exchanges, in which

one party makes up a key and sends it (protected) to the other

party, as much less s ecure than two-way key exchanges, in

which both parties contribu te to the randomness and entropy

o the key.

Even when the client is not at au lt or oering (and the serveror selecting) a less-secure key exchange, this mechan ism

in SSL/LS allows a third party to attack the security o

the connection. Tis is not by aking up a cer ticate, but by

modiying the SSL/LS negotiation to select poor security

options that are easily cracked.

Te deault or most browsers when interacting with Microsot

application servers (such as Mic rosots Internet Inormation

Services) is to select insec ure (one-way) key exchanges,

unless specically congured to prohibit this. Although

Microsot, since Windows N days, has made it possible to

modiy the allowed set o key exchanges, doing so requires

customization o keys within the registry, ar o the beaten

path or most Microsot server managers.

Unix-based servers using OpenSSL are more variable in what

they will select, depending on the security-consciousness

o the web servers developer. Application managers should

edit their OpenSSL conguration le s to block less secure key

exchange methods.

o help identiy potentially weak keys, network managers can

use some rewalls and most intrusion protection system tools

to alert, or even block, poorly chosen cipher suites.

Symmt eyptoMost bulk encr yption encryption over more than a ew

octets o data is done using symmetric encryption . Tis is

true or both data at rest and data in motion. Even in cases

where the amount o data may be small, such as individual

email messages, symmetric encryption is commonly used.

For example, in the PGP cryptosystem, which is most oten

used or encrypted and authenticated email, each email

message is encrypted using a symmetric (pr ivate key)

algorithm, and only the encry ption key itsel is protected

(encrypted) using asymme tric (pub lic-key) cryptography.

Most I proessionals have airly good working knowledge

o symmetric encr yption. However, there are two important

points to highlight: encryption choices c hange over time, and

key length matters.

For many I proessionals, cryptography star ted with the

U.S. Data Encryption Standard (DES), an IBM-d eveloped and

U.S.-standardized algorithm or encryption using a key size o

56 bits (64 bits o which are parity bits). DES is no longer used,

as brute-orce attacks on DES have been shown to succeed

in less than 24 hours. Tis means that any old data encrypted

with DES, or which was transmitted in the past and could h ave

been captured by an attacker, is eectively unencrypted.

Although DES was not commonly used in commercial

computing, a variation on DES has seen heavy use as

the preerred encryption algorithm in most IPSec VPN

deployments: 3DES (usually reerred to as triple-DES),

which has an eective 112-bit key length, has withstood

the test o time and is still considered a secure encr yption

algorithm. However, in 2001, the U.S. government issue d a newFederal Inormation Processing Standard (FIPS) that uses the

Advanced Encryption Standard (AES) as a replaceme nt or

DES and 3DES.

AES supports dierent key lengths, but the common lengths

are 128 bits (the minimum) and 256 bits (the maximum), with

192 bits occasionally selected as halway in between.

As a best practice, and to avoid any questions o negligence,

network and application managers shou ld deploy AES or all

new encryption applications and VPN deployments, selecting

the 256-bit key length wherever possibl e. However, or

inormation that is sensitive or only a shor t period otime, the 128-bit key size is considered secure against

contemporary attacks.

Another important a lgorithm to be aware o is RC4. A stream

cipher, rather than a block cipher suc h as 3DES, RC4 is oten

selected or streaming applications. It is used in the original

wireless encryption algorithm, Wired Equivalent Privacy

or WEP (with a 40-bit key), as well as Bitorrent, SSL/

LS, Microsot Remote Desk top Protocol (RDP) and Skyp e.

Although RC4 can have long key lengths (thousands o bi ts in

some cases), almost all applications based on RC4 use a length

ranging rom the minimum allowed, 40 bits to 256 bits.

Bt fog Pins

In 2012, DataGenetics President Nick Berry published his

analysis o our-digit PINs based on the many password les

that have been leaked over the years, looking in detail at 3.4

million our-digit passwords. He ound that a mere 20 PINs

account or about 27 percent o the our-digit passwords:

1234, 1212, 1004, 2000, 6969, 1122, 1313, 4321, 2001, 1010

and the 10 PINs in the orm 0000, 1111 and so on. Tat means

that brute orcing a PIN oten doesnt require trying 10,000

our-digit combinations. Instead, about a third o the time,

it requires simply trying these 20 possibilities.
http://www.cdw.com/default.aspxhttp://www.cdw.com/default.aspx


4/8


Although RC4 is still heavily used, it is a poor choice or a

couple o reasons. Because RC4 was used in WEP (the original

encryption protocol with 802.11 Wi-Fi LANs), it has become

synonymous with poor secu rity. Although WEP itsel was at

ault, not the RC4 algorithm, the association between WEP and

RC4 has caused many sec urity proessionals to shy away rom

the algorithm, either rom ignorance or simply to avoid having

to explain why RC4 wasnt the reason that WEP was insec ure.Additionally, RC4 has come under a number o attacks rom

cryptographers. And several issues have been ound that

question the long-term viability o RC4 or enterprise use.

Neither o these is a reason to run screaming rom RC4. But

network and application managers shou ld cross RC4 o their

list or any uture deployments and should be look ing at places

where RC4 might be in use such as in SSL/LS servers,

where it is still common, especially in Microsot environments.

Network managers will notice a wide varie ty o new

encryption algorithms also popping up, such as Camellia, which

was introduced and patented by NEC and has been selectedby some application providers. Generally, unless a specic

requirement is made to use a nonstandard algorithm, AE S

should be selected.

Its cryptographic properties have been more careully studied

than other, similar algorithms. In addition, Intel and, more

recently, AMD have included AES acceleration in their CPUs,

giving a signicant perormance increase or servers and

helping to improve overall security by avoiding certain types o

timing attacks that have been proposed against AES.

asymmt cyptogphyAlthough encryption is the primary goal, many encryption

systems depend on a combination o tools to accomplish other

tasks. Public-key cryptography is one o those tools. Although

public-key cryptography is rarely used or encryption o long

strings o data because o its airly slow perormance, public

keys are used heavily or signing messages (authentic ation

and integrity checking) as well as encrypting short strings

(such as sessi on keys).

One algorithm is heavily use d in public-key cryptography:

Rivest-Shamir-Adleman (RSA), the original public-key

cryptography algorithm rom 1978. Te Digital Signature

Algorithm, or DSA, based on a 1984 algorithm developed by

Egyptian cryptographer aher Elgamal and used only or

signing, not encrypting, is also widely available.

When network managers have a choice between the two,

typically RSA is more widely supported mainly because it

can be more widely applied.

One important consideration or security-conscious

managers is key size. RSA keys should be ch osen based on

the sensitivity o the inormation being protected and the

expected lietime o the sensitivity. Keys sizes o 512 bits

are now considered insecure one was broken in 1999 in

seven months.

RSA (the company), through its RSA Laboratories, suggests

that organizations select key sizes o 1,024 bits (considered

about equal to an 80-bit symm etric encryption key) or

ordinary enterprise use and 2,04 8 bits (similar in strength to

a 112-bit symmetric encry ption key) or extremely valuable

data, such as certication au thority root keys.

For inormation that must be p rotected or more than 20

years, the U.S. National Ins titute o Standards and echnology

recommends a 3,072-bit RSA key, which is roughly equivalen t

in strength to a 128-bit symmetric encryption key.

An even more important area o attention when using RSA is

key liecycle. Most RSA (and DSA) keys are used many times

over their lietime; or instance, when incorporated into digital

certicates. Enterprise security managers should strictly

require that keys be replaced every ew years. A maxim um o

three years is considered good practice.

Hashing Algorithms

Hashing is used to ensure that inormation is not modied

in transit. Hashing is heavily used in all aspec ts o encryption,

including in VPNs, digital signatures and certicates,

and email encryption.

Hashing is oten an aterthought or encryption applications,

but improperly selec ted hash algorithms have resulted in

some spectacular and very public ailures. In the 1990s,

What Is Elliptic Curve Cryptography?

Elliptic curve cryptography is popping up in application

and virtual private network (VPN) servers, driven by

the increasing number o low-speed devices, such as

smartphones and tablets, that are connecting to the

Internet. ECC has been used to speed up both digital

signatures and key agreement, two computationally

intensive operations.

Te main idea behind ECC is that smaller key sizes and

simpler computations provide security equivalent to much

larger key sizes o other algorithms. For example, a 3,072-bit

RSA public-key computation can be replaced by a 256-bit

ECC public-key computation with the same level o security.

Standards bodies have avoided use o ECC because someaspects o the cryptography are covered by patents owned

by Certicom (a subsidiary o Research in Motion or RIM). But

the cloud o uncertainty about public use o ECC has been

partially lited by a U.S. National Security Agency license o

the patents or government use.

Network and application managers ocused on supporting

mobile devices that can benet rom ECC, especially in the

U.S. government sector, should investigate the perormance

benets that it can ofer without compromising security.

tWEEt tHis!


5/8

800.800.4239 | CDW.com

security researchers b egan to identiy faws in one o the

two commonly used hashing algorithms, Message-Digest 5

(MD5). Te U.S. government replaced M D5 with Secure Hash

Algorithm-1 (SHA-1) in 1993 as a s tandard or ederal agencie s.

In 2005, SHA-1 was also shown to have internal cryptographic

weaknesses. So security-conscious systems managers

should avoid all use o SHA-1 and move to the n ewer SHA-2

algorithm. SHA-2 is actually a amily o hash algorithms withdierent size digests, so these may be reerred to in product

documentation by their hash sizes: SHA-224 and SHA-256

(32-bit-wide algorithms) and SHA-384 and SHA-512 (64-

bit). I 64-bit devices or servers are in p lace, SHA-512 will

give substantially better per ormance over SHA-256 and is

generally preerred.

Pots o eyptorying to make sense o the mishmash o encry ption

strategies can stress anyone, as overlapping options and a

whole host o what-i scenarios make it dicult to design

a holistic approach that doesnt over-encrypt or under-

encrypt. Although every enterprise application and network

environment is dierent, its helpul to divide encryption in to

two main categories: protecting data in transit and p rotectingdata at rest.

As a simple guidelin e, start by assuming that the two types o

protection are not connected in any way: Data that is already

encrypted on disk (at rest), or example, still needs protection

when sent over the network (in motion). In other words,

encryption strategies should assu me that all data needs to

be protected in motion, even i its already been encrypted at

some other layer.

Tis assumption has some key benets:

Data that is already encrypted gets additional protection,such as metadata hiding.

Any error on the application layer in missing encryption ispartially compensated or by encryption in motion.

Disconnecting at rest and in motion encryption simplieswhat i scenarios in environments where users connect

using dierent networks.

Pottg Dt MotoNetwork and application managers will nd comm on tools

or encryption at three dierent network layers: data link,

network and application. Tese are briefy detailed in this chart:

Encryption and the Cloud

When an organization doesnt control the inrastructure,

theres a huge question to answer: Will the organizations

cloud service provider saeguard its data? Or is it up to the

entity to do that?

Its critical to alleviate this concern through encryption

use. Any cloud application, whether private, public or

hybrid, must use an encrypted VPN or all communication.

Encrypting data in transit solves some problems and is a

clear requirement or any cloud-based application. But

encrypting data in transit doesnt help secure data at rest.

Cloud applications have two signicant risks that encryption

can help mitigate. One risk is amiliar: An application could

have holes or bugs that let an unauthorized party view

sensitive data. Te other risk, more specic to cloud service

providers, is that the inrastructure might not be secure.

Encrypting data in the app protects against both types o

risk but may not be desirable. For example, cloud-based

email, such as an outsourced Microsot Exchange service,

will easily support Secure/Multipurpose Internet Mail

Extensions to encrypt sensitive mail on the server. But

S/MIME presents a diferent set o problems, including

intererence with archiving and search, long-term key

storage issues, and generally weak support in popular

mobile and web-based email clients.

In some cases, encryption o data in the cloud is the easy

and an obvious choice, such as with ofsite storage or

backup, le sharing or collaboration. In other cases, such

as customer relationship management (CRM) or help desk

applications, encryption o data likely wont work, and

organizations must depend on the assurances, reputation,

auditing and best practices o their cloud service provider.

eyptoLy

Co mm on To ols Ad van tage s D isa dva ntages

Data link Media AccessControl (MAC)Securityprotocol(wired), WPA2(wireless)

Lowperormanceimpact; lowcongurationcost

MACsec(802.1ae) notcommonlysupported

Network IP Security(IPSec) VPN,SSL VPN

A combinationo authen-tication,encryption andaccess control

Requires aclient; has aperormanceimpact; isnot easy to

use in LANenvironments

Application SSL/LS,Secure Shelltunneling

Works orall users;generally doesnot requirespecializedclient

Can impactserverand clientperormance;oten is notcompatiblewith network-based data lossand intrusionpreventiontools


6/8


Unortunately, encrypting and protecting data at only one

layer doesnt solve all problems. Te result is that its too easy

to encrypt everything three (or more) times as it passes over

a corporate network simply by using normal security tools,

such as wireless W i-Fi Protected Access 2 (WPA2) encryption,

server-level SSL encryption and s tandard VPN products. Te

result is additional overhead and a perormance hit, especially

or remote users.Network and security ma nagers trying to reduce double (or

triple) encryption oten look at removing one o the encryption

layers to increase perormance and reduce complexity.

Generally, there is no reason to reconsider data-lin k layer

encryption. Data link encryption or wireless networks

doesnt actually create overhead or slow down trac in any

measurable way. I n addition, no one would consider deploying

an enterprise wireless network without using WPA2 (AES-

based) security, which includes authentication, encryption and

message integrity checking.

When providing direct access to encrypted applicationservers, host-based intrusion protection (includi ng break-in

evasion) is a clear necessity. Without it, a dedicated attacker

can attempt a brute-orce attack, which could go completely

undetected or unprotected. Opening up application servers

to direct connec tions also invites denial- o-service (DoS)

attacks using commonly available tools.

When an application server is hidden behind a VPN

concentrator, it is possible or a DoS attack to be launched

against the VPN concentrator. But the two-step disassociation

between the VPN concentrator and the actual appli cation

server leaves the application server protected, and also

presents a less obvious target to an attacker.

Te opposite approach leaves the n etwork-layer VPN

protection in place, but removes application-layer encryption.

Tis strategy is more common among perormance-conscious

application owners because it retains the minimum required

protections while oering the maximum perormance.

Te danger o this approach is that someone will make a

conguration error somewhere, perhaps months or years

ater initial deployment, and the unprotected application

server may be used in a way that does not oer encryption

o data in motion. When corp orate networks are very large,

or when inormation is very sensitive, unencrypted data

even over a LAN normally considered to be secure in most

organizations may not be acceptable e ither.

Tere is no perect way to avoid doubly encrypting trac.

But it is important that the application, network and security

teams agree on an approach or most enterprise applications .

By having a consistent view on how data in transit should

be encrypted, the risk o expens ive and embarrassing data

breaches can be signicantly reduced.

Pottg Dt t rstData at rest is encrypted or a variety o reasons, including

regulatory compliance. However, the main ocus o any

encryption deployment should be threat mitigation.

Tis can be broken down into two subsets: user devices

(smartphones, notebooks and de sktops), and servers and all o

their associated hardware (such as backup applian ces).

us SystmsFor phones, tablets, notebooks and desktops, the main

threat is loss o physical control o the system: outright the t,

misplaced or lost devices, borrowed devices and improper

destruction o data when systems are recycled.

When selecting encryption solutions or notebooks and

desktops, most organizations have the advantage o a

sophisticated inrastructure. In contrast, mobile devices

such as phones and tablets are usually handled by mobile

device management (MDM) sotware. Many o the unctional

requirements or encryption o notebooks and desk topsare impossible to meet in the world o mobile devices, so

enterprise managers may need to mix and match solutions to

cover all their users systems.

Te table below shows enterprise-level requirements or

user device encryption. Because the requirement or

encryption is now so common, all the desk top operating

systems (recent versions o Windows as well as Mac OS X)

and major mobile OSs (recent versions o Android as well as

Apple iOS) all cover a signicant subset o the requirements

below as a part o core OS services. But none cover all o them

with built-in encryption.

a rqmt

eypto Requires ull-disk encryption; per-le and per-directory leaves devices vulnerable to attack

authentiction Requires end-user authentication prior to bootand periodically thereater; hardware token(such as smartcard or USB dongle) is a goodtwo-actor addition

Key recovery Requires enterprise management (includingrevocation and replacement) and backup oencryption keys; no device can be encryptedwithout a key managed by the organization

Removable

media control

Requires control o removable writeable

media (especially USB drives, but also CD/DVDwriters); allow only or corporate-providedmedia meeting encryption requirements

Loggg,dt dcompliance

Requires standards certication (such as theFederal Inormation Processing Standardor FIPS 140), and ull logging and auditing todemonstrate compliance with policies andregulatory regime

etpsinfrstructure

tgto

Requires integration with enterprise directoryproduct (such as Active Directorys WindowsDomain) or user authentication and keymanagement and control

tWEEt tHis!


7/8

800.800.4239 | CDW.com

Protecting Data on ServersEncrypting data on servers is a more complicated process than

protecting user data or several reasons:

Multiple-access le sys tems (such as clustered le systems)or network-based ling may not be whole-disk encryptable.

Te threat o loss o physical control is low, but the threat oan intruder gaining access to the system is much highe r and

needs to be mitigated dierently.

For these reasons, most entities choose not to use ull-disk

encryption on servers and i nstead ocus on other threat

mitigation options including le- and older-based encryption

as well as endpoint security products, host-based intrusion

prevention, integrity monitoring, and a heavy dose o security

inormation and event management (SIEM) alerting on the logs

rom these systems.

Some types o data should always be encrypted, such as

personally identiab le inormation (PII), protected health

inormation (PHI) and or private nancial inormation (such as

credit card numbers).

Protecting such data by having applications encrypt and

decrypt on the fy is a common strategy. Although experience

has shown that application developers arent necessar ily good

at selecting c ryptography to protect sensitive inormation. A

better approach is to store the inormation in a database and

make use o one o the ransparent Data Encryption eatures

o the database (or an add-on package that provides DE).

DE supports real-time encryption and decryption o

data (and database transaction logs). Most DE products

including those built into some database management

systems suppor t hardware-based key protection. o

optimize perormance, these produc ts oten also allow

the database manager to select columns, tables or e ntire

databases or encryption.

As with any encryption produc t, DE tends to create issues

in scalability and high availability because keeping encrypted

inormation synchronized across databases, or distributed

across multiple systems, is more dic ult than the same task

with unencrypted inormation.

In large-scale applications, DE encryption may not be

suitable, making the use o application-layer encryption

and decryption necessary. But application managers should

ocus on built-in encryption/decryption acilities, such as D E,

and avoid creating custom encryption services.

Another issue or server environments is backup data

although this also applies to user devices. Obviously, having

unencrypted data on a backup tape that is beyond the

organizations control, or is loosely controlled, is just as bad

as having unencrypted data on a notebook in the trunk o

someones car. Tereore, even i the application and le

servers themselves are not encrypted, enterprise managers

should ensure that all backup data is encrypted.

Arrival of Windows 8

Windows 8 brings many o the same encryption eaturesavailable in Windows 7 and earlier versions, with min or twists.

Core encryption technologies that have been present in other

versions o Windows such as the IPSec VPN, SSL/LS in

Internet Explorer, certicate services and cryptographic

acceleration or compatible hardware are all still very much

present and should be amil iar to desktop managers.

Te biggest changes relevant to encryption have occurred

in the relatively new BitLocker and B itLocker o Go

(Microsots drive encryption solutions), and in Microsots

sandboxing technology. As in earlier versions, not every

edition o Windows 8 has the same eature set. For BitLocker,Microsots drive encryption solution, the Pro and Enterprise

editions are required.

BitLocker and some associated application programming

interfaces in Windows 8 have been updated based on customer

requests for a more user-friendly encryption solution.

Because Windows 8 operates on tablet, notebook and desk top

systems, and runs across multiple CPU architectures, some

internal changes were made to broaden drive encryption

capabilities. For example , sel-encrypting hard drives (oten

called eDrives) and advance d ormat drives (those with

4,096-octet rather than 512-octet sec tor size) are bettersupported in initial releases o Windows 8. Note that the use

o eDrives with Windows essentially delegates all trust and

security o the drive to Microsot.

Desktop managers may need basic input/output systems

(BIOS) updates, rmware updates or even Windows patches

to ully support BitLocker on all eDrives and advanced ormat

drives. Unsolved issues with BitLocker include SkyDrive cloud

storage encryption and interactions between BitLocker and

SharePoint.

Windows Flash Drive Encryption

with BitLocker

Since the release o Windows 7, Microsot has made it

possible to extend BitLocker o Go encryption o disk

volumes to USB volumes, such as portable thumb drives.

When a domain-connected Windows system has the

appropriate group policy, any insertion o a removable

volume can kick of BitLocker o Go tools that will enorce

encryption o the entire volume. Windows 7 and above

systems can read these encrypted devices automatically.

For older versions o Windows, the BitLocker Reader

application is available to decrypt a locked volume.


8/8

EntErprisE Encryption 800.800.4239 | CDW.com

Te inormation is provided or inormational purposes. It is believed to be accurate but could contain errors. CDW does not intend

to make any warranties, express or implied, about the products, services, or inormation that is dis cussed. CDW , CDWG and

Te Right echnology. Right Away are registered trademarks of CDW LLC. PEOPLE WHO GET IT is a trademark o CDW LLC.

All other trademarks and registered trademarks are the sole property o their respective owners.

ogether we strive or perection. ISO 9001 :2000 certifed121703 130204 2013 CDW LLC

BitLocker Administration is still in beta test with Microsot

BitLocker Administration and Monitoring version 2

(MBAM 2.0). But key new eatures that Microsot shipped in

beta versions last November include a sel -service portal to

resolve some issues without having to call help desk suppo rt

and compatibility between M BAM 2.0 and Microsot System

Center 2012 Conguration Manager. Other additions inc lude

changes to improve the end-user experience when installingand interacting with B itLocker and BitLocker o Go.

For a complete Windows 8 drive encryption solution, a v1. 2

(or later) rusted Platorm Module chip is highly recommend ed.

Although most devices being mad e today have PM chips,

some low-end consumer PCs do not. PM is cri tical or proper

storage o drive encryption keys and also or detecting certain

low-level attacks on the Windows operating system. Keep

in mind, some coun tries (or example China and Russia) have

strict PM regulations.

cDW: a Sty Ptat Gets ITEncryption reers to a comprehensive set o product oerings

to protect data and inormation assets rom multiple threats.

CDW oers a wide selection o security sol utions that protect

data, both at rest and in transit.

Your CDW account manager and solution architects are ready

to assist with every phase o choosing and leveraging the right

encryption solution or your I environment.

Our approach includes:

An initial discovery session to understand your goals,requirements and budget

An assessment review o your existing environmentand denition o project requirements

Detailed manuacturer evaluations, recommendations,uture environment design and proo o concept

Procurement, conguration and deployment o thenal solution

24x7 telephone suppor t, as well as ongoing productliecycle support

Sty assssmts CDW security assessments are

tailored to refect organizational needs. Each security report

highlights individual concerns and goals. CDW security

assessments inclu de analysis o any or all o the ollowing:

Internet security Dial-access security Internal network security Wireless network securityPartner or extranet security Data loss assessmentComprehensive assessment

Sophos Complete Security Suite

gives you the antivirus, endpoint

and mobile protection you need with

the device control, encryption, web

and email gateway security you

demand. And, because its all rom

Sophos, it works better together.

Its backed by a vendor you trust.

Even better, its so simple to use

youll actually turn it on delivering

exceptional protection that saves

you time and money.

McAee Endpoint Encryption

solutions use powerul encryption

algorithms and oer multiple layers

o data protection that address

specic risk areas. Encryption

is extended to desktop PCs,

notebooks, network les and

olders, removable media and

USB storage devices. Endpoint

Encryption allows you to

transparently secure a broader

scope o condential inormationincluding customer data, intellectual

property, legal and nancial records,

and employee communications

with no system perormance

degradation.

Symantecs encryption solutions

enable organizations to deliver data

protection with centralized policy

management through the optional

use o encryption management

server. Our solutions provide

standards-based technology,

centralized policy management,

compliance-based reporting and

universal management or your

encryption products.

cDW.om/sophos cDW.om/m cDW.om/symt

To learn more about CDWs security solutions, contact your CDW account manager, call 800.800.4239 or visit cDW.om/sty

tWEEt tHis!
http://www.cdw.com/default.aspxhttps://www.cdw.com/shop/search/results.aspx?key=sophos%7cmobile&SortBy=MostRelevant&searchscope=All&Contract=19876http://www.cdw.com/content/brands/mcafee/default.aspxhttp://www.cdw.com/content/brands/symantec/default.aspxhttp://www.cdw.com/content/solutions/it-security-solutions.aspxhttp://twitter.com/intent/session?return_to=%2Fintent%2Ftweet%3Ftext%3D%2520Enterprise%2520encryption%2520white%2520paper%2521%2520http://tinyurl.com/ag537bn%2520%40CDWNewshttp://twitter.com/intent/session?return_to=%2Fintent%2Ftweet%3Ftext%3D%2520Enterprise%2520encryption%2520white%2520paper%2521%2520http://tinyurl.com/ag537bn%2520%40CDWNewshttp://www.cdw.com/content/solutions/it-security-solutions.aspxhttp://www.cdw.com/content/brands/symantec/default.aspxhttp://www.cdw.com/content/brands/mcafee/default.aspxhttps://www.cdw.com/shop/search/results.aspx?key=sophos%7cmobile&SortBy=MostRelevant&searchscope=All&Contract=19876http://www.cdw.com/default.aspx

Documents

Enterprise Encryption White Paper