Payment Card Industry (PCI) Data Security Standard and Bsafe/Enterprise Security

Payment Card Industry (PCI) Data Security Standard and Bsafe/Enterprise Security Mapping of Bsafe/Enterprise Security Controls to PCI-DSS Requirements and Security Assessment Procedures Version 1.2 vember 2008

Table of Contents Introduction and PCI Data Security Standard Overview 1 *te: Comments Column... 3 Build and Maintain a Secure Network... 3 Requirement 1: Install and maintain a firewall configuration to protect cardholder data 3 Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters 6 Protect Cardholder Data... 8 Requirement 3: Protect stored cardholder data 8 Requirement 4: Encrypt transmission of cardholder data across open, public networks 12 Maintain a Vulnerability Management Program... 14 Requirement 5: Use and regularly update anti-virus software or programs 14 Requirement 6: Develop and maintain secure systems and applications 15 Implement Strong Access Control Measures... 19 Requirement 7: Restrict access to cardholder data by business need to know 19 Requirement 8: Assign a unique ID to each person with computer access. 21 Requirement 9: Restrict physical access to cardholder data. 25 Regularly Monitor and Test Networks... 28 Requirement 10: Track and monitor all access to network resources and cardholder data. 28 Requirement 11: Regularly test security systems and processes. 30 Maintain an Information Security Policy... 32 Requirement 12: Maintain a policy that addresses information security for employees and contractors. 32 Introduction and PCI Data Security Standard Overview The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. This document uses as its foundation the 12 PCI DSS requirements, and matches them up with corresponding Bsafe/Enterprise Security and other Bsafe applications and modules. It is designed for use by companies looking for automated solutions to assist them in achieving compliance with the PCI DSS.

*te: Comments Column 't applicable' appears in circumstances where the requirement is a procedural issue, not in the scope of a security and system management product or if the requirement is not part of the functionality of the product such as a hardware or system architecture requirement. Build and Maintain a Secure Network Requirement 1: Install and maintain a firewall configuration to protect cardholder data Firewalls are computer devices that control computer traffic allowed between a company s network (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas within a company s internal trusted network. The cardholder data environment is an example of a more sensitive area within the trusted network of a company. A firewall examines all network traffic and blocks those transmissions that do not meet the specified security criteria. All systems must be protected from unauthorized access from untrusted networks, whether entering the system via the Internet as e-commerce, employees Internet access through desktop browsers, employees e-mail access, dedicated connection such as business to business connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key protection mechanism for any computer network. PCI DSS Requirements of 'In Place' * Bsafe Function 1.1 Establish firewall and router configuration standards that include the following: 1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations 1.1.2 Current network diagram with all connections to cardholder data, including any wireless networks 1.1.3 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone 1.1.4 Description of groups, roles, and responsibilities for logical management of network components 1.1.5 Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to Partial Partial Partial Bsafe/Enterprise Security's Application Audit function and the Bsafe/Assessment Tool are two tools which assist in formulating and conducting this process t applicable. Bsafe/Enterprise Security controls requests to the System i at the packet, user and application levels Administration role manager to divide Bsafe admin tasks among administrators. Application Access Control permissions by group profile, Bsafe Group, generic name, IP address and system policy Bsafe/Enterprise Security (compliance module, packet filtering, report generator and other functions) and the Bsafe/Assessment Tool include readymade reports to document system services, definitions and vulnerabilities.

be insecure 1.1.6 Requirement to review firewall and router rule sets at least every six months of 'In Place' * Bsafe Function t applicable. 1.2 Build a firewall configuration that restricts connections between untrusted networks and any system components in the cardholder data environment. 1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment. IP Packet Lockdown (packet filtering) and Application Access Control 1.2.2 Secure and synchronize router configuration files. 1.2.3 Install perimeter firewalls between any wireless networks and the cardholder data environment, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment. t applicable. I)P Packet Filtering 1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment. 1.3.1 Implement a DMZ to limit inbound and outbound traffic to only protocols that are necessary for the cardholder data environment. Application Access Control, IP Packet Lockdown 1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ. Application Access Control, IP Packet Lockdown 1.3.3 Do not allow any direct routes inbound or outbound for traffic between the Internet and the cardholder data environment. 1.3.4 Do not allow internal addresses to pass from the Internet into the DMZ. 1.3.5 Restrict outbound traffic from the cardholder data environment to the Internet such that outbound traffic can only access IP addresses within the DMZ. IP Packet Lockdown t applicable. IP Packet Lockdown

1.3.6 Implement stateful inspection, also known as dynamic packet filtering. (That is, only established connections are allowed into the network.) 1.3.7 Place the database in an internal network zone, segregated from the DMZ. 1.3.8 Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet, using RFC 1918 address space. Use network address translation (NAT) technologies for example, port address translation (PAT). 1.4 Install personal firewall software on any mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization s network. of 'In Place' For Port and IP Application Access Control and IP Packet Lockdown t applicable. t applicable. t applicable.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters Malicious individuals (external and internal to a company) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information. PCI DSS Requirements 2.1 Always change vendorsupplied defaults before installing a system on the network for example, include passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts. 2.1.1 For wireless environments connected to the cardholder data environment or transmitting cardholder data, change wireless vendor defaults, including but not limited to default wireless encryption keys, passwords, and SNMP community strings. Ensure wireless device security settings are enabled for strong encryption technology for authentication and transmission. of 'In Place' t applicable. t applicable. PCI DSS Requirements 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards. 2.2.1 Implement only one primary function per server. 2.2.2 Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the device s specified function). of 'In Place' Partial Implementation can be assisted by Bsafe system management functions like System Audit, System Value Inquiry, Compliance module t applicable. Application Access Control, IP Packet Lockdown

2.2.3 Configure system security parameters to prevent misuse. of 'In Place' Partial Implementation can be assisted by Bsafe system management functions like System Audit, System Value Inquiry 2.2.4 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers. Partial Implementation can be assisted by Bsafe Application Access Control PCI DSS Requirements 2.3 Encrypt all non-console administrative access. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other nonconsole administrative access. 2.4 Shared hosting providers must protect each entity s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers. of 'In Place' Partial Implementation of procedures can be assisted by using the Field Masking function to mask data and Application Access Control to restrict Telnet and other remote log-in commands t applicable.

Protect Cardholder Data Requirement 3: Protect stored cardholder data Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other network security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending PAN in unencrypted e-mails. Please refer to the PCI DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of strong cryptography and other PCI DSS terms. PCI DSS Requirements 3.1 Keep cardholder data storage to a minimum. Develop a data retention and disposal policy. Limit storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in the data retention policy. of 'In Place' t applicable. PCI DSS Requirements 3.2 Do not store sensitive authentication data after authorization (even if encrypted). Sensitive authentication data includes the data as cited in the following Requirements 3.2.1 through 3.2.3: 3.2.1 Do not store the full contents of any track from the magnetic stripe (located on the back of a card, contained in a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data. te: In the normal course of business, the following data elements from the magnetic stripe may need to be retained: The cardholder s name, Primary account number (PAN), Expiration date, and of 'In Place' t applicable. t applicable.

Service code To minimize risk, store only these data elements as needed for business. te: See PCI DSS Glossary of Terms, Abbreviations, and Acronyms for additional information. of 'In Place'

3.2.2 Do not store the cardverification code or value (threedigit or four-digit number printed on the front or back of a payment card) used to verify card-notpresent transactions. te: See PCI DSS Glossary of Terms, Abbreviations, and Acronyms for additional information. of 'In Place' t applicable. 3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block. 3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed). tes: This requirement does not apply to employees and other parties with a legitimate business need to see the full PAN. This requirement does not supersede stricter requirements in place for displays of cardholder data for example, for point-ofsale (POS) receipts. 3.4 Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches: One-way hashes based on strong cryptography Truncation Index tokens and pads (pads must be securely stored) Strong cryptography with associated key-management processes and procedures The MINIMUM account information that must be rendered unreadable is the PAN. tes: If for some reason, a company is unable render the PAN unreadable, refer to Appendix B: Compensating Controls. Strong cryptography is defined in the PCI DSS Glossary of Terms, Abbreviations, and Acronyms. Partial t applicable. Field Masking module Tape Encryption or Crypto Complete

3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms (for example, by not using local user account databases). Decryption keys must not be tied to user accounts. of 'In Place' Crypto Complete 3.5 Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse: 3.5.1 Restrict access to cryptographic keys to the fewest number of custodians necessary. 3.5.2 Store cryptographic keys securely in the fewest possible locations and forms. 3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following: 3.6.1 Generation of strong cryptographic keys 3.6.2 Secure cryptographic key distribution 3.6.3 Secure cryptographic key storage 3.6.4 Periodic cryptographic key changes As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically At least annually 3.6.5 Retirement or replacement of old or suspected compromised cryptographic keys Application Access Control, File Protection, CryptoComplete CryptoComplete CryptoComplete CryptoComplete CryptoComplete CryptoComplete CryptoComplete CryptoComplete 3.6.6 Split knowledge and establishment of dual control of cryptographic keys 3.6.7 Prevention of unauthorized substitution of cryptographic keys CryptoComplete CryptoComplete

3.6.8 Requirement for cryptographic key custodians to sign a form stating that they understand and accept their keycustodian responsibilities of 'In Place' t applicable. Requirement 4: Encrypt transmission of cardholder data across open, public networks Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols can be continued targets of malicious individuals who exploit these vulnerabilities to gain privileged access to cardholder data environments. PCI DSS Requirements 4.1 Use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks. Examples of open, public networks that are in scope of the PCI DSS are: The Internet, Wireless technologies, Global System for Mobile communications (GSM), and General Packet Radio Service (GPRS). of 'In Place' SSL option between Bsafe/Enterprise Security server and GUI components

4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission. For new wireless implementations, it is prohibited to implement WEP after March 31, 2009. For current wireless implementations, it is prohibited to use WEP after June 30, 2010. 4.2 Never send unencrypted PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat). of 'In Place' t applicable t applicable

Maintain a Vulnerability Management Program Requirement 5: Use and regularly update anti-virus software or programs Malicious software, commonly referred to as malware including viruses, worms, and Trojans enters the network during many business approved activities including employees e-mail and use of the Internet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats. PCI DSS Requirements Inclusion of Controls for Satisfying Requirement of 'In Place' 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers). 5.1.1 Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software. 5.2 Ensure that all anti-virus mechanisms are current, actively running, and capable of generating audit logs. Partial Partial Application Access Control File Server protects the System I IFS and reduces the chance of viruses or other malicious programs being transferred to the IFS t applicable t applicable

Requirement 6: Develop and maintain secure systems and applications Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor-provided security patches, which must be installed by the entities that manage the systems. All critical systems must have the most recently released, appropriate software patches to protect against exploitation and compromise of cardholder data by malicious individuals and malicious software. te: Appropriate software patches are those patches that have been evaluated and tested sufficiently to determine that the patches do not conflict with existing security configurations. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques. PCI DSS Requirements Inclusion of Controls for Satisfying Requirement of 'In Place' Bsafe Function 6.1 Ensure that all system components and software have the latest vendorsupplied security patches installed. Install critical security patches within one month of release. te: An organization may consider applying a risk-based approach to prioritize their patch installations. For example, by prioritizing critical infrastructure (for example, public-facing devices and systems, databases) higher than lesscritical internal devices, to ensure highpriority systems and devices are addressed within one month, and addressing less critical devices and systems within three months. 6.2 Establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the Internet). Update configuration standards as required by PCI DSS Requirement 2.2 to address new vulnerability issues. 6.3 Develop software applications in accordance with PCI DSS (for example, secure authentication and logging) and based on industry best practices, and incorporate information security throughout the software development life cycle. These processes must include the following: The Bsafe website is regularly updated with downloads of the latest patches t applicable Secure authentication, logging and other best practices used in development of Bsafe ES See below 6.3.1 Testing of all security patches, and system and software configuration changes before deployment, including but not limited to the following: 6.3.1.1 Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.) All patches are tested thoroughly and included fixes are detailed. The same is true for version upgrades t applicable 6.3.1.2 Validation of proper error

handling 6.3.1.3 Validation of secure cryptographic storage 6.3.1.4 Validation of secure communications 6.3.1.5 Validation of proper rolebased access control (RBAC) 6.3.2 Separate development/test and production environments 6.3.3 Separation of duties between development/test and production environments 6.3.4 Production data (live PANs) are not used for testing or development 6.3.5 Removal of test data and accounts before production systems become active 6.3.6 Removal of custom application accounts, user IDs, and passwords before applications become active or are released to customers 6.3.7 Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability te: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle required by PCI DSS Requirement 6.3. Code reviews can be conducted by knowledgeable internal personnel or third parties. Web applications are also subject to additional controls, if they are public facing, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.6. Inclusion of Controls for Satisfying Requirement of 'In Place' Bsafe Function t applicable SSL encryption between Bsafe/ES GUI and server components Application Access Control and Administration Role Manager t applicable Application Access Control and Administration Role Manager t applicable t applicable Development QA Development QA

6.4 Follow change control procedures for all changes to system components. The procedures must include the following: t applicable 6.4.1 Documentation of impact t applicable 6.4.2 Management sign-off by t applicable appropriate parties 6.4.3 Testing of operational t applicable functionality 6.4.4 Back-out procedures t applicable 6.5 Develop all web applications (internal and external, and including web administrative access to application) based on secure coding guidelines such as the Open Web Application Security Project Guide. Cover prevention of common coding vulnerabilities in software development processes, to include the following: te: The vulnerabilities listed at 6.5.1 through 6.5.10 were current in the OWASP guide when PCI DSS v1.2 was published. However, if and when the OWASP guide is updated, the current version must be used for these requirements. t applicable

6.5.1 Cross-site scripting (XSS) t applicable 6.5.2 Injection flaws, particularly SQL injection. Also consider LDAP and Xpath injection flaws as well as other injection flaws. t applicable 6.5.3 Malicious file execution All Bsafe/Enterprise Security logs 6.5.4 Insecure direct object references 6.5.5 Cross-site request forgery (CSRF) 6.5.6 Information leakage and improper error handling 6.5.7 Broken authentication and session management 6.5.8 Insecure cryptographic storage Partially Application Access Control, Object Authority Manager, Policy Compliance Manager t applicable t applicable Session Timeout CryptoComplete 6.5.9 Insecure communications Application Access Control 6.5.10 Failure to restrict URL access t applicable PCI DSS Requirements 6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes Installing a web-application firewall in front of public-facing web applications t applicable

Implement Strong Access Control Measures Requirement 7: Restrict access to cardholder data by business need to know To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities. Need to know is when access rights are granted to only the least amount of data and privileges needed to perform a job. PCI DSS Requirements 7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access. Access limitations must include the following: 7.1.1 Restriction of access rights to privileged user IDs to least privileges necessary to perform job responsibilities 7.1.2 Assignment of privileges is based on individual personnel s job classification and function 7.1.3 Requirement for an authorization form signed by management that specifies required privileges 7.1.4 Implementation of an automated access control system Application Access Control, Policy Compliance Manager. Administration Roles Manager, Field Masking, CryptoComplete Application Access Control (Account Types, System Default),, Field Masking, CryptoComplete Application Access Control, Policy Compliance Manager,, Field Masking, CryptoComplete t applicable Bsafe/Enterprise Security for System i

7.2 Establish an access control system for systems components with multiple users that restricts access based on a user s need to know, and is set to deny all unless specifically allowed. This access control system must include the following: 7.2.1 Coverage of all system components Application Access Control, Field Masking, File Protection, IP Packet Lockdown See above 7.2.2 Assignment of privileges to individuals based on job classification and function See above 7.2.3 Default deny-all setting System Policy

Requirement 8: Assign a unique ID to each person with computer access. Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users. PCI DSS Requirements 8.1 Assign all users a unique ID before allowing them to access system components or cardholder data. 8.2 In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users: Password or passphrase Two-factor authentication (for example, token devices, smart cards, biometrics, or public keys) 8.3 Incorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties. Use technologies such as remote authentication and dial-in service (RADIUS); terminal access controller access control system (TACACS) with tokens; or VPN (based on SSL/TLS or IPSEC) with individual certificates. 8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography (defined in PCI DSS Glossary of Terms, Abbreviations, and Acronyms). User Profile Manager in combination with Application Access Control User Profile Manager r addresses password settings Application Access Control, IP Packet Filtering Application Access Control uses TelNet/SSL OS/400 itself encrypts passwords stored on OS400

8.5 Ensure proper user authentication and password management for nonconsumer users and administrators on all system components as follows: 8.5.1 Control addition, deletion, and modification of user IDs, credentials, and other identifier objects. User Profile Manager & Application Access Control 8.5.2 Verify user identity before performing password resets. 8.5.3 Set first-time passwords to a unique value for each user and change immediately after the first use. 8.5.4 Immediately revoke access for any terminated users. 8.5.5 Remove/disable inactive user accounts at least every 90 days. 8.5.6 Enable accounts used by vendors for remote maintenance only during the time period needed. 8.5.7 Communicate password procedures and policies to all users who have access to cardholder data. User Profile Manager User Profile Manager, Administration Roles Manager : using Restricted Security Officer role User Profile Manager, Object Authority Manager, Application Access Control, Inactive User Management Inactive Users module for automatic disabling and deletion Application Access Control time restrictions, and authority swapping, t applicable

8.5.8 Do not use group, shared, or generic accounts and passwords. Policy Compliance Manager 8.5.9 Change user passwords at least every 90 days. 8.5.10 Require a minimum password length of at least seven characters. Policy Compliance Manager and User Profile Manager Password change period parameter can be viewed in System Value Inquiry and Report Generator. Last change information available for all users in Password Inquiry Policy Compliance Manager, Password minimum length parameter can be viewed in System Value Inquiry and Report Generator.

8.5.11 Use passwords containing both numeric and alphabetic characters. 8.5.12 Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used. 8.5.13 Limit repeated access attempts by locking out the user ID after not more than six attempts. 8.5.14 Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID. 8.5.15 If a session has been idle for more than 15 minutes, require the user to re-enter the password to reactivate the terminal. 8.5.16 Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users. Partial Policy Compliance Manager, Password content parameters can be viewed in System Value Inquiry and Report Generator. Policy Compliance Manager, Password repetition parameters can be viewed in System Value Inquiry and Report Generator. Policy Compliance Manager, Application Access Control Resetting the account provided through Session Timeout Automatic resetting following lock out using System Audit & Alert Center. Session Timeout Application Access Control, Field Masking, File Protection, Object Authority Manager

Requirement 9: Restrict physical access to cardholder data. Any physical access to data or systems that house cardholder data provides the opportunity for individuals to access devices or data and to remove systems or hardcopies, and should be appropriately restricted. PCI DSS Requirements 9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment. 9.1.1 Use video cameras or other access control mechanisms to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law. te: Sensitive areas refers to any data center, server room or any area that houses systems that store, process, or transmit cardholder data. This excludes the areas where only point-of-sale terminals are present, such as the cashier areas in a retail store. 9.1.2 Restrict physical access to publicly accessible network jacks. 9.1.3 Restrict physical access to wireless access points, gateways, and handheld devices. 9.2 Develop procedures to help all personnel easily distinguish between employees and visitors, especially in areas where cardholder data is accessible. For purposes of this requirement, employee refers to full-time and parttime employees, temporary employees and personnel, and contractors and consultants who are resident on the entity s site. A visitor is defined as a vendor, guest of an employee, service personnel, or anyone who needs to enter the facility for a short duration, usually not more than one day. t applicable t applicable t applicable t applicable t applicable 9.3 Make sure all visitors are handled as follows: 9.3.1 Authorized before entering areas where cardholder data is processed or maintained 9.3.2 Given a physical token (for example, a badge or access device) that expires and that identifies the visitors as non-employee t applicable t applicable

9.3.3 Asked to surrender the physical token before leaving the facility or at the date of expiration 9.4 Use a visitor log to maintain a physical audit trail of visitor activity. Document the visitor s name, the firm represented, and the employee authorizing physical access on the log. Retain this log for a minimum of three months, unless otherwise restricted by law. t applicable t applicable

9.5 Store media back-ups in a secure location, preferably an off-site facility, such as an alternate or back-up site, or a commercial storage facility. Review the location s security at least annually. 9.6 Physically secure all paper and electronic media that contain cardholder data. 9.7 Maintain strict control over the internal or external distribution of any kind of media that contains cardholder data, including the following: 9.7.1 Classify the media so it can be identified as confidential. 9.7.2 Send the media by secured courier or other delivery method that can be accurately tracked. 9.8 Ensure management approves any and all media containing cardholder data that is moved from a secured area (especially when media is distributed to individuals). 9.9 Maintain strict control over the storage and accessibility of media that contains cardholder data. 9.9.1 Properly maintain inventory logs of all media and conduct media inventories at least annually. t applicable t applicable t applicable t applicable t applicable t applicable CryptoComplete t applicable PCI DSS Requirements 9.10 Destroy media containing cardholder data when it is no longer needed for business or legal reasons as follows: 9.10.1 Shred, incinerate, or pulp hardcopy materials so that cardholder data cannot be reconstructed. 9.10.2 Render cardholder data on electronic media unrecoverable so that cardholder data cannot be reconstructed. t applicable t applicable CryptoComplete

Regularly Monitor and Test Networks Requirement 10: Track and monitor all access to network resources and cardholder data. Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult without system activity logs. PCI DSS 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. System Audit, Central Audit, Application Access Control, File Audit 10.2 Implement automated audit trails for all system components to reconstruct the following events: 10.2.1 All individual 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 As above File Audit, Application Audit, System Audit File Audit, Application Audit, System Audit, Bsafe Administrator Audit 10.2.4 Invalid logical access attempts Application Access Control 10.2 5 Use of identification and authentication mechanisms System Audit, Central Audit, Application Access Control, File Audit 10.2.6 Initialization of the audit logs Bsafe Administrator Audit, System Audit 10.2.7 Creation and deletion of system-level objects System Audit 10.3 Record at least the following audit trail entries for all system components for each event: 10.3.1 User identification All logs within Bsafe/Enterprise Security 10.3.2 Type of event All logs within Bsafe/Enterprise Security 10.3.3 Date and time All logs within Bsafe/Enterprise Security 10.3.4 Success or failure indication All logs within Bsafe/Enterprise Security 10.3.5 Origination of event All logs within

10.3.6 Identity or name of affected data, system component, or resource 10.4 Synchronize all critical system clocks and times. Bsafe/Enterprise Security All logs within Bsafe/Enterprise Security t applicable 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 Write logs for external-facing technologies onto a log server on the internal LAN. 10.5.5 Use file-integrity monitoring or 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). 11.2 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). te: Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6 10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from back-up). Partially Administration Role Manager Object Authority Manager, Application Access Control, Policy Compliance Manager, Administration Role Manager Partially CryptoComplete which makes back-up fuiles difficult to alter Cross Platform Audit (CPA) Alert Center, Application Access Control System Audit Policy, Application Access Control, System Policy Cross Platform Audit (CPA)

Requirement 11: Regularly test security systems and processes. Vulnerabilities are being discovered continually by malicious individuals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequently to ensure security controls continue to reflect a changing environment. PCI DSS Requirements 11.1 Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use. t applicable wireless connections to System i 11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades). te: Quarterly external vulnerability scans must be performed by an Approved Scanning Vendor (ASV) qualified by Payment Card Industry Security Standards Council (PCI SSC). Scans conducted after network changes may be performed by the company s internal staff. Bsafe/Security Assessment Tool (SAT), Policy Compliance Manager, Report Generator 11.3 Perform external and internal penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a subnetwork added to the environment, or a web server added to the environment). These penetration tests must include the following: 11.3.1 Network-layer penetration tests 11.3.2 Application-layer penetration tests 11.4 Use intrusion-detection systems, and/or intrusion-prevention systems to monitor all traffic in the cardholder data environment and alert personnel to suspected compromises. Keep all intrusion-detection and prevention engines up-to-date. Bsafe/Security Assessment Tool (SAT) Policy Compliance Manager, Report Generator Bsafe/Security Assessment Tool (SAT), Report Generator Bsafe/Security Assessment Tool (SAT), Report Generator File Audit, Central Audit (Read Record Data) 11.5 Deploy file-integrity monitoring File Audit, System

software to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly. te: For file-integrity monitoring purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. File-integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider). Audit, Report Generator and Policy Compliance Manager

Maintain an Information Security Policy Requirement 12: Maintain a policy that addresses information security for employees and contractors. A strong security policy sets the security tone for the whole company and informs employees what is expected of them. All employees should be aware of the sensitivity of data and their responsibilities for protecting it. For the purposes of this requirement, employees refers to full-time and part-time employees, temporary employees and personnel, and contractors and consultants who are resident on the company s site. PCI DSS Requirements 12.1 Establish, publish, maintain, and disseminate a security policy that accomplishes the following: 12.1.1 Addresses all PCI DSS requirements. 12.1.2 Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment. 12.1.3 Includes a review at least once a year and updates when the environment changes. 12.2 Develop daily operational security procedures that are consistent with requirements in this specification (for example, user account maintenance procedures, and log review procedures). Partial t applicable t applicable t applicable

12.3 Develop usage policies for critical employee-facing technologies (for example, remoteaccess technologies, wireless technologies, removable electronic media, laptops, personal data/digital assistants (PDAs), e-mail usage and Internet usage) to define proper use of these technologies for all employees and contractors. Ensure these usage policies require the following: 12.3.1 Explicit management approval 12.3.2 Authentication for use of the technology 12.3.3 A list of all such devices and personnel with access 12.3.4 Labeling of devices with owner, contact information, and purpose 12.3.5 Acceptable uses of the technology 12.3.6 Acceptable network locations for the technologies 12.3.7 List of company-approved products 12.3.8 Automatic disconnect of sessions for remote-access technologies after a specific period of inactivity 12.3.9 Activation of remote-access technologies for vendors only when needed by vendors, with immediate deactivation after use t applicable t applicable t applicable t applicable Application Access Control t applicable Session Timeout. Application Access Control, Authority Swapping

12.3.10 When accessing cardholder data via remote-access technologies, prohibit copy, move, and storage of cardholder data onto local hard drives and removable electronic media. 12.4 Ensure that the security policy and procedures clearly define information security responsibilities for all employees and contractors. 12.5 Assign to an individual or team the following information security management responsibilities: 12.5.1 Establish, document, and distribute security policies and procedures. 12.5.2 Monitor and analyze security alerts and information, and distribute to appropriate personnel. 12.5.3 Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations. 12.5.4 Administer user accounts, including additions, deletions, and modifications 12.5.5 Monitor and control all access to data. Application Access Control, t applicable Administration Roles Manager. Pre-defined roles and tailored roles as 'restricted security officer' Done in Compliance module. Done in Alert center and CPA Alerts t applicable Done in Application Access Control, Object Authority Manager, User Profile Manager Done in Application Access Control, Application Audit, File Audit, Object Authority Manager, File Protection, Field Masking

12.6 Implement a formal security awareness program to make all employees aware of the importance of cardholder data security. t applicable 12.6.1 Educate employees upon hire and at least annually. 12.6.2 Require employees to acknowledge at least annually that they have read and understood the company s security policy and procedures. 12.7 Screen potential employees (see definition of employee at 9.2 above) prior to hire to minimize the risk of attacks from internal sources. For those employees such as store cashiers who only have access to one card number at a time when facilitating a transaction, this requirement is a recommendation only. t applicable t applicable t applicable 12.8 If cardholder data is shared with service providers, maintain and implement policies and procedures to manage service providers, to include the following: 12.8.1 Maintain a list of service providers. 12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess. 12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement. 12.8.4 Maintain a program to monitor service providers PCI DSS compliance status. t applicable t applicable t applicable t applicable 12.9 Implement an incident response plan. Be prepared to respond immediately to a system breach.

12.9.1 Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum: Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum Specific incident response procedures Business recovery and continuity procedures Data back-up processes Analysis of legal requirements for reporting compromises Coverage and responses of all critical system components Reference or inclusion of incident response procedures from the payment brands 12.9.2 Test the plan at least annually. 12.9.3 Designate specific personnel to be available on a 24/7 basis to respond to alerts. 12.9.4 Provide appropriate training to staff with security breach response responsibilities. t applicable t applicable t applicable t applicable PCI DSS Requirements 12.9.5 Include alerts from intrusiondetection, intrusion-prevention, and file-integrity monitoring systems. 12.9.6 Develop process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments. Alert Center t applicable + -+