Encryption For Data At Rest

1. Encryption For Data At Rest

2. Why is data-at-rest encryption needed?

3. Additional reasons…if necessary • Changes in Michigan Public Act 452 regarding “Breach Notification” • Negative public relations and political distaste • SOM is responsible for the protection of citizens privacy and identity • To build citizen trust • There are a lot of ways data can “leak” from the SOM’s network

4. Sponsors Dan Lohrmann (CSO) Scot Ellsworth (CEA) Agency Services Bruce Colf Michael Goodness Paul Groll Donna Sivaraman Narayan Sivaraman Office Automation Wayne Foster Enterprise Architecture Chad Sesvold End-User Standards Reid Sisson OES Brent Ericks Chris Kellogg Enterprise Encryption Workgroup (EEW)

5. 2 Objectives of the EA workgroup50,000 foot view • Provide EA guidance to agencies with existing “Data at Rest” encryption needs • Through the Enterprise Architecture work group, develop and implement a state-wide “Data at Rest” encryption standard that addresses the business and technical needs • Analyze and recommend one standard “Data at Rest” encryption tool that meets the standard

6. What is Data at Rest? • It is: • Data that exists on a laptop hard drive • Data that exists on a P.C. hard drive • Data that exists on a locally attached server hard drive • Data that exists on a portable storage mechanism (I.e., USB stick, CD, DVD) • It is not: • Automatically the data being transmitted via e-mail • Data being transmitted over the network (internal or external) • Data written from server to the SAN or NAS

7. Project Scope(as defined by the technical requirements) Priority scope • Laptops using confidential State resources must have full disk encryption • Encryption of USB memory stick • Encryption of as many transportable systems and data devices as possible (thumb and flash drives, CDs, DVDs, tablets, PDA’s, cameras, I-pod’s, etc) • Locally attached server hard drives and control of server USB/DVD/CD • Centralized management capability Additional scope • Transparency to the end user – Minimal impact • Key recovery facility with Helpdesk interface • Port/Device control including CD’s, DVD’s and memory sticks • Present findings and recommendations to multiple groups of individuals

8. Approach • Identify: • Known requirements from agencies gathered • Existing standards, policies and regulations • Candidate products from Gartner Magic Quadrant and other industry resources • Encryption tools already in use throughout the enterprise • An assessment matrix from the requirements and other IT considerations • Accomplish: • Build an assessment matrix based on the requirements identified by the group • Schedule and hold vendor demonstrations that meet the matrix requirements • Clarify outstanding issues with vendors • Develop scoring mechanism (scorecard)

9. Work Group Deliverables • Establish Enterprise Data Encryption (data at rest) requirements. • Review industry vendor products for research, functional capability, and industry maturity. • Score the vendor presentations utilizing the TRC scoring method (weighted questions). • Recommend direction for the state. • Draft State-Wide standard to address critical encryption requirements. • Present recommendation to State of Michigan leadership (Agencies and MDIT). • Proceed with recommended acquisition programs.

10. Gartner’s Magic Quadrant

11. Requirements Identified by the EA Sub-Group Encryption Requirements • Full disk encryption (FDE) • Pre-boot authentication • FIPS 140-2 certified Operational Requirements • Key recoverability • Auditability • Port control Infrastructure Requirements • Ability to load users from Active Directory, E-Directory, and manually • Central key management (console)

12. Vendor Finalists • After establishing requirements and interacting with 13 vendors, 3 have been targeted as viable solutions • WinMagic • SafeBoot • PointSec • These finalists align with Gartner’s Magic Quadrant • Once the procurement method has been established the EA Sub-Group will identify one product as the State standard

13. Final Scoring Criteria

14. Multi-Government Encryption Procurement Initiative • Federal Government combined purchase initiative named the ESI/SmartBuy vehicle • Was competitively bid • Ten vendors granted approved for purchases under this vehicle • State and local government can participate and combine purchase with Federal government • All 3 vendors that Michigan MDIT EA Sub-Group group have targeted are included in this federal purchase initiative.

15. More on ESI/Smartbuy • USDA is utilizing the ESI/SmartBUY contract vehicle to purchase the SafeBoot product • Full Disk Encryption (FDE) • File/Folder Encryption (FES) • Port Control • All Connectors needed for directory and mobile devices • 1st Year 7x24 Maintenance & Support • Management Console • Database Backup • Scripting Tool • Web Help Desk • Home use of all licenses • Secondary use right for all licenses • Immediate temporary enterprise license for use during natural disasters, acts of war and/or terror • Rates are extremely reduced • $11.56 per license (normal cost for all three products is approximately $230.00) • Year two (2) Maintenance is $2.89 per license (normal maintenance is 18% of the normal cost) • Timeline • August 29th – October 29th, 2007 • PO for 1,000 Seat Minimum locks in price point until October 29th, 2008 • Letter of Intent Received on October 29th, 2007 provides an additional thirty (30) extension to receive PO to accommodate funding or legal requirements

16. Next Steps • Estimate Total-Cost-of Ownership (TCO) of solution. • Align purchase program of products and services via Federal ESI/SmartBuy vehicle. • Pilot project to begin Enterprise Data Encryption environment, deployment processes, and services.

17. Encryption of Data At Rest ? ? ? Questions? ? ? ? ?

18. Support Slides…. • Please reference the following slides as additional work group research and Data Encryption requirements.

19. “Encryption Requirements”Full Disk Encryption • Without “Full Disk” encryption users cannot be sure that their data is encrypted. • Normal file deletion leaves residual data on the hard drive • Applications and Browsers leave data in unpredictable areas on the hard drive • Users often do not realize they have sensitive data on their devices

20. “Encryption Requirements” File level encryption not recommended

21. “Encryption Requirements”Full Disk Encryption recommended Note that FDE encrypts the entire disk including the un-used space before the C partition and after it. (Encrypting only the drive C may leave attacker code in these spaces.)

22. “Encryption Requirements”Pre-Boot Authentication • User must be identified prior to accessing the operating system • Can be implemented in single sign on mode thereby requiring only 1 username and 1 password to login to windows (transparent to user) • Compatible with existing SecurID tokens, Smart Cards, Biometrics and many other multi-factor authentication devices

23. “Encryption Requirements”FIPS 140-2 Certified • The Federal Information Processing Standard (FIPS) Publication 140-2, is a U.S. government computer security standard used to accredit cryptographic modules • Industry best practice dictates that successful implementations of encryption products meet the FIPS 140-2 certification.

24. “Operational Requirements”Key Recoverability • User forgets login – product must have an interface for Client Service Center to restore access • Master login must not exist (backdoor) • OES must have access to keys for acceptable use policy investigations and others

25. “Operational Requirements”Auditability • Product must be able to validate that encryption has taken place for each device that is encrypted • Audit logs will be used to remediate the notification requirement changes within Public Act 452 • Port control audit logs can be used to enforce sensitive data control policies

26. “Operational Requirements”Port Control • Ability to restrict “Writing” to USB ports for agencies that request it • Selective device control (I.e., Dell USB but not U3 USB devices) • Automatic encryption of data when sent to the USB port if allowed

27. “Infrastructure Requirements” • Central console to manage encryption enterprise-wide • Centralized policy enforcement for users and groups of users • Web-based interface for password recovery situations for the CSC • Ability to interface with different LDAP directories (I.e., Novell E-Directory, Microsoft Active Directory and manual entry for users that don’t exist in an LDAP)