Employing Encryption to Combat Data Theft

1. Employing Encryption to Combat Data Theft Karim Toubba Vice President – Product Management

2. The Challenge • Three high profile breaches within two week period alone • Database compromise • Malicious authorized users • Application attacks • Laptop thefts

3. Data-at-Rest Encryption Mandate Evolving nature of threats: focus now on data theft Network > System > Application attacks Numerous devastating thefts keep occurring Privacy Legislation/Security Policies PCI, VISA CISP, SB 1386, FISMA, EU Data Protection, NCUA 748, Sarbanes-Oxley, etc. MasterCard SDP: “Applications and databases must store all sensitive cardholder details in an encrypted form.” Data-at-Rest Encryption Encrypting confidential data at rest is now a mandate for security and compliance.

4. Data-at-Rest Encryption Steps Classify your sensitive data Define a security policy around the classified data Leverage existing technology standards Know the building blocks of data encryption

5. Know Your Threat Model • Threats to Sensitive Data within Database Systems • Authorized Malicious user – an authorized user with valid access to the database uses his permissions to extract large amounts of data • Malicious DBA – Malicious DBA extracts large amounts of sensitive data from a database or grants rights to other users to do the same • Database compromise – an internal or external user, through some OS security hole or misconfiguration of the database, gains access to the entire database • Application level Attack – an internal or external user compromises a web or application server and steals data by issuing ad hoc SQL queries through the application. • Physical Theft – Attacker steals physical medium that stores database (either physical disk or backup tape)

6. Encrypting Data at Rest • The options • Storage encryption • Web/Application encryption • Application encryption • Database encryption • The issues • Know your threat models • Application transparency • Performance • Security – protecting against the right threat model • Business logic embedded within database environments (stored procedures) • Batch processing & bulk import/export operations • Indexing and primary/foreign key pairs • Searching on encrypted data

7. Storage Encryption • Solutions in market today encrypt at the file system • Support for both NAS and SAN models • Solutions will also support interfacing with well known backup systems • Deployments are typically done in one of two modes • In-line to storage systems • Out of band and called through an agent on the host

8. Storage Encryption • Pros • Easy to setup • Transparent to application • No concerns over app/database schemas, objects, searches • Performance can be very fast • Cons • No granular control over what to encrypt – all or nothing proposition • No way to tie real access controls to data – only access to file system • Does not protect against many of the aforementioned threats • Protects purely against theft of physical medium. • Considerations – when to use file level encryption • When all data in the database needs to be encrypted • Word, excel, other file formats need to be encrypted on central file server • Large images, blue prints etc.

9. Web/Application “Field Level” Encryption • Granular field encrypted at application within SQL syntax or at Web layer (‘cc num’, ‘ID’) • Ideal for credit cards, email addresses, zip codes etc. • Encryption embedded within Web server logic • Apache - CGI (C/C++) call to PKCS#11 • IIS – ISAPI extension (VB) call to MS-CAPI • Encryption embedded within application logic • API explicitly called by application • Can be controlled at any point in application logic • Standard interfaces available today • Vendor specific crypto API’s also have additional intelligence built-in • Leverage use of crypto API’s or XML interface • JCE – Java • MS-CAPI – MSFT • PKCS#11 – C/C++ • XML – not real API but actually an interface • Implementation changes are minimal • Call provider • Pass parameters (‘data string’, ‘keyname’, encryption function’, ‘algorithm mode’) • Can work for equality queries depending on query structure

10. Application Encryption • Pros • Complete control over when and where to enforce encryption • Minimal performance impact at application logic – use of distributed application minimizes performance impact • Protects against a broad range of threats - VERY strong security model • Cons • Requires application code changes • Will not work with off the shelf applications that do not provide source code • Data access method problem – if you enable encryption in app A and insert into DB; you must also enable encryption in app B that is accessing same DB • Indexing/searching is an issue depending on existing query structures, amount of data within database and data to be encrypted. Can lead to potential performance degradation. • Considerations (Apply to web, app, and database encryption) • Database schema changes • Data Migration changes • Key rotation basics • When to use application level encryption – you have selective data you want to encrypt (credit cards, SSN, Student ID’s, address etc.)

11. Database “Column-Level” Encryption • Column-level encryption within database environments • Enables application transparency – no changes to applications required for simple queries • Implementation generally done through ‘instead of’ triggers, views, and stored procedures • Inserts/updates/deletes used ‘instead of’ triggers • Selects use views • Stored procedure calls underlying provider that enables cryptographic functions

12. Database Encryption • Pros • Can achieve complete application transparency depending on data encrypted • If deployed properly can tie directly into database authentication scheme to provide an additional layer of security • Database changes can be automated (field width and type, creation of views/triggers etc.) • Tools can be used to understand attributes of each column and therefore make recommendations for encryption • Can enable separation of duties and protect against malicious DBAs if implemented properly • Cons • Indexing/searching becomes problematic due to view-based implementations • Equality queries are not supported unless deploying in conjunction with application encryption (current solutions underway for specific DBMS environments) • Schema changes may have to occur for proper and practical implementation

13. Key Management – A Must for All Encryption Solutions • Strong key management is at the root of encrypting data at rest • Deploy symmetric encryption with strong keys and standards-based protocols • 128 bit 3DES • 256 bit AES • Stay away from asymmetric algorithms (RSA) – order of magnitude slower (there are some cases where this is appropriate) • Centralize all symmetric cryptographic keys and restrict access to keys through strong authentication policies • Create strong model for separation of duties • Key administrator – security administrator; creates keys/policies for access • Encryption user – database user, DBA, application user • Plan a supportable key rotation process – automate where possible; strongly consider solutions that allow key rotation without downtime • Plan robust key backup and recovery

14. Proper Access Controls • When implementing encryption of sensitive data it is imperative that you build an authentication/ authorization structure • Enable encryption process to validate user prior to allowing decryption to occur • Creates a security boundary within application or database framework which enables restricting access to keys to unauthorized users. • Leverage existing authentication/authorization solutions (LDAP) • Use strong multi-factor authentication to grant key access • Use authorization policies to enforce which functions encryption users can perform • Evaluate advanced authorization policies to protect against malicious authorized users

15. OLTP vs. Bulk load/batch processing environments • OLTP characteristics • Performance perception issue • Practically speaking, you can implement web, application or database encryption with minimal and acceptable performance degradation • Must implement granular encryption – specify only needed fields/columns • 100’s of operations/sec. is very acceptable • Distributed application environment is very suitable unless there are ‘select * from table’ type of queries. • Bulk load/batch processing environments • Increase amount of business logic embedded within DB environments • Bulk load/batch processing will NOT work with traditional application or database implementations (they both work on a field or record basis) • Performance requirements: 10,000’s ops/sec sometimes even 100,000’s ops/sec. • Generally requires specialized HW to perform that number of operations • Must be able to leverage a bulk load capability that can implement crypto or large numbers of records (batch) at once

16. Qualifying Questions for Encryption • What is the threat model you are protecting against? • Physical media theft (tapes, drives) • Logical threats (application, database, systems being compromised) • What is the data you want to encrypt? • What threat model are you protecting against? • Where are you going to perform encryption? • Are you indexing on the data you want to encrypt? • Are you using the data as a primary or foreign key? • What is the access mode for the data? • How many applications access the data? • What types of queries do you perform on the data? • Are you using stored procedures and building logic into the database? • Are you importing/exporting data from columns/fields you are encrypting? • Are you running batched processes that operate on encrypted data?