CISP Compliant Oracle DB

1. CISP Compliant Oracle DB Oracle Database Compliant Cardholder Information Security Program

2. Cardholder Information Security Program • VISA international crafted a program to secure credit cardholder information • Purpose is to protect exposure credit card information leading to • Potential credit card fraud • Financial systems efforts to reinstate card usage • Embarrassment to merchants and processors

3. Increasing Security Breaches Increasing amounts of security breaches Global Security Survey by Deloitte and Touche LLP found: • 39% of Financial Institutions experienced security breach within last year • Of that 39%, two-thirds of the security breaches came from outside the organization • Only 5% of the respondents replied “extremely confident” about how well their organization’s systems are protected from internal attacks Source: Financial firms prey for hackers | CNET News.com | http://news.com.com/2100-1009_3-1018482.html?tag=fd_top

4. Perimeter Security Alone? • Today’s network and operating system security tactics can not defend against changing threats to the application: • Known Vulnerabilities • Database Mis-configuration • Integrity and Access Issues • ID/Password Control Issues • Incorrect Usage • Internal threats occur inside the perimeter from: • Employees • Contractors • Partners • Trusted Customers

5. Credit Card Data – In the database • “The increasing sophistication of business applications requires a similarly sophisticated application-centric approach to security.”– David Thompson, META Group • “The most common mistake is to assume that something "behind the firewall" will not be attacked, or alternatively, that insiders are all upstanding citizens.” – Mary Ann Davidson, Chief Security Officer, Oracle • “Gartner estimates that 70 percent of security incidents that actually cause loss to enterprises – rather than mere annoyance – involve insiders, … Enterprises must broaden their approach to securing Internet-exposed applications and servers.” – John Pescatore, Gartner • “The proliferation of Internet protocols has intensified awareness of perimeter security and left Internet-facing applications vulnerable to attacks. .” – Eric Ogren, Yankee Group

6. Databases Are Under Attack BREACH RESULTS IN FINES ($60K) AND MANDATORY INTERNAL INFOSECURITY PROGRAM + EXTERNAL AUDITOR (April 2004) SECURITY HOLE RESULTS IN FINE ($50K) (October 2003) IMPACT ATTACKS FORCE FIRMS OUT OF BUSINESS INVESTIGATION AND REVIEW BY SECURITY FIRM + POSSIBLE FINES (March 2004) 1990s 2000 2001 2002 2003 2004 EGGHEAD DATABASE BREACHED (December 2000) BJ’s WHOLESALE CLUB DATABASE COMPROMISED (March 2004) EVENTS CD UNIVERSEDATABASE BREACHED (1997 – December 2000) VICTORIA’S SECRET DATABASE SECURITY HOLE VIA WEB SITE (August – November 2002) BARNES & NOBLE WEB APP VULNERABILITY (1998 – August 2002)

7. Visa CISP 12 Security Requirements • Source: Visa - http://usa.visa.com/business/merchants/cisp_index.html

8. CISP Requirement 2 • 2.1 Keep security patches up-to-date. • 2.1.1 Make sure all “systems and software” have the latest vendor-supplied security patches • 2.1.2 Install new/modified security patches within one month of release. • 2.2 Install new/modified security patches within one month of release. • 2.3 Follow change control procedures for system and software configuration.

9. CISP Requirement 2 • Oracle Database software contains functional defects that require software updates or modifications. • For database security, defects in the software that can be used to compromise the database must be addressed quickly after publication. • Commit to being alert to database security alerts and applying security patches quickly and effectively.

10. CISP Requirement 2.1.1 • Make sure all “systems and software” have the latest vendor-supplied security patches • Discover DB version from V$VERSION • Discover listener version via lsnrctl • Find security alerts on Metalink or via email http://www.oracle.com/technology/deploy/security/securityemail.html http://www.oracle.com/technology/deploy/security/alerts.htm

11. CISP Requirement 2.1.2 • Install new/modified security patches within one month of release. • Review security alert from Oracle • Investigate patch for application to current deployments • Open tickets for deployment and testing of patches MetaLink Note: 237007.1 ORACLE SUPPORT SERVICES Security Alert - Frequently Asked Questions

12. CISP Requirement 2.2 • Install new/modified security patches within one month of release. • Apply patch to development & test environments • After careful testing, apply to production

13. CISP Requirement 2.3 • Follow change control procedures for system and software configuration. • Patch application begins by opening an change control ticket • Ticket includes patch details and contingencies • Note that management signs off on patch application • Patch is applied and ticket is closed

14. CISP Requirement 3 • Protect stored data using • 3.1 - Limited cardholder storage • 3.2,3.3 – Proper disposal & retention • 3.4 – Segregate Card Verification value 2 • 3.5 – Segregate merchant data • 3.6,3.7 – Encrypt passwords & data • 3.8,3.9 – Use cryptography best practices • 3.10 – Document crypto key management

15. CISP Requirement 3.1 • Limited cardholder storage • Minimize the schemas & tables containing credit card data • Restrict storage of card numbers in outside databases (Excel, Access …) • Encrypt any data files used for card number transport

16. CISP Requirement 3.2 & 3.3 • Proper disposal & retention • Audit disposal & retention procedures quarterly • Verify card data retention in all locations – data warehouse, OS & DB backups • Oracle Partitioning by transaction date is useful to meet this requirement

17. CISP Requirement 3.4 • Segregate Card Verification value 2 • Store the Card Verification value in a separate table • Separate CVV2 data from card data during transport • Encrypt CVV2 data with different key than card number value

18. CISP Requirement 3.5 • Segregate merchant data • Segregate merchant data using application code • Use Oracle Virtual Private Database to segregate data in card tables • Fine Grain access control to restrict table or view rows for a merchant to an assigned account manager • Use merchant identifier as the predicate • SYS_CONTEXT('userenv', ‘current_user') • SYS_CONTEXT('userenv', ‘proxy_user')

19. Virtual Private Database Example • Add one or more policies to a table DBMS_RLS.ADD_POLICY ( OBJECT_SCHEMA => ‘KSMITH', OBJECT_NAME => ‘TRANSACTIONS', POLICY_NAME => 'CTX_TRANS', FUNCTION_SCHEMA => ‘KSMITH', POLICY_FUNCTION => ‘TRANS_POLICY'); • Policy function generates a predicate

20. CISP Requirement 3.6 • Encrypt passwords • Check applications for user passwords • Use LDAP directory for user identification • Connect database passwords to Active Directory • Protect hash password values • Manage Database Links carefully • Use private database links • Protect SYS Link$ dictionary view • Encrypt automated process passwords

21. CISP Requirement 3.7 3.7 Render unreadable stored cardholder data • Oracle package DBMS_CRYPTO Cryptographic algorithms are supported: • Data Encryption Standard (DES), Triple DES (3DES, 2-key) • Advanced Encryption Standard (AES) • MD5, MD4, and SHA-1 cryptographic hashes • MD5 and SHA-1 Message Authentication Code (MAC) • Oracle 9i use DBMS_OBFUSCATION_TOOLKIT

22. PL/SQL Encrypt Example raw_input RAW(128); raw_key RAW(128); encrypted_raw RAW(2048); -- convert input to raw encrypted_raw := dbms_crypto.Encrypt( src => raw_input, typ => DBMS_CRYPTO.DES_CBC_PKCS5, key => raw_key);

23. PL/SQL Decrypt Example raw_key RAW(128); encrypted_raw RAW(2048); decrypted_raw RAW(2048); decrypted_raw := dbms_crypto.Decrypt( src => encrypted_raw, typ => DBMS_CRYPTO.DES_CBC_PKCS5, key => raw_key);

24. CISP Requirement 3.8-3.9 • Use cryptography best practices • Document crypto key management • Automate key management, including key expiration and re-encryption • Split key values across people and systems in private locations • Consider hardware encryption instead of software • Generate random encryption keys or choose obscure keys • Encrypt keys prior to distribution • Separate encryption keys from encrypted data

25. Alternative Card Access Protection • Encryption of data may not be pragmatic • Multiple layers of defense • To access clear text card data, a user • Authenticates to the internal trusted network • Accesses database using username & password • Authenticates connection via an access control layer or application controls • Accesses masked card data via views • Accesses clear card data via package calls • Clear card access is audited to database or operating system file

26. Card Access Network Protection • Authentication to the databases on trusted internal database protection on • Required ports • Required protocols • Required IP addresses • Network access is monitored by intrusion detection systems • Once authenticated to trusted network, database access is possible

27. Card Access Server Protection • Database host servers are protected by • Host based IDS • File integrity system • System logging • Configuration to CIS security benchmark • Patch management • Hardened & complex passwords

28. Card Access Database Protection • Session connection to database requires: • Hardened & complex passwords • Authentication via application • Authentication to database based user connection context • Database hardened to CIS Oracle security benchmark (Level 1)

29. Card Access Permission Protection • Session capability to see card numbers includes • Database permission to execute functions for card data access • Application permission to view for card data • Security configuration for clear text card access • Knowledge of how to use functions for card data access

30. Data Access Layer - Components • A DAL consists of these components: • A function – accepts query parameters • A query - cursor within the function to fetch data • An object type – an object patterned after cardholder table rows • An collection type – an table type for passing a collection of objects as a result set from a function • An authentication schema – permissions for users for card access is held in a user schema

31. Data Access Layer - Components • A DAL consists of these components: • A masking function – based on user credentials, a mask pattern may be applied to a card number • An auditing function – queries made to card numbers where clear text card number are revealed must trigger an audit record • An audit location – a database table and/or file system where audit records are written & analyzed

32. DAL Construction • Before a DAL can be used for a table named TRANSACTIONS: • Create a table type object based on TRANSACTIONS • Create a package function that will service a specific query on table TRANSACTIONS • Configure a directory or table for an audit trail • Configure tables for user authentication credentials

33. DAL Functions • Functions required for data access layer: • Function to capture user context • Query function that returns a table type object • A lookup function that returns user card access level • A masking function that returns a masked card number • An audit function that creates audit records upon full card number presentation

34. DAL Query Process • Application runs a SQL statement calling the query function with parameters • The query function fetches user credentials from security managed tables • Each card number is masked or clear according to credentials • If the card numbers are presented in full, an audit record is written • A table collection is filled (or piped) with the result set & returned from the function

35. DBMS_SESSION.set_context DAL Query Process Flow Application SQLCommand INSERT INTO table or use UTL_FILE.PUT_LINE to file select * from table((transactions (p1, p2) as transaction_tab)) SELECT SYS_CONTEXT() SELECT * FROM TRANSACTIONS 1. Capture user context 2. Call query function 3. Fetch context & access 4. Mask card number 5. Write audit record 6. Return data

36. Example DAL call • Package = dal • Function = get_transactions • Collection type = transactions_tbl_type • Investigating simple syntax SELECT * FROM TABLE (ksmith.dal.get_transactions ('10-JUL-04','', '','','USERNAME');

37. Cardholder Masked Views • Views will be used access cardholder tables • Views will return the account number as a masked value • View name will be the same as the current table name

38. Cardholder Access Options • Access masked card data via a view. • The view will have the same name as the current cardholder table • Access card data using complete card data via a package function call

39. View for Masking Card Data CREATE OR REPLACE VIEW TRANSACTIONS_VIEW as SELECT sale_id, sale_date, sale_amount, mask_card(card_number) card_number FROM TRANSACTIONS;

40. Example Masked View Query SELECT item_tag, card_nbr FROM TRANSACTIONS;

41. Masked View vs. DAL Change • Use the DAL package function: • If the full card number is required by the application • If the card number is a condition in the SQL WHERE condition (predicate) • If card numbers are used for multi table joins • If card numbers are used in set operations (UNION, INTERSECT)

42. CISP Requirement 6 Restrict Access to Data by Business Need to Know • 6.1 - Develop a data control policy. Limit access to computing resources and cardholder information to only those individuals whose job requires such access. • 6.2 - Establish a mechanism for systems with multiple users that restricts access based on a user’s need to know

43. CISP Requirement 6.1 • Review all database users on cardholder production databases to assess each business function and database permissions. • Authorize each account was via company Data Access Control policy. • Document management authorization for each database and application user, permitting users access according to business function.

44. CISP Requirement 6.2 • Grant database users specific database permissions for their job function via roles and object grants • Remove PUBLIC permissions to most database objects, especially card holder data and functions • Configure security people authority to grant permissions to database and application users for clear text card access.

45. CISP Requirement 7 Assign a Unique ID to Each Person With Computer Access • Protecting cardholder data depends on the unique authentication of database user connections. • Database users can be Oracle default, data owners, staff or application database users. • Some database user accounts fill more than one role on a company database. • Each account must be carefully reviewed for unique identification

46. CISP Requirement 7.1 • Uniquely identify all users with access to cardholder information • Database connection access occurs with user/password combination & a context based customized access control system. • After authentication but before the connection is established, the context of the user connection is compared against access control entries for that user. • For example, if a database user named JSSMITH must be authenticated to the network as JSSMITH before the connection can be established.

47. CISP Requirement 7.1 • Uniquely identify all users (cont) • Application database user combine machine and OSUSER context for connections • Some staff users across databases have been migrated to user names that are identical to the network login id. • Active Directory & Oracle LDAP - Distributed Interface Platform (DIP)

48. CISP Requirement 7.3.1 • Control the addition, deletion, and modification of user IDs, credentials, or other identifier objects. • Authorize database user modifications based on policy • Complete and sign forms for user permission modifications • Track database user changes change management system tickets

49. CISP Requirement 7.3.2 • Immediately revoke accesses of terminated users. • Employee separation triggers human resources to notify the data management group • Remove these users from the database if the user has no schema objects and dependencies • Immediately lock user accounts if the user has schema objects. Investigated schema objects for the account and eventually removed user from database

50. CISP Requirement 7.3.3 • Remove inactive user accounts at least every 90 days. • Automate processes to capture the last connect time for each account. • Investigated and locked accounts without connections within 90 days. • Remove the account after investigation.