Teleran PCI Customer Case Study Written by Director of Credit Card Systems for Large Credit Card Issuer Customer Case Study Summary A large credit card issuer was engaged in a Payment Card Industry Data Security Standard (PCI DSS) compliance audit. The subject system is a 40+ TB consumer data warehouse built in Oracle on Solaris servers containing sensitive consumer information including primary account number, social security number and other card holder personal data. The system is accessed by approximately 1000 users employing a variety of tools including SAS, Business Objects, SQL+, Toad, and others. During the initial audit, the system failed six key sections of PCI Requirement 10: Tracking and monitoring all access to network resources and cardholder data. The issuers compensating control or alternative approach to meeting Requirement 10 would require creating a security system to restrict data change and access that would store an estimated 2TB of audit logs per year. They would also need to develop a reporting system to provide the necessary PCI reporting. The issuer had significant concerns about the development and system resource costs associated with capturing, storing and reporting on the required data. The credit card issuer was already using the Teleran System, isight and iguard, for database monitoring and management, query control and user management. The issuer asked the auditors whether these products would enable compliance with the failed audit requirements. After evaluation and testing, the auditors found that isight would meet their audit requirements. In addition they determined that iguard access control policies would meet PCI Requirement 3: Protecting stored cardholder data. Compliance with this additional requirement would significantly reduce the risk of data loss due to malicious attempts at unauthorized system penetration and data theft. With the approval of their auditors, the issuer used isight and iguard to meet the PCI Requirement 3 and 10 demands. The Teleran System required 1 week to implement, just 5% of the time it would have required to develop the system using off-shore resources. This saved the issuer more than $250,000 in development and management costs, as well as significant recurring expense in ongoing maintenance costs. In addition the Teleran System saved the issuer an additional $800,000 in their first year of use by reducing operational costs. These cost reductions included using isight to identify and delete or archive unused data; thereby lowering storage, processing and data handling costs. Savings also included lowering system resource costs and hardware expense through the use of iguard user management controls. iguard prevented wasteful database usage by application users, improving system efficiency and user performance and productivity. The issuer has since made the Teleran software suite the enterprise standard for systems that must comply with PCI requirements 3, and 10. The issuer is also planning to apply iguard policies to further enhance compliance with three additional PCI Requirements: Requirement 1: Install and maintain a firewall configuration to protect cardholder data. Requirement 7: Restrict physical access to cardholder data by business need-to-know. Requirement 12: Maintain a policy that addresses information security. Teleran PCI Customer Case Study September, 2008 1
Payment Card Industry Data Security Standard The Payment Card Industry Security Standards council was formed by American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International to enhance payment account security by driving broad adoption of the Payment Card Industry Data Security Standard (PCI DSS). The PCI Data Security Standard represents a common set of industry tools and measurements to help ensure the safe handling of sensitive information. Initially created by aligning Visa's Account Information Security (AIS)/Cardholder Information Security (CISP) programs with MasterCard's Site Data Protection (SDP) program, the standard provides an actionable framework for developing a robust account data security process - including preventing, detecting and reacting to security incidents. (Ref: https://www.pcisecuritystandards.org/about/faqs.htm#q15 Twelve PCI DSS Requirements Build and Maintain a Secure Network 1) Install and maintain a firewall configuration to protect cardholder data. 2) Do not use vendor-supplied defaults for system passwords and other security parameters. Protect Cardholder Data 3) Protect stored cardholder data. 4) Encrypt transmission of cardholder data across open, public networks. Maintain a Vulnerability Management Program 5) Use and regularly update anti-virus software. 6) Develop and maintain secure systems and applications. Implement Strong Access Control Measures 7) Restrict access to cardholder data by business need-to-know. 8) Assign a unique ID to each person with computer access. 9) Restrict physical access to cardholder data. Regularly Monitor and Test Networks 10) Track and monitor all access to network resources and cardholder data. 11) Regularly test security systems and processes. Maintain an Information Security Policy 12) Maintain a policy that addresses information security. Compliance with these requirements significantly reduces risk of data loss due to malicious attempts at unauthorized system penetration and data theft. PCI DSS Compliance If an organization fails PCI DSS requirements, a compensating control or alternative approach may be presented by the applicant to be assessed by the auditing organization. The compensating control may or may not be approved, and can be labor or resource intensive such PCI s Section 10: tracking and monitoring all access to network resources and cardholder data. Requirement 10 has several sections, listed below. The focus of this study is on the highlighted (bold) subsections: Teleran PCI Customer Case Study September, 2008 2
Requirement 10: Track and monitor all access to network resources and cardholder data Logging mechanisms and the ability to track user activities are critical. The presence of logs in all environments allows thorough tracking and analysis if something does go wrong. However, determining the cause of a compromise is very difficult without system activity logs. 10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user. 10.2 Implement automated audit trails for all system components to reconstruct the following events: 10.2.1 All individual user accesses to cardholder data 10.2.2 All actions taken by any individual with root or administrative privileges 10.2.3 Access to all audit trails 10.2.4 Invalid logical access attempts 10.2 5 Use of identification and authentication mechanisms 10.2.6 Initialization of the audit logs 10.2.7 Creation and deletion of system-level objects. 10.3 Record at least the following audit trail entries for all system components for each event: 10.3.1 User identification 10.3.2 Type of event 10.3.3 Date and time 10.3.4 Success or failure indication 10.3.5 Origination of event 10.3.6 Identity or name of affected data, system component, or resource 10.4 Synchronize all critical system clocks and times. 10.5 Secure audit trails so they cannot be altered: 10.5.1 Limit viewing of audit trails to those with a job-related need. 10.5.2 Protect audit trail files from unauthorized modifications. 10.5.3 Promptly back-up audit trail files to a centralized log server or media that is difficult to alter. 10.5.4 Copy logs for wireless networks onto a log server on the internal LAN. 10.5.5 Use file integrity monitoring and change detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert). 10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion detection system (IDS) and authentication, authorization and accounting protocol (AAA) servers (for example, RADIUS). Note: Log harvesting, parsing, and alerting tools may be used to achieve compliance with Requirement 10.6. 10.7 Retain audit trail history for at least one year, with a minimum of three months online availability. If the above highlighted requirements were to be addressed without a cohesive system, the organization would need to enable the following high-level steps: 1) Enable Logging in the Database. This can be a costly exercise for performance, storage and system management 2) Write the date to system logs which are typically flat files Teleran PCI Customer Case Study September, 2008 3
3) Flat files on a server are not secure, they would need to be encrypted (either through the logging process, an expensive and technically challenging operation), or on a set interval. This can introduce additional system overhead and exposure until the datasets are encrypted. 4) The data would need to be stored for the 1-year retention period. This can require significant amount of incremental storage. 5) A custom solution would need to be devised in order to present three months of data on-line. This would require the certification of another vendor system, or a custom in-house solution. 6) Additionally, depending on the database, and the method for connection, some of the required data may not be available. These steps would be a costly in terms of system infrastructure, development and data administration staff resources. The issuer needed to find a lower cost, more easily implemented PCI compliance solution The Teleran PCI Audit Solution Because the issuer had already implemented the Teleran System for database monitoring and user controls, the infrastructure was already in place to audit and control access to PCI covered data. The auditors were able to immediately assess and approve this solution to address previously failed Section 10 requirements. Using Teleran isight to Address PCI Auditing and Reporting Requirements The following highlights in (bold) how isight addressed these specific requirements: 10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user. isight logs all access to the database through the listener port regardless of security privileges. 10.2 Implement automated audit trails for all system components to reconstruct the following events: 10.2.1 All individual user accesses to cardholder data isight logs all user access through listener port, and captures key attributes like User ID and fully SQL statement. 10.2.2 All actions taken by any individual with root or administrative privileges isight logs all access to the database through the listener port regardless of security privileges. 10.2.3 Access to all audit trails isight logs all activity the user performs from log-on through log-off. 10.2 5 Use of identification and authentication mechanisms isight captures the User ID used to log into the database. 10.2.6 Initialization of the audit logs isight captures data as long as the listener port is up. This ensures that whenever access is allowed to the database, isight is capturing the activity. 10.3 Record at least the following audit trail entries for all system components for each event: isight captures User ID, IP Address, access tool, SQL statement, Start date/time, End Date Time, query status, Database errors associated with access, Database/Instance/Schema/Table/Column accessed, as well as many other attributes about the data. (This applies to all sub-sections below.) 10.3.1 User identification 10.3.2 Type of event 10.3.3 Date and time 10.3.4 Success or failure indication Teleran PCI Customer Case Study September, 2008 4
10.3.5 Origination of event 10.3.6 Identity or name of affected data, system component, or resource. 10.4 Synchronize all critical system clocks and times. isight leverages the system clock on the system it is running on. 10.5.1 Limit viewing of audit trails to those with a job-related need isight employs a robust security component, and allows read-only access to the data through reports. 10.5.2 Protect audit trail files from unauthorized modifications isight employs a robust security component, and allows read-only access to the data through reports. 10.5.3 Promptly back-up audit trail files to a centralized log server or media that is difficult to alter The Teleran repository can be backed-up using any standard backup protocols. 10.5 Secure audit trails so they cannot be altered. The Teleran system employs a robust security component, and allows read-only access to the data through reports. Using Teleran iguard To Address PCI Access Control and Data Protection Requirements The following highlights in (bold) how iguard addresses four major PCI access control and data protection requirements. iguard has already been implemented to address Requirement 3. iguard will be applied to address Requirements 1, 7 and 12 in the future. Compliance with these requirements significantly reduces risk of data loss due to malicious attempts at unauthorized system penetration and data theft: Requirement 3: Protect stored cardholder data. iguard prevents unauthorized access of both table and column access thereby protecting for example individual credit card holders account numbers and social security numbers. Requirement 1: Install and maintain a firewall configuration to protect cardholder data. iguard will function as a database firewall residing on the network, independent of the database and will restrict access to database objects at a granular level (table, column, cell, view or stored procedure). Requirement 7: Restrict physical access to cardholder data by business need-to-know. iguard data access policies will be applied individually to application users or groups of users depending on role and authorization. Requirement 12: Maintain a policy that addresses information security. iguard s data access policies will secure protected data by blocking access by unauthorized users or unauthorized applications. iguard connection policies will also prevent a user or application from even connecting to the database. References: https://www.pcisecuritystandards.org/index.htm Teleran PCI Customer Case Study September, 2008 5