Encryption For Data At Rest

1
Encryption For Data At Rest
2
Why is data-at-rest encryption needed?
3
Additional reasonsif 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
  SOMs network

4
Enterprise Encryption Workgroup (EEW)

• 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

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, PDAs, cameras, I-pods, 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 CDs, DVDs 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
Gartners 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 Gartners 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
Laptops, Desktops Y/N
PDA's (Ipod, Blackberry, Windows, Palm) 5
Portable devices (USB Ports, CD, DVD, Firewire, etc.) 5
Gartner rating of Vendor 10
Prior Experience (Vendor customer's, E.g., DOD, etc.) 15
Financial Stability (Check information such as 10-Q and 10-K at SEC.GOV) 5
Enterprise Management Capability (Directory imports, manual entry, centralized console, key management, key recovery) 25
User Experience 15
Hot line interface (Customer Service Center) 10
Maintenance support including installation 10
   
Total Score 100
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

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 RequirementsFull 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 RequirementsFull 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 RequirementsPre-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 RequirementsFIPS 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 RequirementsKey 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 RequirementsAuditability

• 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 RequirementsPort 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
  dont exist in an LDAP)