Attestation of Compliance, SAQ D

Transcription

1 Attestation of Compliance, SAQ D Instructions for Submission The merchant must complete this Attestation of Compliance as a declaration of the merchant's compliance status with the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Security Assessment Procedures. Complete all applicable sections and refer to the submission instructions at "PCI DSS Compliance - Completion Steps" in this document. Part 1. Merchant and Qualified Security Assessor Information Part 1a. Merchant Organization Information Company Name: BookingCenter LLC Contact Name: Jesse Chieppa DBA(S): Title: Telephone: (707) ext 2 jesse@bookingcenter.com Business Address: 495 Tramway Drive, Unit 8 City: Stateline State/Province: NV Country: United States URL: ZIP: Part 1b. Qualified Security Assessor Company Information (if applicable) Company Name: Lead QSA Contact Name: Telephone: Business Address: Title: City: State/Province: Country: ZIP: URL: List facilities and locations included in PCI DSS review: Part 2. Type of merchant business (check all that apply): Merchant Type MCC Code(s) Lodging - Hotels, Motels, Resorts, Central Reservation Services Part 2a. Relationships Does your company have a relationship with one or more third-party agents (for example, gateways, web-hosting companies, airline booking agents, loyalty program agents, etc.)? Does your company have a relationship with more than one credit card processor (acquirer)? Yes No Yes No PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 1

2 Part 2b. Transaction Processing Payment Application Vendor Payment Application In Use Payment Application Version Part 3. PCI DSS Validation Based on the results noted in the SAQ D dated :18:14, BookingCenter LLC asserts the following compliance status (check one): Compliant: All sections of the PCI SAQ are complete, and all questions answered "yes," resulting in an overall COMPLIANT rating, thereby BookingCenter LLC has demonstrated full compliance with the PCI DSS. Non-Compliant: Not all sections of the PCI SAQ are complete, or some questions are answered "no," resulting in an overall NON-COMPLIANT rating, thereby BookingCenter LLC has not demonstrated full compliance with the PCI DSS. Target Date for Compliance: An entity submitting this form with a status of Non-Compliant may be required to complete the Action Plan in Part 4 of this document. Check with your credit card processor (acquirer) or the payment brand(s) before completing Part 4, since not all payment brands require this section. Part 3a. Confirmation of Compliant Status Merchant confirms: PCI DSS Self-Assessment naire D, Version 2.0, was completed according to the instructions therein. All information within the above-referenced SAQ and in this attestation fairly represents the results of my assessment. I have read the PCI DSS and I recognize that I must maintain full PCI DSS compliance at all times. No evidence of magnetic stripe (i.e., track) data2, CAV2, CVC2, CID, or CVV2 data3, or PIN data4 storage after transaction authorization was found on ANY systems reviewed during this assessment. Part 3b. Merchant Acknowledgement Signature of Merchant Executive Officer Jeff Tweddale Merchant Executive Officer Name BookingCenter LLC Merchant Company Represented :18:14 Date Title Part 4. Action Plan for Non-Compliant Status Please select the appropriate "Compliance Status" for each requirement. If you answer "NO" to any of the requirements, you are required to provide the date Company will be compliant with the requirement and a brief description of the actions being taken to meet the requirement. Check with your credit card processor (acquirer) or the payment brand(s) before completing Part 4, since not all payment brands require this section. PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 2

3 PCI DSS Requirement Follow standards for service providers Change wireless default settings Install and maintain a firewall Set policies for remote access Test security systems and processes Manage disk encryption security Follow secure remote access procedures Develop secure systems and applications Do not use vendor-supplied defaults Protect stored cardholder data Encrypt transmission of cardholder data Use and update anti-virus software Upkeep secure systems and applications Restrict access to cardholder data Assign unique IDs Restrict physical access Track access to resources and data Maintain a security policy Description of Requirement Follow standards for service providers Change wireless default settings Install and maintain a firewall Set policies for remote access Test security systems and processes Manage disk encryption security Follow secure remote access procedures Develop secure systems and applications Do not use vendor-supplied defaults Protect stored cardholder data Encrypt transmission of cardholder data Use and update anti-virus software Upkeep secure systems and applications Restrict access to cardholder data Assign unique IDs Restrict physical access Track access to resources and data Maintain a security policy Compliance Status (Select One) YES NO Remediation Date and Actions (if Compliance Status is "NO") PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 3

4 PCI DSS Requirement Shared Hosting Provider Requirements Description of Requirement Shared Hosting Provider Requirements Compliance Status (Select One) YES NO Remediation Date and Actions (if Compliance Status is "NO") Self-Assessment naire D Date of Completion: :18:14 Follow standards for service providers Requirement : Follow standards for service providers For issuers and/or companies that support issuing services and store sensitive authentication data, there is a business justification for the storage of sensitive authentication data, and that data is secured. For service providers only: If keys are shared with customers for transmission or storage of cardholder data, documentation is provided to customers that includes guidance on how to securely transmit, store and update customer's keys, in accordance with your documented key-management processes and procedures. Non-consumer user passwords are required to be changed periodically and non-consumer users are given guidance as to when, and under what circumstances, passwords must change. Non-consumer user passwords must be at least seven characters in length. Non-consumer user passwords are required to contain both numeric and alphabetic characters. New, non-consumer user passwords are required to be different from any of the last four passwords used. Non-consumer user passwords are temporarily locked-out after not more than six invalid access attempts. Change wireless default settings Requirement : Change wireless default settings Encryption keys are changed from default at installation, and changed anytime anyone with knowledge of the keys leaves the company or changes positions. PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 4

5 SNMP community strings are changed from default on wireless devices connected to the cardholder data environment. Passwords on wireless access points are changed from default. Firmware on wireless devices are updated to support strong encryption for authentication and transmission over wireless networks. Any other existing security-related wireless vendor defaults are changed. Industry best practices are used to implement strong encryption for authentication and transmission for wireless networks transmitting cardholder data or connected to the cardholder data environment. Install and maintain a firewall Requirement : Install and maintain a firewall There is a formal process for approving and testing all external network connections and changes to the firewall and router configurations. There is a current network diagram that documents all connections to cardholder data, including any wireless networks. The network diagram is kept current. Configuration standards include requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone. The current network diagram is consistent with the firewall configuration standards. Firewall and router configuration standards include a description of groups, roles, and responsibilities for logical management of network components. Firewall and router configuration standards include a documented list of services, protocols and ports necessary for business. All allowed insecure services, protocols, and ports are necessary, and compensating security features are documented and implemented for each. Firewall and router configuration policy requires a review of firewall and router rule sets at least every six months. Firewall and router rule sets are reviewed at least every six months. Firewall and router configurations restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and these restrictions are documented. PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 5

6 Firewall and router configurations for the cardholder data environment specifically deny all inbound and outbound traffic other than what is necessary. All router configuration files are secure and synchronized. Perimeter firewalls are installed between any wireless networks and the cardholder data environment. These firewalls are configured to deny or control any traffic from the wireless environment into the cardholder data environment. A demilitarized zone (DMZ) is implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports. Inbound Internet traffic is limited to IP addresses within the DMZ. The firewall configuration prohibits direct connections for inbound or outbound traffic between the Internet and the cardholder data environment. Internal addresses are prohibited from passing from the Internet into the DMZ. The firewall configuration requires all outbound traffic from the cardholder data environment to the Internet to be explicitly authorized. The firewall configuration implements dynamic packet filtering. System components that store cardholder data (such as a database) are placed in an internal network zone, segregated from the DMZ and other untrusted networks. Methods are in place to prevent the disclosure of private IP addresses and routing information to the Internet. Any disclosure of private IP addresses and routing information to external entities is authorized. Personal firewall software is installed and active on any employee-owned and/or mobile computers which are used to access the organization's network and have direct connectivity to the Internet. The personal firewall software is configured to specific standards and is not alterable by users of employee-owned and/or mobile computers. Set policies for remote access Requirement : Set policies for remote access For personnel accessing cardholder data via remote-access technologies, the policy specifies the prohibition of copy, move, and storage of cardholder data onto local hard drives and removable electronic media, unless explicitly authorized for a defined business need. PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 6

7 For personnel with proper authorization to copy, move, or store cardholder data onto local hard drives or removable electronic media, the policy requires the protection of cardholder data in accordance with PCI DSS Requirements. Test security systems and processes Requirement : Test security systems and processes A documented process is implemented to detect and identify wireless access points on a quarterly basis. The methodology detects and identifies any unauthorized wireless access points, including at least the following: WLAN cards inserted into system components Portable wireless devices connected to system components (for example, by USB, etc.) Wireless devices attached to a network port or network device The process to identify unauthorized wireless access points is performed at least quarterly for all system components and facilities. If automated monitoring is utilized (for example, wireless IDS/IPS, NAC, etc.), monitoring is configured to generate alerts to personnel. The Incident Response Plan includes a response in the event unauthorized wireless devices are detected. Quarterly internal vulnerability scans are performed. The quarterly internal scan process includes rescans until passing results are obtained, or until all "High" vulnerabilities are resolved. Internal quarterly scans are performed by a qualified internal resource(s) or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV). Quarterly external vulnerability scans are performed. External quarterly scan results satisfy the ASV Program Guide requirements (for example, no vulnerabilities rated higher than a 4.0 by the CVSS and no automatic failures). Quarterly external vulnerability scans are performed by an Approved Scanning Vendor (ASV), approved by the Payment Card Industry Security Standards Council (PCI SSC). Internal and external scans are performed after any significant change (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades). PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 7

8 The scan process after any significant change includes rescans until: For external scans, no vulnerabilities exist that are scored greater than a 4.0 by the CVSS, For internal scans, a passing result is obtained or all "High" vulnerabilities are resolved. Scans are performed after any significant change by a qualified internal resource(s) or qualified external third party, and if applicable, organizational independence of the tester exists (not required to be a QSA or ASV). External and internal penetration testing is performed at least once a year and after any significant infrastructure or application changes. Exploitable vulnerabilities discovered in penetration testing are corrected and testing repeated. Penetration tests are performed by a qualified internal or external resource. Network-layer penetration tests are performed. Application-layer penetration tests are performed. Intrusion-detection systems and/or intrusion-prevention systems are used to monitor all traffic at the perimeter of the cardholder data environment as well as at critical points inside of the cardholder data environment. Intrusion prevention systems (IPS) and/or intrusion detection systems (IDS) are configured to alert personnel of suspected compromises. All intrusion-detection and prevention engines, baselines, and signatures are kept up-to-date. File-integrity monitoring tools are deployed within the cardholder data environment. The file-integrity monitoring tools are configured to alert personnel to unauthorized modification of critical system files, configuration files or content files, and the tools perform critical file comparisons at least weekly. Manage disk encryption securityrequirement : Manage disk encryption security If disk encryption (rather than file- or column-level database encryption) is used, logical access to encrypted file systems is managed independently of native operating system access control mechanisms. If disk encryption (rather than file- or column-level database encryption) is used, cryptographic keys are stored securely. If disk encryption (rather than file- or column-level database encryption) is used, cardholder data on removable media is encrypted wherever stored. Follow secure remote access proceduresrequirement : Follow secure remote access procedures PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 8

9 Two-factor authentication is incorporated for remote access to the network by employees, administrators, and third parties. Accounts used by vendors for remote access, maintenance, or support are enabled only during the time period needed. Vendor remote access accounts are monitored when in use. All non-console administrative access is encrypted with strong cryptography, and a strong encryption method is invoked before the administrator's password is requested. Systems are configured so that Telnet and other insecure remote login commands are not allowed. Administrator access to web-based management interfaces is encrypted with strong cryptography. Develop secure systems and applicationsrequirement : Develop secure systems and applications Software development processes are based on industry standards and best practices. Information security is included throughout the software development life cycle. Software applications are developed in accordance with PCI DSS (Data Security Standards). Custom application accounts, user IDs, and/or passwords are removed before applications become active or are released to customers. All custom application code changes are reviewed (either using manual or automated processes) prior to release to production or customers in order to identify any potential coding vulnerability as follows: Code changes are reviewed by individuals other than the originating code author, and by individuals who are knowledgeable in code review techniques and secure coding practices. Code reviews ensure code is developed according to secure coding guidelines. Appropriate corrections are implemented prior to release. Code review results are reviewed and approved by management prior to release. Change control processes and procedures are followed for all changes to system components to ensure that development/test environments are separate from the production environment. Access control is in place to enforce the separation. Change control processes and procedures are followed for all changes to system components to ensure that there are separation of duties between personnel assigned to the development/test environments and those assigned to the production environment. PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 9

10 Change control processes and procedures are followed for all changes to system components to ensure that production data (especially live credit card numbers) is not used for testing or development. Change control processes and procedures are followed for all changes to system components to ensure that test data and accounts are removed before production systems become active. Change control procedures for implementing security patches and software modifications are documented. Documentation of impact is performed for all changes. Approval by authorized parties is documented for all changes. Functionality testing to verify that the change does not adversely impact the security of the system is performed for all changes. For custom code changes, updates are tested for compliance with PCI DSS Requirements before being deployed into production. Back-out procedures are prepared for each custom code change. Custom applications are developed based on secure coding guidelines. Developers of custom applications are knowledgeable in secure coding techniques. Software development processes ensure that applications are not vulnerable to Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP injection flaws, XPath injection flaws, and other injection flaws. Software development processes ensure that applications are not vulnerable to buffer overflow. Software development processes ensure that applications are not vulnerable to Insecure cryptographic storage. (Prevent cryptographic flaws.) Software development processes ensure that applications are not vulnerable to insecure communications. Software development processes ensure that applications are not vulnerable to improper error handling. Software development processes ensure that applications are not susceptible to any known "High" vulnerabilities. For web applications and application interfaces (internal or external), cross-site scripting (XSS) vulnerabilities are addressed. For web applications and application interfaces (internal or external), improper access control vulnerabilities such as insecure direct object references, failure to restrict URL access, and directory traversal are addressed. For web applications and application interfaces (internal or external), cross-site request forgery (CSRF) vulnerabilities are addressed. PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 10

11 Public-facing web applications are protected against new threats and vulnerabilities on an ongoing basis by either: A web-application firewall in front of public-facing web applications that detects and prevents web-based attacks. -or- Review of public-facing web applications at least annually and after any changes by an organization that specializes in application security. This review is done manually or by automated application vulnerability security assessment tools. All vulnerabilities are corrected and the application is re-evaluated after the corrections. Do not use vendor-supplied defaultsrequirement 2: Do not use vendor-supplied defaults Vendor-supplied defaults are always changed before installing a system on the network. Configuration standards are developed for all system components and are consistent with industry-accepted system hardening standards. System configuration standards are updated as new vulnerability issues are identified. System configuration standards are applied when new systems are configured. System configuration standards specify that only one primary function is implemented per server. If virtualization technologies are used, system configuration standards specify that only one primary function is implemented per virtual system component or device. All unnecessary functionality on devices and computers within the cardholder data environment have been disabled. All enabled insecure services, daemons, or protocols are justified, and compensating security features are documented and implemented. System administrators and/or personnel that configure system components are knowledgeable about common security parameter settings for those system components. Common system security parameters are included in the system configuration standards. Security parameters are set appropriately on system components. All unnecessary functionality has been removed from all systems. Enabled functions are documented and support secure configuration. Only documented functionality is present on system components. Protect stored cardholder datarequirement 3: Protect stored cardholder data PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 11

12 Data retention and disposal policies and procedures are implemented and include specific requirements for retention of cardholder data as required for business, legal, and/or regulatory purposes. Data retention and disposal policies and procedures include provisions for the secure disposal of cardholder and other data when no longer needed for legal, regulatory, or business reasons. Data retention and disposal policies and procedures covers all storage of cardholder data. Data retention and disposal processes and procedures include at least one of the following: A programmatic process (automatic or manual) to remove, at least quarterly, stored cardholder data that exceeds requirements defined in the data retention policy Requirements for a review, conducted at least quarterly, to verify that stored cardholder data does not exceed requirements defined in the data retention policy. All stored cardholder data meets the requirements defined in the data retention policy. If sensitive authentication data is received and deleted, processes are in place to securely delete the data to verify that the data is unrecoverable. After authorization, no systems store the full contents of any track from the magnetic stripe under any circumstance, even if encrypted. After authorization, no systems store the card verification code or value under any circumstance, even if encrypted. Regarding non-storage of sensitive authentication data after authorization (even if encrypted), all systems adhere to not storing the personal identification number (PIN) or the encrypted PIN block under any circumstance. The credit card number is masked when displayed (the first six and last four digits are the maximum number of digits to be displayed). The credit card number (PAN) is rendered unreadable anywhere it is stored (including data repositories, portable digital media, backup media, and in audit log), by using any of the following approaches. One-way hashes based on strong cryptography (hash must be of the entire PAN) Truncation (hashing cannot be used to replace the truncated segment of PAN) Index tokens and pads (pads must be securely stored) Strong cryptography with associated key management processes and procedures. Any keys used to secure cardholder data are protected against disclosure and misuse by restricting access to cryptographic keys to the fewest number of custodians necessary. PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 12

13 Any keys used to secure cardholder data are protected against disclosure and misuse by storing keys in encrypted format and by storing key-encrypting keys separately from data-encrypting keys. Any keys used to secure cardholder data are protected against disclosure and misuse by storing cryptographic keys in the fewest possible locations and forms. All key-management processes and procedures are fully documented and implemented for cryptographic keys used for encryption of cardholder data. Cryptographic key-management processes and procedures include the generation of strong cryptographic keys. Cryptographic key-management processes and procedures include secure cryptographic key distribution. Cryptographic key-management processes and procedures include secure cryptographic key storage. Cryptographic key-management processes and procedures include cryptographic key changes for keys that have reached the end of their defined cryptoperiod as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication ). Cryptographic key-management processes and procedures include retirement or replacement of cryptographic keys when the integrity of the key has been weakened such as after the departure of an employee with knowledge of a clear-text key. Cryptographic key-management processes and procedures include replacement of known or suspected compromised keys. Cryptographic key-management processes and procedures states that if retired or replaced cryptographic keys are retained, these keys are only used for decryption/verification purposes and not used for encryption operations. Cryptographic key-management processes and procedures include split knowledge and dual control of cryptographic keys for manual clear-text key-management operations. Cryptographic key-management processes and procedures include the prevention of unauthorized substitution of cryptographic keys. Cryptographic key-management processes and procedures require cryptographic key custodians to formally acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities. Encrypt transmission of cardholder datarequirement 4: Encrypt transmission of cardholder data PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 13

14 Strong cryptography and security protocols, such as SSL/TLS, SSH or IPSEC, are used to safeguard sensitive cardholder data during transmission over open, public networks. Only trusted keys and/or certificates are accepted. Security protocols are implemented to use only secure configurations, and not support insecure versions or configurations. The proper encryption strength is implemented for the encryption methodology in use (check vendor recommendations/best practices). Verify that any webpage your company uses for processing credit cards appears as not Ensure that the website does not accept or ask for credit card information unless is present. Credit card numbers (PANs) are rendered unreadable or secured with strong cryptography whenever they are sent via end-user messaging technologies. Policies are in place that state that unprotected credit card numbers (PANs) are not to be sent via end-user messaging technologies. Use and update anti-virus softwarerequirement 5: Use and update anti-virus software Anti-virus software is deployed on all systems commonly affected by malicious software. All anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software. The master installation of the anti-virus software is enabled for automatic updates and scans. Automatic updates and periodic scans are enabled. Anti-virus logs are retained at least one year with the last three months immediately available. Upkeep secure systems and applicationsrequirement 6: Upkeep secure systems and applications All system components and software are protected from known vulnerabilities by having the latest vendor-supplied security updates and patches installed. Critical security patches are installed within one month of release. There is a process to identify newly discovered security vulnerabilities, including a risk ranking that is assigned to such vulnerabilities. (At minimum, the most critical, highest risk vulnerabilities should be ranked as "High".) Processes to identify new security vulnerabilities include using outside sources for security vulnerability information. PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 14

15 Restrict access to cardholder datarequirement 7: Restrict access to cardholder data Access rights for all users are restricted to the least privileges necessary to perform their job responsibilities. Privileges assigned to individuals are based on job classification and function (also called "role-based access control"). Documented approval by authorized parties is required that specifies required privileges. Access controls are implemented via an automated access control system. Automated access control systems are in place on all system components with multiple users. Access is restricted based on a user's need to know, and it is set to "deny all" unless specifically allowed. Automated access control systems are configured to enforce privileges assigned to individuals based on job classification and function. Automated access control systems have a default "deny-all" setting. Assign unique IDsRequirement 8: Assign unique IDs All users are assigned a unique ID before allowing them to access system components or cardholder data. In addition to assigning a unique ID, one or more of the following methods are employed to authenticate all users. Something you know, such as a password or passphrase Something you have, such as a token device or smart card Something you are, such as a biometric. All passwords are rendered unreadable during transmission and storage on all system components by using strong cryptography. Users added to your systems are all valid and recognized users. The addition, deletion, and modification of user IDs, credentials, and other identifier objects are managed and controlled only by those with specific authority. User identity is verified before performing password resets on all system components. First-time and reset passwords are set to a unique value for each user on all system components. Each user must change the password immediately after the first use. Access for any terminated users is immediately deactivated or removed on all systems. Inactive user accounts over 90 days old are either removed or disabled on all systems. Authentication procedures and policies are communicated to all users who have access to cardholder data. PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 15

16 Group, shared, or generic accounts and passwords, or other authentication methods are prohibited. User passwords are changed at least every 90 days. A minimum password length of at least seven characters is required. Passwords must contain both numeric and alphabetic characters. An individual must submit a new password that is different from any of the last four passwords he or she has used. Repeated access attempts are limited by temporarily locking out the user ID after no more than six attempts. Once a user account is locked out, the lockout duration is set to a minimum of 30 minutes or until an administrator enables the user ID. Users are logged out if they are idle for more than 15 minutes. All access to any database containing cardholder data is authenticated. All user access to, user queries of, and user actions on the database are through programmatic methods only. User direct access or queries to databases is restricted to database administrators. Application IDs with database access are only able to be used by the applications and not by individual users or other processes. Restrict physical accessrequirement 9: Restrict physical access Appropriate facility entry controls are in place to limit and monitor physical access to systems in the cardholder data environment. Video cameras and/or access-control mechanisms are in place to monitor individual physical access to sensitive areas. Video cameras and/or access-control mechanisms are protected from tampering or disabling. Data collected from video cameras and/or access control mechanisms is reviewed and correlated with other entries, and data is stored for at least three months unless otherwise restricted by law. Physical access to publicly accessible network jacks is restricted, or visitors are escorted at all times in areas with active network jacks. Physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines is restricted. PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 16

17 Processes and procedures for assigning badges to onsite personnel and visitors include the following: Granting new badges Changing access requirements Revoking terminated onsite personnel and expired visitor badges Access to the badge system is limited to authorized personnel. Badges clearly identify visitors and easily distinguish between onsite personnel and visitors. Visitors are authorized before entering areas where cardholder data is processed or maintained. Visitors are given a physical token that identifies the visitors as not onsite personnel. Visitor badges expire. Visitors are asked to surrender the physical token before leaving the facility or upon expiration. A visitor log is in use to record physical access to the facility as well as for computer rooms and data centers where cardholder data is stored or transmitted. The visitor log contains the visitor's name, the firm represented, and the onsite personnel authorizing physical access, and the visitor log is retained for at least three months. Media back-ups are stored in a secure location, preferably in an off-site facility, such as an alternate or backup site, or a commercial storage facility. The media back-up storage location's security is reviewed at least annually. All media is physically secured (including but not limited to computers, removable electronic media, paper receipts, paper reports, and faxes). Strict control is maintained over the internal or external distribution of any kind of media. Controls for maintaining internal and external media include classifying the media so the sensitivity of the data can be determined. Controls for maintaining internal and external media include sending the media by secured courier or other delivery method that can be accurately tracked. Logs are maintained to track all media that is moved from a secured area, and management approval is obtained prior to moving the media (especially when media is distributed to individuals). Strict control is maintained over the storage and accessibility of media. Inventory logs of all media are properly maintained and periodic media inventories are conducted at least annually. All media is destroyed when it is no longer needed for business or legal reasons. PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 17

18 For destruction, hardcopy materials are cross-cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed. For destruction, containers that store information to be destroyed are secured to prevent access to the contents. Cardholder data on electronic media is rendered unrecoverable via a secure wipe program in accordance with industry-accepted standards for secure deletion, or otherwise by physically destroying the media, so that cardholder data cannot be reconstructed. Track access to resources and datarequirement 10: Track access to resources and data A process is in place to trace all access to system components back to individual users. All system components have automated audit trails in place which track any access to cardholder data to individual users. All system components have automated audit trails in place which track any access to cardholder data to individual users with root or administrative privileges. All system components have automated audit trails in place which track any access to all audit logs. All system components have automated audit trails in place which track invalid logical access attempts. All system components have automated audit trails in place which track use of identification and authentication mechanisms. All system components have automated audit trails in place which track initialization of the audit logs. All system components have automated audit trails in place which track creation and deletion of system-level object. Audit trail entries are recorded for all system components and include user identification. Audit trail entries are recorded for all system components and include type of event. Audit trail entries are recorded for all system components and include date and time. Audit trail entries are recorded for all system components and include success or failure indication. Audit trail entries are recorded for all system components and include origin of event. Audit trail entries are recorded for all system components and include identity or name of affected data, system component, or resource. Audit trail entries for all system components include critical system clocks and times which are synchronized through use of time synchronization technology. The technology is kept current. PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 18

19 Only designated central time servers receive time signals from external sources. All critical systems have the correct and consistent time, which is based on International Atomic Time or UTC (Coordinated Universal Time). Designated central time servers communicate with each other to keep accurate time. Other internal servers only receive time from the central time servers. Access to time data is restricted to only personnel with a business need to access time data. Changes to time settings on critical systems are logged, monitored, and reviewed. Time settings are received from specific, industry-accepted time sources. Viewing of audit trails is limited to those with a job-related need. Audit trail files are protected from unauthorized modifications via access control mechanisms, physical segregation, and/or network segregation. Audit trail files are promptly backed up to a centralized log server or media that is difficult to alter. Logs for external-facing technologies are offloaded or copied onto a secure, centralized log server or media on the internal LAN. File-integrity monitoring or change-detection software is used on logs to generate alerts if existing log data is changed. Logs for all system components are reviewed at least daily, and follow-ups to exceptions are required. Audit log retention policies and procedures are in place. Audit trail history is retained for at least one year. Audit logs are available for at least one year and processes are in place to immediately restore at least the last three months' logs for analysis. Maintain a security policyrequirement 12: Maintain a security policy A security policy is established, published, maintained, and disseminated to all relevant personnel. The security policy addresses all PCI DSS requirements. An annual risk assessment process is documented that identifies threats and vulnerabilities. Results are documented in a formal risk assessment. The risk assessment process is performed at least annually. The information security policy is reviewed at least once a year and updated as needed to reflect changes to business objectives or the card holder data environment. PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 19

20 Daily operational security procedures are developed that are consistent with PCI DSS requirements. They include administrative and technical procedures for each of the requirements. Usage policies require users of technologies connected to your card data environment to obtain explicit approval from authorized parties. Usage policies require authentication of users of technologies connected to the credit card data environment. Usage policies list all devices and personnel with access to technologies connected to the credit card data environment. All devices connected to the cardholder data environment are labeled to determine owner, contact information, and purpose. Usage policies define acceptable uses of technologies connected to the card data environment. Usage policies define acceptable network locations for technologies connected to the credit card data environment. Usage policies include a list of company-approved products. Usage policies require automatic disconnect of sessions for remote-access technologies connected to the credit card data environment after a specific period of inactivity. Usage policies require that remote-access technologies for vendors and business partners are only activated when needed, with immediate deactivation after use. The security policy and procedures clearly define information security responsibilities for all personnel. Responsibility for information security is formally assigned to a Chief Security Officer or other security-knowledgeable member of management. An individual or team is formally assigned responsibility for establishing, documenting, and distributing security policies and procedures. An individual or team is formally assigned responsibility for monitoring and analyzing security alerts and information, and distributing to appropriate personnel. An individual or team is formally assigned responsibility for Information security management. This includes establishing, documenting, and distributing security incident response and escalation procedures to ensure timely and effective handling of all situations. An individual or team is formally assigned responsibility for administering user accounts, including additions, deletions, and modifications. An individual or team is formally assigned responsibility for monitoring and controlling all access to data. A formal security awareness program is in place to make all personnel aware of the importance of cardholder data security. PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 20

21 The security awareness program provides multiple methods of communicating awareness and educating personnel. Personnel are educated upon hire and at least annually. Personnel are required to acknowledge at least annually that they have read and understood the security policy and procedures. Personnel are screened prior to being hired to minimize the risk of attacks from internal sources. A list of service providers is maintained. A written agreement is maintained that includes an acknowledgment that the service providers are responsible for the security of cardholder data they possess. There is an established process for engaging service providers, including proper due diligence prior to engagement. Service providers' PCI DSS compliance status is monitored at least annually. An incident response plan has been created and is ready for use in the event of system breach. The incident response plan addresses roles, responsibilities, and communication strategies in the event of a compromise. At a minimum, this plan includes notification of the payment brands. The incident response plan addresses specific incident response procedures. The incident response plan addresses business recovery and continuity procedures. The incident response plan addresses data back-up processes. The incident response plan addresses analysis of legal requirements for reporting compromises. The incident response plan addresses coverage and responses of all critical system components. The incident response plan includes response procedures from the payment brands or references where that information can be found. The incident response plan is tested at least annually. Specific personnel are designated to be available 24 hours a day every day to respond to alerts. Appropriate training is provided to staff assigned to responded to security breaches. Alerts from intrusion-detection, intrusion-prevention, and file-integrity monitoring systems are included in the incident response plan. A process is developed and in place to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments. Shared Hosting Provider RequirementsRequirement Appendix A: Shared Hosting Provider Requirements PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 21

22 Each merchant, service provider, or other company that is within your hosted environment only has access to its own cardholder data environment and each one is required to use a unique ID. Each merchant, service provider, or other company that is within your hosted environment has unique user IDs that are not admin, root or other privileged users. Each merchant, service provider, or other company that is within your hosted environment has read, write, or execute permissions only for files and directories it owns or for necessary system files, which are restricted via file system permissions, access control lists, chroot, jailshell, etc. No customer's users have write access to shared system binaries. Merchants, service providers, and other companies can only view logs that they own. Restrictions are in place for the use of disk space, bandwidth, memory, and CPU. Logging and audit trails are enabled for common third-party applications for each merchant and service provider environment. Logging and audit trails are active by default for each merchant and service provider environment. Logging and audit trails are available for review by the owner of each merchant and service provider environment. Logging and audit trail locations are clearly communicated to the owner of each merchant and service provider environment. Written policies and processes are enabled to provide timely forensic investigation in the event of a compromise to any hosted merchant or service provider. If you are a shared hosting provider, your systems are configured to protect each entity's hosted environment and cardholder data. The assessor is required to thoroughly evaluate compensating controls during each annual PCI DSS assessment to validate that each compensating control adequately addresses the risk the original PCI DSS requirement was designed to address, per items 1-4 above. To maintain compliance, processes and controls must be in place to ensure compensating controls remain effective after the assessment is complete. Appendix C: Compensating Controls WorksheetUse this worksheet to define compensating controls for any requirement where "YES" was checked and compensating controls were mentioned in the "Special" column. Note: Only companies that have undertaken a risk analysis and have legitimate technological or documented business constraints can consider the use of compensating controls to achieve compliance. Requirement Number and Definition: Information Required 1 Constraints List constraints precluding compliance with the original requirement. Explanation 2 Objective Define the objective of the original control; identify the objective met by the compensating control. PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 22

23 Information Required 3 Identified Risk Identify any additional risk posed by the lack of the original control. Explanation 4 Definition of Compensating Controls Define the compensating controls and explain how they address the objectives of the original control and the increased risk, if any. 5 Validation of Compensating Controls Define how the compensating controls were validated and tested. 6 Maintenance Define process and controls in place to maintain compensating controls. Appendix D: Explanation of Non-ApplicabilityIf "" or "Not Applicable" was entered in the "Special" column, use this worksheet to explain why the related requirement is not applicable to your organization. Requirement Reason Requirement is Not Applicable PCI DSS D, v2.0, Attestation of Compliance Copyright 2010 PCI Security Standards Council LLC Page 23