Rothke Computer Forensics Show 2010 Deployment Strategies For Effective Encryption

The Computer Forensics Show

Conference

April 19-20, 2010

New York, NY

Deployment Strategies for Effective Deployment Strategies for Effective

EncryptionEncryption

The

Computer

Forensics

EncryptionEncryption

Ben Rothke, CISSP, CISM, PCI QSA

Senior Security Consultant

BT Global Services

April 19, 2010

About Me

• Ben Rothke, CISSP CISM QSA

• Senior Security Consultant – BT Global Services

• In IT sector since 1988 and information security since 1994

• Frequent writer and speaker• Frequent writer and speaker

• Author - Computer Security: 20 Things Every Employee Should Know

(McGraw-Hill)

2

Overview

• Encryption internals are built on complex mathematics and

number theory

• Your successful encryption program requires a CISSP, CISA

and/or PMP, not necessarily a PhD

• Effective encryption requires attention to detail, good design,

combined with good project management and documentation

• Your encryption strategy must reflect this

– This is not a monologue – ask a question, share a comment at any time.

3

It’s 2010 – Where’s the Encryption?

• Many roll-outs nothing more than stop-gap solutions

• Getting it done often takes precedence over key management,

documentation, processes, etc.

• Many organizations lack required security expertise

• These and more combine to obstruct encryption from being • These and more combine to obstruct encryption from being

ubiquitous

• Adds up to a significant need for encryption deployment

strategies

4

Encryption strategy in 3 easy steps

1. Define your requirements

2. Know where your sensitive data resides

3. Create detailed implementation plans

• When implementing your encryption strategy, remember that • When implementing your encryption strategy, remember that

information security is a process, not a product.

5

Typical encryption nightmare scenario

• Monday 9AM – Audit report released to CEO

– Numerous failings, namely lack of strong encryption

• Monday 11 AM – CEO screams at CIO

• Monday Noon – CIO screams at CISO

• Monday 2PM – CISO screams at staff

• Tuesday – With blank check, CISO tells info security manager to order • Tuesday – With blank check, CISO tells info security manager to order

encryption equipment ASAP

• Thursday - Security team spends two days and nights installing/configuring

encryption hardware and software

• Six months later – Complete disarray with regard to encryption key

management. CEO screams at CIO, who fires the CISO.

• Next day – Interim CISO tells team to get encryption working by the

weekend

6

Encryption nirvana scenario

Stra

tegy

Data Mapping Implementation

Deployment

Define Drivers

Data

Policy

Initial Drivers• Business

Effective

Stra

tegy

Risk Modeling

Control Gaps

Management

Audit

Deployment

Data

Classification

Policy Definition

Policy

• Business

• Technical

• Regulatory

Effective

Encryption

7

Encryption challenges

• Operating systems and application vendors haven’t made it

easy and seamless to implement encryption

– Lack of legacy support

• Laws/guidelines often conflict or fail to provide effective

guidance

• Far too few companies have encryption policies and/or a • Far too few companies have encryption policies and/or a

formal encryption strategy

• Costs / Performance

– Up-front and on-going maintenance costs

– Performance hit

– Added technical staff

8

No one, not

even NSA, CIA,

KGB, or evil

No one,

including

yourself,

Effective Encryption Strategy

Encryption – a double-edged sword

KGB, or evil

hacker, can

read your data

yourself,

can read

your dataEffective Encryption Strategy

9

Common encryption deployment mistakes

1. Thinking encryption is PnP

– Hardware is PnP

– Making encryption work is not

2. Going to a vendor too early

– Vendors sell hardware/software

– You need requirements– You need requirements

3. Not being transparent to end users

– If it’s a pain to use, they will ignore/go around it.

4. Not giving enough time to design/test

– Effective encryption roll-outs take time

– Require significant details

– You can’t rush this!

10

Dealing with vendors

• When you drive the project

– You define the requirements

– You have chosen them

– Vendors provides best practices / assistance

– Vendor input can be invaluable

– Project succeeds

• They are brought in as the experts

– They are expected to put out a fire

– They spec out their product

– You don’t have internal expertise working with them

– Project fails

11

Encryption and the technically advanced airplane paradox

• TAA in theory have more available safety, but without proper

training for their pilots, they could be less safe than airplanes

with less available safety

• FAA found that without proper training for the pilots who fly

them, technically advanced airplanes don’t advance safety at all

• TAA presents challenges that under-prepared pilots might not • TAA presents challenges that under-prepared pilots might not

be equipped to handle

• Encryption is exactly like a TAA

• Your staff must be trained and prepared.

12

Encryption Strategy

• Mathematics of cryptography is rocket science

– But most aspects of information security, compliance and audit are not!

• Good computer security is simply attention to detail and good

design, combined with effective project managementdesign, combined with effective project management

• Encryption strategy must reflect this

• Define what needs to be addressed in the enterprise encryption

strategy

– Not everyone will need encryption across the board

– Policies need to be determined first as to what requires encryption

– Any information going over the Internet or internal source code

13

• Laptop encryption

• Database encryption

• Network encryption

• Smart cards

� Application encryption

� Storage encryption

� PDAs

USB

What should the strategy include?

• Smart cards

• Mobile encryption

• Wireless encryption

• Smart phones

• iPad/iPod/iPhone

� USB

� Floppies/CD-ROM/DVD

� Emerging technologies

14

Strategy prioritization

• Prioritize based on specific requirements and compensating

controls

– Start with assumption that by default, data need not be encrypted unless there is a specific requirement to encrypt that data or

– Identify high-risk situation where encrypting data will avert disaster

• Unnecessary or poorly prioritized encryption deployments may • Unnecessary or poorly prioritized encryption deployments may

do more harm than good

– false sense of security

– takes budget away from more pressing encryption requirements

– increases administrative burden

– locked out of your own data

15

Current state

• Evaluate current encryption strategy and policy

– In sync with industry security best practices?

• Encryption framework in place?

• Policies in place?

• Define what regulations must be complied with

Define Drivers

Data

Classification

Policy

• Document current encryption hardware /

software environment

Classification

Policy Definition

Policy

16

Analyze your encryption needs

• Protect data from loss and exposure

• Prevent access to the system itself?

• Does software need to access the files after encryption?

• Data to be transported securely? By what means?

• How much user burden is acceptable?

• How strong does the encryption need to be?

• Do you need to match the solution to the hardware?

• Regulatory, contractual, organizational policy

• Ask a lot of questions at this point!

17

Where are your encryption keys from?

• VPN connections

• SSL/TLS

• PKI/IdM

• User-generated keys

• File system encryption• File system encryption

• Third parties

• Trusted Platform Module (TPM)

– Built into news desktops and laptops

18

• Business

– Customer trust

– Intellectual property

• Technical

– AES, PGP, BitLocker, etc.

Define Drivers

Data

Classification

Policy

Drivers

– Increase in mobile devices

• Regulatory

– PCI / SoX / EU Privacy directive / ISO-17799

– State data breach laws

• Note: Keep a wider picture in mind when complying with specific mandates

Classification

Policy Definition

Policy

19

Documentation and policies

• Encryption must be supported by policies,

documentation and a formal system and risk

management program

– Shows work adequately planned and supervised

– Demonstrates internal controls studied and evaluated

• Policy must be:

Define Drivers

Data

Classification

Policy • Policy must be:

– Endorsed by management

– Communicated to end-users and business partners / 3rd-parties that handle sensitive data. If can’t meet company’s policies, don’t give access to your data

• Encryption responsibility should be fixed with

consequences for noncompliance

Classification

Policy Definition

Policy

20

Encryption processes

• Encryption is a process intensive

• Must be well-defined and documented

• If not implemented and configured properly, can cause system performance degradation or operational hurdles

Define Drivers

Data

Classification

Policy operational hurdles

• Improperly configured encryption processes give false sense of security

– Perception that confidentiality of sensitive information is

protected when it’s not

Classification

Policy Definition

Policy

21

Data classification

• Provides users with information to guide security-

related information handling

• Process must align with business processes

• Classification is dynamic

– Changes as data objects move from one class to another

– Changes as business strategies, structures and external

Define Drivers

Data

Classification

Policy – Changes as business strategies, structures and external

forces change

– Understand potential for change

– Embed appropriate processes to manage it

• Gartner: Organizations that do not have an effective data

classification program usually fail at their data encryption

projects.

Policy Definition

Policy

22

Data classification drivers

Define Drivers

Data

Classification

Policy

Four Category

• Secret

• Confidential

Five Category

� Top Secret

Highly Confidential

� Compliance, discovery, archiving, never delete retention policy,

performance, availability, recovery attributes, etc.

Policy Definition

Policy • Confidential

• Private

• Unclassified

� Highly Confidential

� Proprietary

� Internal Use Only

� Public

23

Encryption strategy

• Identify all methods of data input/output

• Storage media

• Business partners and other third parties

• Applicable regulations and laws

• High-risk areas

Strateg

y

Data Mapping

Risk Modeling • High-risk areas

– Laptops

– Wireless

– Data backups

– Others

Strateg

y

Risk Modeling

Control Gaps

24

Data discovery

• Identify precisely where data is stored and all data flows

• System wide audit of all data repositories

– Significant undertaking for large enterprises

– Process can take months

• Required to comply with PCI?

– Confirm you are not storing PCI-prohibited data– Confirm you are not storing PCI-prohibited data

– Manually review data flows within POS application to find files where results of card swipe are written

– PCI compliance staff should view relevant data files and verify they are not storing full track data

– Many fail PCI since they have flat (non-partitioned) networks in which card databases aren’t segmented from rest of network

25

Data-flow definition

26

Requirements analysis

• Define business, technical, and operational

requirements and objectives for encryption

• Define policies, architecture, and scope of encryption

requirements

• Conduct interviews, review policy documents, analyze

current and proposed encryption strategy to identify

Strateg

y

Data Mapping

Risk Modeling

current and proposed encryption strategy to identify

possible security gaps

• Determine liabilities

• Better requirements definition directly correlates to

successful encryption program

Strateg

y

Control Gaps

27

Legacy systems

• Most legacy systems not designed for encryption

• Legacy encryption options

– Retrofitting application so that encryption is built-in to

application functions

– Using encryption appliance that sits between app and database

– Off-loading encryption to storage mechanism or database– Off-loading encryption to storage mechanism or database

• Hardest platform – AS/400

28

• Data encrypted at creation

– First possible level of data security

• Little chance of encrypted data being intercepted,

accidentally or maliciously

– If intercepted, encryption renders it unreadable

• Can significantly increase processing overheadImplementation

Deployment

Full-disk / host-based encryption (at rest)

• Can significantly increase processing overhead

• Requires additional processing power/expense

• Highly secure and well-suited to active data files

• Large-scale data encryption can be unwieldy and impact

performance

• Vendors: Microsoft, Check Point, PGP, TrueCrypt

Management

Audit

Deployment

29

• Data leaves host unencrypted, then goes to dedicated

appliance for encryption

• After encryption, data enters network or storage

device

• Quickest to implement

• Can be easy to bypass

Implementation

Deployment

Appliance-based encryption

• Can be easy to bypass

• Costly

• Not easily scalable

• Good quick fix

– for extensive data storage encryption, cost and management

complexity of encrypting in-band can increase significantly

• Vendors: NetApp, Thales/nCipher

Management

Audit

Deployment

30

Storage device encryption

• Data transmitted unencrypted to storage device

• Easiest integration into existing backup environments

• Supports in-device key management

• Easy to export encrypted data to tape

• Easy to implement and cost-effectiveImplementation

Deployment

• Easy to implement and cost-effective

• Best suited to static and archived data or encrypting

large quantities of data for transport

• Large numbers of devices can be managed from single

key management platform

• Vendors: EMC, IBM, Hitachi

Management

Audit

Deployment

31

Tape-based encryption

• Data can be encrypted on tape drive

• Most secure solution

• No performance penalty

• Easy to implement

• Customer or regulatory body notification not required

as information not accessible to unauthorized parties

Implementation

Deployment

as information not accessible to unauthorized parties

• Provides protection from both offsite and on-premise

information loss

• Enables secure shipment of data

• Allows secure reuse of tapes

• Vendors: Thales, HP, CA, Brocade, NetApp

Management

Audit

Deployment

32

Database encryption

• DBMS-based encryption vulnerable when encryption

key used to encrypt data stored in DB table inside the

DB, protected by native DBMS access controls

• Users who have access rights to encrypted data often

have access rights to encryption key

– Creates security vulnerability because encrypted text not

Implementation

Deployment

– Creates security vulnerability because encrypted text not

separated from means to decrypt it

• Also doesn’t provide adequate tracking or monitoring

of suspicious activities

Management

Audit

Deployment

33

Database encryption

Inside DBMS

• Least impact on app

• Security vulnerability-

encryption key stored in

database table

Outside DBMS

• Remove computational

overhead from DBMS and

application servers

• Separate encrypted data from database table

• Performance degradation

• To separate keys, additional

hardware required, e.g., HSM

• Separate encrypted data from

encrypted key

• Communication overhead

• Must administer more servers

34

Key Management (KM)

• Generation, distribution, storage, recovery and destruction of

encryption keys

• Encryption is 90% management & policy, 10% technology

• Most encryption failures due to ineffective KM processes

• 80% of 22 SAP testing procedures related to encryption are

about KMabout KM

• Effective KM policy and design requires significant time and

effort

35

• With symmetric cryptography, as number of users increases, number of keys required increases rapidly

• For group of n users, there needs to be 1/2 (n2 - n) keys for total communications

• As number of parties (n) increases, number of symmetric keys becomes unreasonably large for practical use

The n2 Problem

U s e r s 1 / 2 ( n 2 - n ) S h a r e d k e y p a ir sr e q u ir e d

2 ½ ( 4 - 2 ) 1

3 ½ ( 9 – 3 ) 3

1 0 ½ ( 1 0 0 – 1 0 ) 4 5

1 0 0 ½ ( 1 0 ,0 0 0 – 1 0 0 ) 4 ,9 5 0

1 0 0 0 ½ ( 1 ,0 0 0 ,0 0 0 –

1 ,0 0 0 )

4 9 9 ,5 0 0

36

Key management questions

• How many keys do you need?

• Where are keys stored?

• Who has access to keys?

• How will you manage keys?

• How will you protect access to encryption keys?• How will you protect access to encryption keys?

• How often should keys change?

• What if key is lost or damaged?

• How much key management training will we need?

• How about disaster recovery?

37

• Requirement 3.6

– Generation of strong keys

– Secure key distribution

– Periodic key changes

– Destruction of old keys

– Dual control of keys

PCI DSS key management requirements

– Dual control of keys

– Replacement of compromised keys

– Key revocation

Ensuring all these requirements are met for multiple

applications can be overwhelming.

38

Key Management

• Keys must be accessible for the data to be accessible

– If too accessible, higher risk of compromise

• Reliability

– Outage in the system will prevent business from functioning

• Centralized key management

– Can help simplify key management for multiple applications

39

Key generation and destruction

• Generation

– FIPS 140-2 validated cryptographic module

– Distribution

• Manual

• Electronic

� Destruction

� Getting rid of keys is just as detailed as creating them

� Processes must deal with keys stored on:

– Hard drives

– USB• Electronic

– Backup/restore

– Split knowledge

– Destruction

– USB

– EPROM

– Third parties

� Facilities must exist to destroy hard-copies of key, both on paper and in hardware

40

• Focused on standardizing management of symmetric

encryption cryptographic keys across the enterprise within a

symmetric KM system

• Working on creation of:

– Symmetric Key Services Markup Language (SKSML) protocol

– Implementation and operations guidelines for an SKMS

OASIS Enterprise Key Management Infrastructure (EKMI)

– Implementation and operations guidelines for an SKMS

– Audit guidelines for auditing an SKMS

– Interoperability test-suite for SKSML implementations

– www.oasis-open.org/committees/ekmi/

41

For more information

• Guideline for Implementing Cryptography in the Federal

Government– http://csrc.nist.gov/publications/nistpubs/800-21-1/sp800-21-1_Dec2005.pdf

• Cryptographic Toolkit– http://csrc.nist.gov/groups/ST/toolkit/index.html

• Recommendation for Key Management– http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf

– http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part2.pdf

• Encryption Strategies: The Key to Controlling Data– www.sun.com/encryption/wp/encryption_strategies_wp.pdf

42

Books

43

Conclusions

• Organizations that do not have an effective dataclassification program usually fail at their data encryptionprojects

• Creating an effective deployment strategy is thedifference between strong encryption and an audit failuredifference between strong encryption and an audit failure

• Encryption is about attention to detail, good design andproject management

44

The Computer Forensics Show Conference

Forensic Trade Shows, LLC, 94 Field Point Circle, Greenwich, CT 06830 | Tel.: (203) 661-4312 | Fax: (203) 869-0283 [email protected]

New York Metro InfraGard, 249-12 Jericho Turnpike, Suite 252, Floral Park, NY 11001 | Tel.: (516) 216-1869 | Fax: (516) 216-1870 | [email protected]

• Ben Rothke, CISSP PCI QSA

Senior Security Consultant

The

Computer

Forensics

BT Global Services

[email protected]

• www.linkedin.com/in/benrothke

• www.twitter.com/benrothke