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 organizations
  systems are protected from internal attacks
  

Source Financial firms prey for hackers CNET
News.com http//news.com.com/2100-1009_3-101848
2.html?tagfd_top
4
Perimeter Security Alone?

• Todays 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)
BJs WHOLESALE CLUB DATABASE COMPROMISED
(March 2004)
EVENTS
CD UNIVERSE DATABASE BREACHED
(1997 December 2000)
VICTORIAS SECRET DATABASE SECURITY HOLE VIA WEB
SITE
(August November 2002)
BARNES NOBLE WEB APP VULNERABILITY (1998 Au
gust 2002)
7
Visa CISP 12 Security Requirements

• Source Visa - http//usa.visa.com/business/mercha
  nts/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 VVERSION
• Discover listener version via lsnrctl
• Find security alerts on Metalink or via email

http//www.oracle.com/technology/deploy/security/s
ecurityemail.html http//www.oracle.com/technolo
gy/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
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_transacti
ons
('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
  users 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.

51
CISP Requirement 7.3.4

• Develop password policies procedures in
  collaboration with security group
  
• Distribute password procedures and policies to
  all users who have access to cardholder
  information.
  
• Align database profiles password verification
  policies

52
CISP Requirement 7.3.4 7.3.12

• 7.3.5 - Do not permit group passwords.
• 7.3.6 - Change user passwords at least every 90
  days.
  
• 7.3.7 - Require a minimum password length of at
  least 7 characters
  
• 7.3.8 - Use passwords containing both numeric and
  alphabetic characters.
  
• 7.3.9 - Do not allow an individual to submit a
  new password that is the same any of the last
  four passwords he or she has used.
  
• 7.3.10 - Monitor system access attempts. Limit
  repeated attempts by locking out the user ID
  after a specific number of tries. (The maximum
  number for system access attempts must not exceed
  six.)
• 7.3.11 - Set the lockout duration to thirty
  minutes or until administrator enables the user
  ID.
  
• 7.3.12 - If a session has been idle for more than
  15 minutes, require the user to re-enter the
  password to re-activate the terminal.

53
CISP Password Requirements

• Passwords must be complex, expired locked
• Complex 7 characters with both (numeric
  alphabetic characters)
  
• Expired in 45 days not reused within 4 changes
• Locked after 6 failed attempts

54
CISP User Profiles

• Staff user account profiles configured for
  compliance
  
• Limit sessions per user to prevent group logins
• Expire passwords every 45 days
• Disconnect inactive connections
• Limit password reuse

55
CISP Application Impact

• Modify application connection code to handle
  exceptions thrown by database profiles
  
• Provide an application mechanism for users to
  change passwords
  
• Coordinate password changes with batch file
  scripting
  
• Educate application developers on password changes

56
CISP Requirement 8

• Do Not Use Vendor-Supplied Defaults for System
  Passwords and Other Security Parameters.
  
• Hardening the database according to Center for
  Internet Security Benchmark for Oracle

57
CISP Requirement 8 Details

• 8.1 - Always change the vendor-supplied defaults
  before you install a system on the network
  
• 8.2 - Develop system configuration standards for
  all networks components. Make sure these
  standards address all known security
  vulnerabilities and industry best practices.
• 8.2.1 - Implement only one application of primary
  function per server.
  
• 8.2.4 - Configure system security parameters to
  prevent misuse.
  
• 8.2.5 - Remove all unnecessary functionality,
  e.g., drivers, features, subsystems, file
  systems, etc.
  
• 8.2.6 - Enable the audit subsystem in support of
  Requirement 9.
  
• 8.3 - Establish a process to identify newly
  discovered security vulnerabilities. Update your
  standards to address new vulnerability issues.

58
CIS Level 1 Benchmark

• The CIS Level 1 Oracle security benchmark
• Consists of over 150 individual items.
• Security tests are grouped into categories
• host file
• database access
• policy / procedure security
• Benchmark scoring tools available
• CIS Scoring tool Limited operating system
  compatibility
  
• Customized SQL scoring tool (cis_level_1.sql)
• Customized UNIX scoring tool (cis_level_1.sh)
• AppDetective from Application Security
• The benchmark paper can be found at Center for
  Internet Security website (www.cissecurity.org).

59
CIS Level 1 Hardening

• The CIS Level 1 Hardening on databases include
• Hardening the listener and networking
• Adjusting operating system privileges for Oracle
  files
  
• Removing PUBLIC privileges
• Configure parameters for security best practices
• Configuring user permissions for least access
• Limit access to database dictionary parameters
• Revoke powerful privileges from users
• Lock down default Oracle accounts
• Monitor Oracle security settings and resources
• Configure auditing

60
CISP Requirement 9

• Track All User Access to Data by Unique ID
• Audit a variety of database activity including
• Access to credit card numbers
• Database changes and modifications during
  production hours
  
• Deletion of objects
• Accesses to audit trails

61
CISP Requirement 9 - Details
62
CISP Requirement 9 - Solutions

• Auditing serves these primary purposes
• Monitoring changes made to specific portions of
  the database
  
• Detecting when an attacker is elevating
  privileges
  
• Providing forensic evidence in the event of a
  security breech
  
• Clear Card access audited to the Operating system
  with Data Access Layer functions
  
• SYSDBA access audited to the operating system via
  database parameter setting
  
• Database activity audited via Oracle database
  standard auditing to the SYS.AUD table

63
CISP Requirement 9 Audit Trail

• Protecting the audit trail
• Audit trail in operating system files and
  database tables are copied to an OIS logging
  server
  
• Alert log files and listener log files are copied
  to the logging server
  
• Access to the database audit trail are written to
  the database audit trail
  
• Changes to the database auditing are written to
  the database audit trail
  
• Deletion of objects and initialization of audit
  trails are written to the audit trail
  
• Audit trails are monitored for suspicious activity

64
Configure Auditing

• Audit drop object activity on the database
• Users connected as SYSDBA SYSOPER are not
  audited with the audit command
  
• Set audit_sys_operationsTRUE to audit SYSDBA
  SYSOPER to an operating system file

65
Consider Fine Grained Auditing

• Write access information on Card tables to
  dba_fga_audit_trail with DBMS_FGA
  
• Use a function for the audit condition
• Function determines if clear text card is being
  displayed
  
• Only access to table providing clear access are
  audited

66
Passing the CISP Audit

• Auditors are looking for documentation
• Communicate with auditors prior to audit
• Concentrate on testing procedures listed in the
  CISP standard

67
CISP Compliance Oracle DB

• Oracle Database Compliance
• Cardholder Information Security Program