Ben Rothke presented on effective encryption deployment strategies. He began by discussing common mistakes made in encryption rollouts and emphasized that encryption is a process, not just a product. He then outlined a 3 step strategy: 1) define requirements, 2) know where sensitive data resides, and 3) create detailed implementation plans. Finally, he discussed various technical considerations for encryption deployment including full disk encryption, key management, and database encryption.

1. The Computer Forensics Show
Conference
April 19-20, 2010
New York, NY
Deployment Strategies for Effective
Encryption
Ben Rothke, CISSP, CISM, PCI QSA
Senior Security Consultant
BT Global Services
April 19, 2010
The
Computer
Forensics

2. 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
• Author - Computer Security: 20 Things Every Employee Should Know
(McGraw-Hill)
2

3. 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

4. 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
ubiquitous
• Adds up to a significant need for encryption deployment
strategies
4

5. 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
information security is a process, not a product.
5

6. 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
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

7. Encryption nirvana scenario
Deployment
Deployment
Define Drivers Data Mapping Implementation
Initial Drivers
Strategy
Strategy
Policy
Policy
• Business Data
Effective
Risk Modeling Management
• Technical Classification Encryption
• Regulatory
Policy Definition Control Gaps Audit
7

8. 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
formal encryption strategy
• Costs / Performance
– Up-front and on-going maintenance costs
– Performance hit
– Added technical staff
8

9. Encryption – a double-edged sword
Effective Encryption Strategy
No one, not No one,
even NSA, CIA, including
KGB, or evil yourself,
hacker, can can read
read your data your data
9

10. 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
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

11. 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

12. 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
be equipped to handle
• Encryption is exactly like a TAA
• Your staff must be trained and prepared.
12

13. 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 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

14. What should the strategy include?
• Laptop encryption Application encryption
• Database encryption Storage encryption
• Network encryption
PDAs
• Smart cards
USB
• Mobile encryption
Floppies/CD-ROM/DVD
• Wireless encryption
Emerging technologies
• Smart phones
• iPad/iPod/iPhone
14

15. 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
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

16. Current state
• Evaluate current encryption strategy and policy
– In sync with industry security best practices?
• Encryption framework in place?
Define Drivers • Policies in place?
Policy
Policy
Data
Classification
• Define what regulations must be complied with
• Document current encryption hardware /
Policy Definition
software environment
16

17. 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

18. Where are your encryption keys from?
• VPN connections
• SSL/TLS
• PKI/IdM
• User-generated keys
• File system encryption
• Third parties
• Trusted Platform Module (TPM)
– Built into news desktops and laptops
18

19. Drivers
• Business
– Customer trust
– Intellectual property
Define Drivers
• Technical
Policy
Policy
Data
– AES, PGP, BitLocker, etc.
Classification
– Increase in mobile devices
Policy Definition
• Regulatory
– PCI / SoX / EU Privacy directive / ISO-17799
– State data breach laws
• Note: Keep a wider picture in mind when complying
with specific mandates
19

20. Documentation and policies
• Encryption must be supported by policies,
documentation and a formal system and risk
management program
– Shows work adequately planned and supervised
Define Drivers
– Demonstrates internal controls studied and evaluated
Policy
Policy
Data
Classification • Policy must be:
Policy Definition – 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
20

21. Encryption processes
• Encryption is a process intensive
• Must be well-defined and documented
• If not implemented and configured properly,
Define Drivers
can cause system performance degradation or
Policy
Policy
Data
Classification operational hurdles
Policy Definition
• Improperly configured encryption processes
give false sense of security
– Perception that confidentiality of sensitive information is
protected when it’s not
21

22. Data classification
• Provides users with information to guide security-
related information handling
• Process must align with business processes
Define Drivers • Classification is dynamic
Policy
Data – Changes as data objects move from one class to another
Classification
– Changes as business strategies, structures and external
Policy Definition
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.
22

23. Data classification drivers
Compliance, discovery, archiving, never delete retention policy,
performance, availability, recovery attributes, etc.
Define Drivers Four Category Five Category
• Secret
Policy
Data Top Secret
Classification
• Confidential Highly Confidential
Policy Definition • Private Proprietary
• Unclassified Internal Use Only
Public
23

24. Encryption strategy
• Identify all methods of data input/output
• Storage media
• Business partners and other third parties
Data Mapping
• Applicable regulations and laws
Strategy
Risk Modeling
• High-risk areas
Control Gaps
– Laptops
– Wireless
– Data backups
– Others
24

25. 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
– 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

26. Data-flow definition
26

27. Requirements analysis
• Define business, technical, and operational
requirements and objectives for encryption
• Define policies, architecture, and scope of encryption
Data Mapping
requirements
Strategy
Strategy
• Conduct interviews, review policy documents, analyze
Risk Modeling
current and proposed encryption strategy to identify
Control Gaps possible security gaps
• Determine liabilities
• Better requirements definition directly correlates to
successful encryption program
27

28. 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
• Hardest platform – AS/400
28

29. Full-disk / host-based encryption (at rest)
• 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
Deployment
Deployment
Implementation
• Can significantly increase processing overhead
Management
• Requires additional processing power/expense
Audit
• 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
29

30. Appliance-based encryption
• Data leaves host unencrypted, then goes to dedicated
appliance for encryption
• After encryption, data enters network or storage
device
• Quickest to implement
Deployment
Deployment
Implementation
Management • Can be easy to bypass
Audit
• 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
30

31. 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
Deployment
Deployment
Implementation
• Easy to implement and cost-effective
Management
• Best suited to static and archived data or encrypting
Audit
large quantities of data for transport
• Large numbers of devices can be managed from single
key management platform
• Vendors: EMC, IBM, Hitachi
31

32. Tape-based encryption
• Data can be encrypted on tape drive
• Most secure solution
• No performance penalty
• Easy to implement
Deployment
Deployment
Implementation
• Customer or regulatory body notification not required
Management as information not accessible to unauthorized parties
Audit • 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
32

33. 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
Deployment
Deployment
Implementation
Management – Creates security vulnerability because encrypted text not
separated from means to decrypt it
Audit
• Also doesn’t provide adequate tracking or monitoring
of suspicious activities
33

34. Database encryption
Inside DBMS Outside DBMS
• Least impact on app • Remove computational
• Security vulnerability- overhead from DBMS and
encryption key stored in application servers
database table • Separate encrypted data from
• Performance degradation encrypted key
• To separate keys, additional • Communication overhead
hardware required, e.g., HSM • Must administer more servers
34

35. 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 KM
• Effective KM policy and design requires significant time and
effort
35

36. The n2 Problem
• 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
U s e rs 1 /2 (n 2 - n ) S h a r e d k e y p a ir s
r e q u ir e d
2 ½ (4 - 2 ) 1
3 ½ (9 – 3 ) 3
10 ½ (1 0 0 – 1 0 ) 45
100 ½ (1 0 ,0 0 0 – 1 0 0 ) 4 ,9 5 0
1000 ½ ( 1 ,0 0 0 ,0 0 0 – 4 9 9 ,5 0 0
1 ,0 0 0 )
36

37. 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 often should keys change?
• What if key is lost or damaged?
• How much key management training will we need?
• How about disaster recovery?
37

38. PCI DSS key management requirements
• Requirement 3.6
– Generation of strong keys
– Secure key distribution
– Periodic key changes
– Destruction of old keys
– Dual control of keys
– Replacement of compromised keys
– Key revocation
Ensuring all these requirements are met for multiple
applications can be overwhelming.
38

39. 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

40. Key generation and destruction
• Generation Destruction
– FIPS 140-2 validated Getting rid of keys is just as detailed as
cryptographic module creating them
– Distribution
Processes must deal with keys stored on:
• Manual – Hard drives
• Electronic – USB
– EPROM
– Backup/restore
– Third parties
– Split knowledge
Facilities must exist to destroy hard-
– Destruction
copies of key, both on paper and in
hardware
40

41. OASIS Enterprise Key Management Infrastructure (EKMI)
• 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
– Audit guidelines for auditing an SKMS
– Interoperability test-suite for SKSML implementations
– www.oasis-open.org/committees/ekmi/
41

42. 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

43. Books
43

44. Conclusions
• Organizations that do not have an effective data
classification program usually fail at their data encryption
projects
• Creating an effective deployment strategy is the
difference between strong encryption and an audit failure
• Encryption is about attention to detail, good design and
project management
44

45. The Computer Forensics Show Conference
Forensic Trade Shows, LLC, 94 Field Point Circle, Greenwich, CT 06830 | Tel.: (203) 661-4312 | Fax: (203) 869-0283
info@computerforensicshow.com
New York Metro InfraGard, 249-12 Jericho Turnpike, Suite 252, Floral Park, NY 11001 | Tel.: (516) 216-1869 | Fax:
(516) 216-1870 | info@www.nym-infragard.us
• Ben Rothke, CISSP PCI QSA
Senior Security Consultant
BT Global Services
ben.rothke@bt.com
• www.linkedin.com/in/benrothke
• www.twitter.com/benrothke
The
Computer
Forensics