You Have to Encrypt Your Data. Now What

1. You Have to Encrypt Your Data.Now What? Cincinnati Chapter ISACA November 13, 2007

2. Agenda A few quick questions� Review the objectives of this discussion Discussion of several available approaches Storage Encryption Host provided db Encryption DB Optimizer provided Encryption Application Managed Encryption Wrap-up, Questions, and Answers

3. Quick Questions What is your role in your organization? Audit or Risk Management Technologist (SME, Analyst, Consultant, Engineer, Architect, etc.) Information Security Manager or Team Leader Corporate Executive (CISO/CIO/VP/etc.) Line-of-Business Stakeholder Do you have data that you need to protect with Encryption today? Yes No Maybe (anticipated in next year)

4. What is the Problem ? Is your organization faced with emerging data encryption needs? Are people trying to sell you 'silver bullet' solutions? How can you ensure that you are getting the data protection you expect? Our objectives today: Identify a set of application data encryption options Review strengths and weaknesses of each Develop a �framework� for selecting appropriate solutions

5. Model Application Architecture

6. Evaluation Criteria For each of the components of the architecture, the following will be discussed: Approach Drivers Strengths Weaknesses

7. Risk Control Questions There are a few issues that are a concern when evaluating the appropriateness and effectiveness of a control: At what point in the architecture is the control applied? Who has access to cleartext data? How does cleartext data propagate (backup, etc.) ? How are keys stored? Is key management (lifecycle, controls, etc.) documented? Are the components FIPS 140-2 validated?

8. Regarding Backups Evaluating backup and data recover strategy�s impacts on any data protection control is very complex, and beyond our scope. That said, issues to address are: Is the data clear or ciphertext on the backup? If is cleartext, what heightened physical controls are used? If ciphertext, how are keys recovered during DR ?

9. Strategy: Storage Approach Use an in-line Encryption device between the DB server and SAN/NAS storage. Drivers Minimally invasive. Application, database, and host changes are avoided. High performance. Generally there is a small and fixed increase in the latency of all storage I/O requests.

10. Strategy: Storage Strengths Potentially rapid deployment Good cost prediction Min / no impact on DB host, database and application Key management isolation This meets a paper �encryption� requirement Weaknesses All or nothing Access controls not enhanced Only mitigates disk loss High cost per device

11. Strategy: Database Host Approach Use filesystem level tools to encrypt database data files Drivers Grants ability to encrypt on a file by file (or directory) basis Limit administrative access to protected files

12. Strategy: Database Host Strengths Doesn�t require application or database changes OS administrators will have full access to host but will be limited in ability to manipulate or view encrypted files Weaknesses Key storage may require compensating controls Key bootstrap Administrator access to keys Some �out of the box� services may not accommodate smooth key rotations Performance impacts must be managed Access controls via SQL front end is not enhanced

13. Strategy: DatabaseRDMS manages keys Approach Use �transparent� encryption facilities provided by database vendor Keys are managed internally by the database Drivers Allows encryption of database without requiring schema or SQL changes.

14. Strategy: DatabaseRDMS manages keys Strengths Deployment doesn�t require application changes Greater protection of encrypted data against host and storage administrators Weaknesses Key storage may require compensating controls (bootstrap, etc.) Close attention must be paid to index and join strategy ( often effectiveness of indexes is impacted if range searches are used ) Logs, transaction journals and indexes likely have clear text data Database storage is impact if� Compression of data is being used Small data items ( PINS, PANS, passwords ) are being encrypted

15. Strategy: DatabaseApplication manages keys Approach Use native SQL encryption methods provided by database vendor Keys / passwords are included within SQL queries Drivers Historically was first database option available

16. Strategy: DatabaseApplication manages keys Strengths DBA, OS, and storage administrators will have no clear access to data Weaknesses Key storage strategy must be managed within the application Potential �Pervasive� password problem Performance impacts must be managed Database storage impact SQL queries will have to be modified Potential to impact database optimization

17. Strategy: Application Approach Encrypt private data within the application Drivers Allows for the most granular control Data is in the clear for the least amount of time End to End protection is achievable

18. Strategy: Application Strengths End to End protection is achievable Highest level of protection of encrypted data against administrative access Weaknesses If �End to End� is a protection goal, key management complexity rises Software design must take key storage and rotation into account Close attention must be paid to developer access to production keys Software development costs may be high / long development time Performance impacts must be managed Close attention must be paid to libraries and techniques selected by development staff

19. Summary Due to the wide variety of options & relative immaturity of the space (compared to other controls), it important to: Understand what Risks are �program drivers� Evaluate secondary benefits of completed approaches Understand operational and support impacts Understand DR and BCP impacts Closely examine backup strategies Always evaluate key storage and management !

20. Framework

21. Wrap-up, Q & A, Etc� Questions ?