1 PCI DSS 3.1 Security Policy Purpose This document outlines all of the policy items required by PCI to be compliant with the current PCI DSS 3.1 standard and that it is the University of Northern Colorado s Policy to be compliant with all requirements set forth below. Applies To This Policy applies to all PCI environments within the University of Northern Colorado and to all staff, faculty, and students that operate within or in cooperation with a PCI environment. Definitions CDE Cardholder data environment DSS Data Security Standards PA-DSS Payment Application Data Security Standards PCI Payment Card Industry PAN Primary Account Number SAD Sensitive Authentication Data, includes Full Track Data, PIN/PIN Block, CAV2/CVC2/CVV2/CID Cardholder Data PAN, Cardholder Name, Service Code, Expiration Date Policy UNC commits to the following actions in regard to each section of PCI-DSS version 3.1:
2 Requirement 1: Install and maintain a firewall configuration to protect cardholder data. 1.1 a. A formal process exists for approving and testing all external network connections and changes to the firewall and router configurations. b. UNC will, at all times, maintain a current network diagram for PCI environments. c. Configuration standards include requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone. d. The current network diagram is consistent with the firewall configuration standards. e. Firewall and router configuration standards include a description of groups, roles, and responsibilities for logical management of network components. f. Firewall and router configuration standards include a documented list of services, protocols and ports necessary for business (for example, hypertext transfer protocol (HTTP), Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols). g. All allowed insecure services, protocols, and ports necessary, and are security features documented and implemented for each. h. Firewall and router configuration standards require a review at least every six months. i. Firewall and router rule sets reviewed at least every six months. j. Maintain a current network PCI network diagram for each of the PCI environments. k. Maintain a current dataflow diagram for PCI environments. 1.2 a. Inbound and outbound traffic is restricted to that which is necessary for the cardholder data environment, and the restrictions are documented. b. All other inbound and outbound traffic specifically denied. c. Router configuration files are secure and synchronized. d. Perimeter firewalls are installed between any wireless networks and the cardholder data environment, and are these firewalls configured to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment. 1.3 a. Direct connections are prohibited for inbound or outbound traffic between the Internet and the cardholder data environment. b. Internal addresses are prohibited from passing from the Internet into the PCI environment. c. Outbound traffic from the cardholder data environment to the Internet must be explicitly authorized.
3 d. Stateful inspection, also known as dynamic packet filtering, is implemented (that is, only established connections are allowed into the network). e. 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. f. Methods are in place to prevent the disclosure of private IP addresses and routing information to the Internet. g. Any disclosure of private IP addresses and routing information to external entities requires authorization. 1.4 a. Personal firewall software is installed and active 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. b. The personal firewall software is configured to specific standards, and not alterable by mobile and/or employee owned computer users. Requirement 2: Do not use vendor supplied defaults for system passwords and other security parameters. 2.1 a. Vendor-supplied defaults are always changed before installing a system on the network. b. For the wireless environment encryption keys are changed from default at installation, and changed anytime anyone with knowledge of the keys leaves the company or changes positions. c. Default SNMP community strings on wireless devices are changed. d. Default passwords/passphrases on access points are changed. e. Firmware on wireless devices is updated to support strong encryption for authentication and transmission over wireless networks. f. All other security-related wireless vendor defaults are changed. 2.2 a. Configuration standards are developed for all system components and are they consistent with industry-accepted system hardening standards. b. System configuration standards are updated as new vulnerability issues are identified, as defined in requirement 6.2. c. System configuration standards are applied when new systems are configured. d. Only one primary function is implemented per server, to prevent functions that require different security levels from co-existing on the same server.
4 e. Virtualization technologies are used, and only one primary function is implemented per virtual system component or device. f. Only necessary services, protocols, daemons, etc. are enabled as required for the function of the system. g. All enabled insecure services, daemons, or protocols are justified, and are security features documented and implemented. h. System administrators and/or personnel that configure system components are knowledgeable about common security parameter settings for those system components. i. Common system security parameters settings are included in the system configuration standards. j. Security parameter settings are set appropriately on system components. k. All unnecessary functionality - such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers have been removed. l. Enabled functions are documented and do support a secure configuration. m. Only documented functionalities are present on system components. 2.3 a. All non-console administrative access is encrypted with strong cryptography, and a strong encryption method invoked before the administrator's password is requested. b. System services and parameter files are configured to prevent the use of Telnet and other insecure remote login commands. c. Administrator access to web-based management interfaces are encrypted with strong cryptography. d. All non-console administrative access requires two factor authentication. 2.4 a. An inventory of all system components in the PCI is maintained by each environment owner and reported up to the CISO. 2.5 a. Security policies and operational procedures for managing vendor defaults and other security parameters are documented and used by all parties. Requirement 3: Protect stored cardholder data. 3.1 a. Data retention and disposal policies and procedures are implemented and do they include specific requirements for retention of cardholder data as required for business, legal, and/or regulatory purposes. b. Policies and procedures include provisions for the secure disposal of data when no longer needed for legal, regulatory, or business reasons, including disposal of cardholder data.
5 c. Policies and procedures include coverage for all storage of cardholder data. d. Processes and procedures include: 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. e. All stored cardholder data meets the requirements defined in the data retention policy. 3.2 a. When sensitive authentication data is received and deleted, processes in place to securely delete the data to verify that the data is unrecoverable. The university does not store SAD. b. The full contents of any track from the magnetic stripe (located on the back of a card, equivalent data contained on a chip, or elsewhere) are not stored under any circumstance. c. The card verification code or value (three-digit or four-digit number printed on the front or back of a payment card) is not stored under any circumstance. d. The personal identification number (PIN) or the encrypted PIN block are not stored under any circumstance. 3.3 a. The PAN is masked when displayed (the first six and last four digits are the maximum number of digits to be displayed). 3.4 a. PAN is rendered unreadable anywhere it is stored (including data repositories, portable digital media, backup media, and in audit logs), 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. b. Logical access to encrypted file systems is managed independently of native operating system access control mechanisms. c. Cryptographic keys stored securely. d. Cardholder data on removable media is encrypted wherever stored. 3.5 a. Access to cryptographic keys are restricted to the fewest number of custodians necessary. b. Keys are stored in encrypted format and are key-encrypting keys stored separately from data-encrypting keys. c. Cryptographic keys are stored in the fewest possible locations and forms.
6 3.6 a. Cryptographic key procedures include the generation of strong cryptographic keys. b. Cryptographic key procedures include secure cryptographic key distribution. c. Cryptographic key procedures include secure cryptographic key storage. d. Cryptographic key procedures include cryptographic key changes for keys that have reached the end of their defined cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of ciphertext has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication ). e. Cryptographic key procedures include retirement or replacement (for example, archiving, destruction, and/or revocation) of cryptographic keys when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key). f. Cryptographic key procedures include replacement of known or suspected compromised keys. g. If retired or replaced cryptographic keys are retained, are these keys only used for decryption/verification purposes (not used for encryption operations). h. Cryptographic key procedures include split knowledge and dual control of cryptographic keys (for example, requiring two or three people, each knowing only their own key component, to reconstruct the whole key), for manual clear-text key-management operations. i. Cryptographic key procedures include the prevention of unauthorized substitution of cryptographic keys. j. Cryptographic key custodians required to formally acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities. Requirement 4: Encrypt transmission of cardholder data across open, public networks. 4.1 a. Strong cryptography and security protocols, such as later versions of TLS, SSH or IPSEC, are used to safeguard sensitive cardholder data during transmission over open, public networks. b. Only trusted keys and/or certificates are accepted. c. Security protocols implemented to use only secure configurations, and not to support insecure versions or configurations. d. The proper encryption strength is implemented for the encryption methodology in use (check vendor recommendations/best practices).
7 e. For SSL/TLS implementations: HTTPS appears as part of the browser Universal Record Locator. Cardholder data is required only when HTTPS appears in the URL. f. Industry best practices (for example, IEEE i) are used to implement strong encryption for authentication and transmission for wireless networks transmitting cardholder data or connected to the cardholder data environment. 4.2 a. PANs are rendered unreadable or secured with strong cryptography whenever they are sent via end-user messaging technologies (for example, , instant messaging, or chat). b. Policies are in place that state that unprotected PANs are not to be sent via end-user messaging technologies. Requirement 5: Protect all systems against malware and regularly update anti virus software or programs. 5.1 a. Anti-virus software is deployed on all systems commonly affected by malicious software. b. All anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software (for example, viruses, Trojans, worms, spyware, adware, and rootkits). 5.2 a. The anti-virus policy requires updating of anti-virus software and definitions. b. The master installation of the software is enabled for automatic updates and scans. c. Automatic updates and periodic scans is enabled. d. All anti-virus mechanisms will generate audit logs, and logs are retained in accordance with PCI DSS Requirement a. Anti-virus configurations are actively running on systems required by PCI and have been configured to prevent removal. 5.4 a. Security policies and operational procedures for protecting system against malware are documented and known to all affected parties.
8 Requirement 6: Develop and maintain secure systems and applications. 6.1 a. All system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. b. Critical security patches are installed within one month of release. 6.2 a. A process exists to identify newly discovered security vulnerabilities, including a risk ranking that are assigned to such vulnerabilities. b. A process exists to identify new security vulnerabilities include using outside sources for security vulnerability information. 6.3 a. The software development processes are based on industry standards and/or best practices. b. Information security is included throughout the software development life cycle. c. Software applications are developed in accordance with PCI DSS (for example, secure authentication and logging). d. Custom application accounts, user IDs, and/or passwords are removed before applications become active or are released to customers. e. 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 (per PCI DSS Requirement 6.5). Appropriate corrections are implemented prior to release. Code review results are reviewed and approved by management prior to release. Note: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle. 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 a. Development/test environments are separate from the production environment, and access control is in place to enforce the separation.
9 b. There are separation of duties between personnel assigned to the development/test environments and those assigned to the production environment. c. Production data (live PANs) is not used for testing or development. d. Test data and accounts are removed before production systems become active. e. Change control procedures for implementing security patches and software modifications are documented and require items f. All changes have a documentation of impact. g. All changes are approved by authorized parties. h. All changes are functionality tested to verify that the change does not adversely impact the security of the system. i. Custom code changes, are updates are tested for compliance with PCI DSS Requirement 6.5 before being deployed into production. j. There is a back out procedure for each change. 6.5 a. All applications developed is based on secure coding guidelines. b. Developers are knowledgeable in secure coding techniques. c. Prevention of common coding vulnerabilities are covered in software development processes to ensure that applications are not vulnerable to, at a minimum the following: Injection flaws, particularly SQL injection. Buffer overflow. Insecure cryptographic storage. Insecure communications. Improper error handling. All ""High"" vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.2). Cross-site scripting (XSS). Improper Access Control such as insecure direct object references, failure to restrict URL access, and directory traversal. Cross-site request forgery (CSRF). Broken authentication and session management. 6.6 a. For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis, these applications are protected against known attacks by applying either of the following methods: Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, as follows: At least annually. After any changes by an organization that specializes in application security. That all vulnerabilities are corrected. That the application is re-evaluated after the corrections- or
10 - Installing a web-application layer firewall in front of public-facing web applications to detect and prevent web-based attacks. Requirement 7: Restrict access to cardholder data by business need to know. 7.1 a. Access to system components and cardholder data limited to only those individuals whose jobs require such access, as follows: Access rights for privileged user IDs are restricted to least privileges necessary to perform job responsibilities. Privileges are assigned to individuals based on job classification and function (also called "role-based access control" or RBAC). Documented approval by authorized parties required (in writing or electronically) that specifies required privileges. Access controls implemented via an automated access control system. 7.2 a. An access control system is in place for systems with multiple users to restrict access based on a user s need to know, and is it set to "deny all" unless specifically allowed, as follows: Access control systems is in place on all system components. Access control systems is configured to enforce privileges assigned to individuals based on job classification and function. Access control systems have a default "deny-all" setting. 7.3 a. Ensure that security policies and operational procedures for restricting access to cardholder data are documented, in use, and known by all parties. Requirement 8: Identify and authenticate access to system components. 8.1 a. All users are assigned a unique ID before allowing them to access system components or cardholder data.
11 8.2 a. In addition to assigning a unique ID, is one or more of the following methods 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. Placing servers containing cardholder data behind proxy servers/firewalls or content caches. Something you are, such as a biometric. 8.3 a. Two-factor authentication is incorporated for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties. 8.4 a. All passwords are rendered unreadable during transmission and storage on all system components using strong cryptography. 8.5 a. Proper user identification and authentication management controls are in place for nonconsumer users and administrators on all system components, as follows: Additions, deletions, and modifications of user IDs, credentials, and other identifier objects controlled, such that user IDs are implemented only as authorized (including with specified privileges). User identity is verified before performing password resets for user requests made via a non-face-to-face method (for example, phone, , or web). First-time and reset passwords will set to a unique value for each user, and each user must change their password immediately after the first use. Access for any terminated users is immediately deactivated or removed. Inactive user accounts over 90 days old will either be removed or disabled. Accounts used by vendors for remote access, maintenance or support is enabled only during the time period needed. Vendor remote access accounts is monitored when in use. Authentication procedures and policies is communicated to all users who have access to cardholder data. b. Group, shared, or generic accounts and passwords, or other authentication methods, are prohibited as follows: Generic user IDs and accounts are disabled or removed. Shared user IDs for system administration activities and other critical functions do not exist. Shared and generic user IDs are not used to administer any system components. c. User passwords are changed at least every 90 days. d. A minimum password length of at least seven characters is required. e. Passwords will contain both numeric and alphabetic characters.
12 f. An individual must submit a new password that is different from any of the last four passwords he or she has used. g. Repeated access attempts is limited by locking out the user ID after no more than six attempts. h. Once a user account is locked out, the lockout duration is set to a minimum of 30 minutes or until administrator enables the user ID. i. A session that has been idle for more than 15 minutes, users are required to reauthenticate (for example, re-enter the password) to re-activate the terminal or session. j. All access to any database containing cardholder data is authenticated. k. All user access to, user queries of, and user actions on (for example, move, copy, delete), the database through programmatic methods only (for example, through stored procedures). l. User direct access or queries to databases is restricted to database administrators. m. Application IDs with database access will only be able to be used by the applications (and not by individual users or other processes). 8.6 a. Where other authentication mechanisms are used the following mechanisms must be used: Authentication mechanisms must be assigned to an individual account and not shared across multiple accounts. Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access. 8.7 a. Access to any database containing cardholder data is restricted as per PCI DSS 3.1 requirements. Requirement 9: Restrict physical access to cardholder data. 9.1 a. Appropriate facility entry controls is in place to limit and monitor physical access to systems in the cardholder data environment. b. Video cameras and/or access-control mechanisms are in place to monitor individual physical access to sensitive areas. c. Video cameras and/or access-control mechanisms are protected from tampering or disabling. d. Data collected from video cameras and/or access control mechanisms are reviewed and correlated with other entries, and data is stored for at least three months, unless otherwise restricted by law. e. Physical access to publicly accessible network jacks is restricted. f. Physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines is restricted.
13 9.2 a. Procedures are developed to easily distinguish between onsite personnel and visitors, as follows: 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 will clearly identify visitors and easily distinguish between onsite personnel and visitors. 9.3 a. Visitors is authorized before entering areas where cardholder data is processed or maintained. b. Visitors are given a physical token (for example, a badge or access device) that identifies the visitors as not onsite personnel. c. Visitor badges will expire. d. Visitors are asked to surrender the physical token before leaving the facility or upon expiration. 9.4 a. 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. b. The visitor log contain the visitor's name, the firm represented, and the onsite personnel authorizing physical access, and is the visitor log retained for at least three months. 9.5 a. 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. b. This location's security is reviewed at least annually. 9.6 a. All media is physically secured (including but not limited to computers, removable electronic media, paper receipts, paper reports, and faxes). 9.7 a. Strict control is maintained over the internal or external distribution of any kind of media. b. Controls include the following:
14 Media is classified so the sensitivity of the data can be determined. Media that is sent by secured courier or other delivery method that can be accurately tracked. 9.8 a. Logs are maintained to track all media that is moved from a secured area, and management approval obtained prior to moving the media (especially when media is distributed to individuals). 9.9 a. Strict control is maintained over the storage and accessibility of media. b. Inventory logs of all media properly are maintained and periodic media inventories are conducted at least annually a. Hardcopy materials are cross-cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed. b. Containers that store information to be destroyed are secured to prevent access to the contents. c. Cardholder data on electronic media are rendered unrecoverable via a secure wipe program in accordance with industry-accepted standards for secure deletion, or otherwise by physically destroying the media (for example, degaussing), so that cardholder data cannot be reconstructed. Requirement 10: Track and monitor all access to network resources and cardholder data a. A process is in place to link all access to system components (especially access done with administrative privileges such as root) to each individual user a. Automated audit trails implemented for all system components to reconstruct the following events: All individual user accesses to cardholder data. All actions taken by any individual with root or administrative privileges. Access to all audit trails. Invalid logical access attempts. Use of identification and authentication mechanisms. Initialization of the audit logs.
15 Creation and deletion of system-level object a. Are the following audit trail entries recorded for all system components for each event: User identification. Type of event. Date and time. Success or failure indication. Origination of event. Identity or name of affected data, system component, or resource a. All critical system clocks and times are synchronized through use of time synchronization technology, and is the technology kept current. b. The following controls implemented for acquiring, distributing, and storing time: Only designated central time servers receive time signals from external sources, and all critical systems have the correct and consistent time, based on International Atomic Time or UTC. Designated central time servers peer with each other to keep accurate time, and other internal servers only receive time from the central time servers. c. Time and date are protected as follows: 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. d. Time settings received from specific, industry-accepted time sources a. Audit trails secured so they cannot be altered, as follows: 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 (for example, wireless, firewalls, DNS, mail) offloaded or copied onto a secure, centralized log server or media on the internal LAN. File-integrity monitoring or change-detection software are used on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert) a. Logs for all system components reviewed at least daily, and follow-ups to exceptions are required.
16 10.7 a. Audit log retention policies and procedures are in place and do require that audit trail history is retained for at least one year. b. 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. Requirement 11: Regularly test security systems and processes a. A documented process implemented to detect and identify wireless access points on a quarterly basis. b. The methodology to detect and identify 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. c. The process to identify unauthorized wireless access points is performed at least quarterly for all system components and facilities. d. Automated monitoring is utilized (for example, wireless IDS/IPS, NAC, etc.), monitoring is configured to generate alerts to personnel. e. The Incident Response Plan (Requirement 12.9) includes a response in the event unauthorized wireless devices are detected a. Internal and external network vulnerability scans run 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), as follows: Quarterly internal vulnerability scans are performed. The quarterly internal scan process include rescans until passing results are obtained, or until all "High" vulnerabilities as defined in PCI DSS Requirement 6.2 are resolved. Internal quarterly scans are performed by a qualified internal resource(s) or qualified external third party, and if applicable, does organizational independence of the tester exist (not required to be a QSA or ASV). b. Quarterly external vulnerability scans are performed. c. External quarterly scan results do satisfy the ASV Program Guide requirements (for example, no vulnerabilities rated higher than a 4.0 by the CVSS and no automatic failures). d. Quarterly external vulnerability scans performed by an Approved Scanning Vendor (ASV), are approved by the Payment Card Industry Security Standards Council (PCI SSC).
17 e. 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). f. The scan process include 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 as defined in PCI DSS Requirement 6.2 are resolved. g. Scans are performed by a qualified internal resource(s) or qualified external third party, and if applicable, does organizational independence of the tester exist (not required to be a QSA or ASV) a. External and internal penetration testing is performed at least once a year and after any significant infrastructure or application changes (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment). b. Noted exploitable vulnerabilities are corrected and testing repeated. c. Tests are performed by a qualified internal resource or qualified external third party, and if applicable, does organizational independence of the tester exist (not required to be a QSA or ASV). These penetration tests include the following: Network-layer penetration tests. Application-layer penetration tests a. 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. b. IDS and/or IPS are configured to alert personnel of suspected compromises. c. All intrusion-detection and prevention engines, baselines, and signatures are kept up-todate a. File-integrity monitoring tools are deployed within the cardholder data environment. b. The 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. Requirement 12: Maintain a policy that addresses information security for all personnel a. A security policy is established, published, maintained, and disseminated to all relevant personnel.
18 b. The policy addresses all PCI DSS requirements. c. An annual risk assessment process is documented that identifies threats and vulnerabilities, and results in a formal risk assessment. d. The risk assessment process is performed at least annually. e. The information security policy is reviewed at least once a year and updated as needed to reflect changes to business objectives or the risk environment a. Daily operational security procedures are developed that are consistent with requirements in this specification (for example, user account maintenance procedures, and log review procedures), and do they include administrative and technical procedures for each of the requirements a. Usage policies for critical employee-facing technologies (for example, remote-access technologies, wireless technologies, removable electronic media, laptops, personal data/digital assistants [PDAs], , and Internet usage) are developed to define proper use of these technologies for all employees and contractors. b. Explicit approval by authorized parties to use the technologies is required. c. Authentication for use of the technology is required. d. A list of all such devices and personnel with access is kept. e. Labeling of devices to determine owner, contact information, and purpose is required. f. Acceptable uses of the technologies is required. g. Acceptable network locations for the technologies is required. h. List of company-approved products is required. i. Automatic disconnect of sessions for remote-access technologies after a specific period of inactivity is required. j. Activation of remote-access technologies for vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use is required. k. Personnel accessing cardholder data via remote-access technologies, 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, all require policies. l. For personnel with proper authorization, policy requires the protection of cardholder data in accordance with PCI DSS Requirements a. The security policy and procedures clearly define information security responsibilities for all personnel.
19 12.5 a. Responsibility for information security is formally assigned to a Chief Information Security Officer. b. The following information security management responsibilities are formally assigned to an individual or team: Establishing, documenting, and distributing security policies and procedures. Monitoring and analyzing security alerts and information, and distributing to appropriate personnel. Establishing, documenting, and distributing security incident response and escalation procedures to ensure timely and effective handling of all situations. Administering user accounts, including additions, deletions, and modifications. Monitoring and controlling all access to data a. A formal security awareness program is in place to make all personnel aware of the importance of cardholder data security. b. A formal security awareness program is in place to make all employees aware of the importance of cardholder data security. c. The security awareness program provides multiple methods of communicating awareness and educating personnel. d. Personnel are educated upon hire and at least annually. e. Personnel are required to acknowledge, at least annually, that they have read and understood the security policy and procedures a. Potential personnel (see definition of ""personnel"" at Requirement 12.1, above) are screened prior to hire to minimize the risk of attacks from internal sources a. If cardholder data is shared with service providers, are policies and procedures maintained and implemented to manage service providers, as follows: A list of service providers is maintained. A written agreement is maintained that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess. There is an established process for engaging service providers, including proper due diligence prior to engagement. A program is maintained to monitor service providers' PCI DSS compliance status at least annually.
20 12.9 a. An incident response plan has been implemented in preparation to respond immediately to a system breach, as follows: An incident response plan been created to be implemented in the event of system breach. The plan address, at a minimum: Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands. 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. b. The plan tested at least annually. c. Specific personnel designated to be available on a 24/7 basis to respond to alerts. d. Appropriate training is provided to staff with security breach response responsibilities. e. Alerts from intrusion-detection, intrusion-prevention, and file-integrity monitoring systems are included in the incident response plan. f. A process developed and placed to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments. Revision History Version Published Author Description /06/18 Matt Langford Original publication /06/19 Matt Langford Minor revisions /07/21 Matt Langford Update to DSS 3.1
General Standards for Payment Card Environments at Miami University 1. Install and maintain a firewall configuration to protect cardholder data and its environment Cardholder databases, applications, servers,
Windows Azure PCI Guide January 2014 Version 1.0 Prepared by: Neohapsis, Inc. 217 North Jefferson St., Suite 200 Chicago, IL 60661 New York Chicago Dallas Seattle PCI Guide January 2014 This document contains
Compliance Report PCI DSS 2.0 Generated by Check Point Compliance Blade, on July 02, 2013 11:12 AM 1 74% Compliance 96 Action Items Upcoming 0 items About PCI DSS 2.0 PCI-DSS is a legal obligation mandated
ISO 27001 PCI DSS 2.0 Title Number Requirement 4 Information security management system 4.1 General requirements 4.2 Establishing and managing the ISMS 4.2.1 Establish the ISMS 4.2.1.a 4.2.1.b 4.2.1.b.1
Appendixes Information Technology Standard for PCI systems Syracuse University Information Technology and Services PCI Network Security Standard (Appendix 1) 1.0 Scope All credit card data and its storage
Policy/Procedure Description PCI DSS Policies Install and Maintain a Firewall Configuration to Protect Cardholder Data Establish Firewall and Router Configuration Standards Build a Firewall Configuration
White paper Achieving PCI-Compliance through Cyberoam The Payment Card Industry (PCI) Data Security Standard (DSS) aims to assure cardholders that their card details are safe and secure when their debit
Mapping PCI DSS 3.0 to Instant PCI Policy Below are the requirements from the PCI Data Security Standard, version 3.0. Each requirement is followed by a bullet point that tells exactly where that requirement
Any physical access to devices or data held in an Melbourne datacentre that houses a customer s cardholder data must be controlled and restricted only to approved individuals. PCI DSS Requirements Version
FACT SHEET Technology Innovation Programme The Visa Europe Technology Innovation Programme () was designed to complement the Payment Card Industry (PCI) Data Security Standard (DSS) by reflecting the risk
University of Sunderland Business Assurance PCI Security Policy Document Classification: Public Policy Reference Central Register IG008 Policy Reference Faculty / Service IG 008 Policy Owner Chief Financial
Payment Card Industry (PCI) Data Security Standard is an international information security standard assembled by the Payment Card Industry Security Standards Council (PCI SSC). The standard was created
Payment Card Industry (PCI) Data Security Standard Summary of s from Version 2.0 to 3.0 November 2013 Introduction This document provides a summary of changes from v2.0 to v3.0. Table 1 provides an overview
Payment Card Industry (PCI) Data Security Standard Summary of s from PCI DSS Version 1.2.1 to 2.0 October 2010 General General Throughout Removed specific references to the Glossary as references are generally
Compliance SonicWALL PCI 1.1 Implementation Guide A PCI Implementation Guide for SonicWALL SonicOS Standard In conjunction with ControlCase, LLC (PCI Council Approved Auditor) SonicWall SonicOS Standard
Minnesota State Colleges and Universities System Procedures Chapter 5 Administration Payment Card Industry Technical s Part 1. Purpose. This guideline emphasizes many of the minimum technical requirements
PCI DSS impacts to your company If an organization is involved in the storage, processing or transmission of cardholder data, then it is subject to the requirements of PCI DSS (Payment Card Industry Data
PCI Data Security and Classification Standards Summary Data security should be a key component of all system policies and practices related to payment acceptance and transaction processing. As customers
SecureTrack Supporting Compliance with PCI DSS 2.0 March 2012 www.tufin.com Table of Contents Introduction... 3 The Importance of Network Security Operations... 3 Supporting PCI DSS with Automated Solutions...
Payment Card Industry Data Security Standard Build and Maintain a Secure Network Requirement 1: Requirement 2: Install and maintain a firewall configuration to protect data Do not use vendor-supplied defaults
WHITEPAPER PCI and PA DSS Compliance Assurance PCI and PA DSS Compliance Assurance with LogRhythm MAY 2014 PCI and PA DSS Compliance Assurance with LogRhythm The Payment Card Industry (PCI) Data Security
SAQ D Compliance Scott St. Aubin Senior Security Consultant QSA, CISM, CISSP Ground Rules WARNING: Potential Death by PowerPoint Interaction Get clarification Share your institution s questions, challenges,
Controls for the Credit Card Environment Edit Date: May 17, 2007 Status: Approved in concept by Executive Staff 5/15/07 This document contains policies, standards, and procedures for securing all credit
Did you know your security solution can help with PCI compliance too? High-profile data losses have led to increasingly complex and evolving regulations. Any organization or retailer that accepts payment
Payment Card Industry Data Security Standard Introduction Purpose Audience Implications Sensitive Digital Data Management In an effort to protect credit card information from unauthorized access, disclosure
Credit Card Security Created 16 Apr 2014 Revised 16 Apr 2014 Reviewed 16 Apr 2014 Purpose This policy is intended to ensure customer personal information, particularly credit card information and primary
LogRhythm and PCI Compliance 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
Payment Card Industry (PCI) Data Security Standard Version 1.1 Release: September, 2006 Build and Maintain a Secure Network Requirement 1: Requirement 2: Install and maintain a firewall configuration to
PCI DSS PCI Prioritized DSS Approach for for PCI DSS.0 The Prioritized Approach to Pursue PCI DSS Compliance The Payment Card Industry Data Security Standard (PCI DSS) provides a detailed, 1 requirements
PCI DSS requirements solution mapping The main reason for developing our PCI GRC (Governance, Risk and Compliance) tool is to provide a central repository and baseline for reporting PCI compliance across
Payment Card Industry (PCI) Data Security Standard Version 1.1 Release: September, 2006 Build and Maintain a Secure Network Requirement 1: Requirement 2: Install and maintain a firewall configuration to
Requirement 1: Install and maintain a firewall configuration to protect cardholder data 1.1 Establish and implement firewall and router configuration standards that include the following: 1.1.1 A formal
Category Question Name Question Text C 1.1 Do all users and administrators have a unique ID and password? C 1.1.1 Passwords are required to have ( # of ) characters: 5 or less 6-7 8-9 Answer 10 or more
Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire A-EP and Attestation of Compliance Partially Outsourced E-commerce Merchants Using a Third-Party Website for Payment Processing
Implementation Guide PayLINK Implementation Guide Version 2.1.252 Released September 17, 2013 Copyright 2011-2013, BridgePay Network Solutions, Inc. All rights reserved. The information contained herein
Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire C and Attestation of Compliance Merchants with Payment Application Systems Connected to the Internet No Electronic Cardholder
Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire D and Attestation of Compliance All other SAQ-Eligible Merchants and Service Providers Version 2.0 October 2010 Document
2: Do not use vendor-supplied defaults for system passwords and other security parameters 2.1: Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing
PCI PA - DSS Point BKX Implementation Guide Atos Xenta, Atos Xenteo and Atos Yomani using the Point BKX Payment Core Version 2.01 POINT TRANSACTION SYSTEMS AB Box 92031, 120 06 Stockholm, Tel. +46 8 566
Meeting PCI-DSS v1.2.1 Compliance Requirements By Compliance Research Group Table of Contents Technical Security Controls and PCI DSS Compliance...1 Mapping PCI Requirements to Product Functionality...2
Passing PCI Compliance How to Address the Application Security Mandates The Payment Card Industry Data Security Standards includes several requirements that mandate security at the application layer. These
Achieving PCI DSS Compliance with A White Paper Spring 2010 Summary The Payment Card Industry Data Security Standard (PCI DSS) is a global information security standard defined by the Payment Card Industry
PCI PA - DSS Point ipos Implementation Guide VeriFone Vx820 using the Point ipos Payment Core Version 1.01 POINT TRANSACTION SYSTEMS AB Box 92031, 120 06 Stockholm, Tel. +46 8 566 287 00 www.point.se Page
1. Introduction 1.1. Purpose and Background 1.2. Central Coordinator Contact 1.3. Payment Card Industry Data Security Standards (PCI-DSS) High Level Overview 2. PCI-DSS Guidelines - Division of Responsibilities
NJ Office of Information Technology P.O. Box 212 www.nj.gov/it/ps/ Jon S. Corzine, Governor 300 Riverview Plaza Adel Ebeid, Chief Technology Officer Trenton, NJ 08625-0212 STATE OF NEW JERSEY IT CIRCULAR
Payment Card Industry - Data Security Standard () Security Policy Version 1-0-0 3 rd February 2014 University of Leeds 2014 The intellectual property contained within this publication is the property of
White Paper PCI-DSS compliance and Software products The Payment Card Industry Data Standard () compliance is a set of specific security standards developed by the payment brands* to help promote the adoption
How NETGEAR ProSecure UTM Helps Small Businesses Meet PCI Requirements I n t r o d u c t i o n The Payment Card Industry Data Security Standard (PCI DSS) was developed in 2004 by the PCI Security Standards
www.netforensics.com NETFORENSICS SOLUTION GUIDE Achieving PCI DSS Compliance with Cinxi Compliance with PCI is complex. It forces you to deploy and monitor dozens of security controls and processes. Data
The Comprehensive Guide to PCI Security Standards Compliance Achieving PCI DSS compliance is a process. There are many systems and countless moving parts that all need to come together to keep user payment
- 1. Policy Statement All card processing activities and related technologies must comply with the Payment Card Industry Data Security Standard (PCI-DSS) in its entirety. Card processing activities must
WHITEPAPER Using Automated, Detailed Configuration and Change Reporting to Achieve and Maintain PCI Compliance Part 4 An in-depth look at Payment Card Industry Data Security Standard Requirements 10, 11,
Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 1.2.1 July 2009 Document Changes Date Version Description Pages October 2008 July 2009 1.2 1.2.1
PCI DSS Compliance Guide 2009 Rapid7 PCI DSS Compliance Guide What is the PCI DSS? Negative media coverage, a loss of customer confidence, and the resulting loss in sales can cripple a business. As a result,
PCI 3.0 and Managed Security: How Network Box can help you with PCI compliance COPYRIGHT 2013 NETWORK BOX USA, INC. 1 COPYRIGHT 2013 NETWORK BOX USA, INC. 2825 WILCREST DRIVE, SUITE 259 HOUSTON, TX 77042
PCI Compliance Reporting Solution Brief Automating Regulatory Compliance and IT Best Practices Reporting Automating Compliance Reporting for PCI Data Security Standard version 1.1 The PCI Data Security
for Sage MAS 90 and 200 ERP Credit Card Processing Version 22.214.171.124 and 126.96.36.199 - January 28, 2010 Sage, the Sage logos and the Sage product and service names mentioned herein are registered trademarks
Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire D and Attestation of Compliance All other Merchants and all SAQ-Eligible Service Providers Version 1.2 October 2008 Document
PCI DSS 3.0 Changes Bill Franklin Executive IT Auditor firstname.lastname@example.org January 23, 2014 Agenda Introduction PCI DSS 3.0 Changes What Can I Do to Prepare? When Do I Need to be Compliant? Questions
This document is to be used to verify that a payment application has been validated against Visa U.S.A. Payment Application Best Practices and to create the Report on Validation. Please note that payment
Payment Card Industry Data Security Standard Self-Assessment Questionnaire C-VT Guide Prepared for: University of Tennessee Merchants 12 April 2013 Prepared by: University of Tennessee System Administration
Introduction Manage Engine Desktop Central is part of ManageEngine family that represents entire IT infrastructure with products such as Network monitoring, Helpdesk management, Application management,
How to Complete the Questionnaire The questionnaire is divided into six sections. Each section focuses on a specific area of security, based on the requirements included in the PCI Data Security Standard.
WHITEPAPER Using Automated, Detailed Configuration and Change Reporting to Achieve and Maintain PCI Compliance Part 3 An in-depth look at Payment Card Industry Data Security Standard Requirements 5, 6,
Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire C-VT and Attestation of Compliance Merchants with Web-Based Virtual Payment Terminals No Electronic Cardholder Data Storage
Chapter 84 Information Security Rules for Street Hail Livery Technology System Providers Table of Contents 84-01 Scope of the Chapter... 2 84-02 Definitions Specific to this Chapter... 2 83-03 Information
First Data First Data Market Market Insight Insight Reducing PCI DSS Scope with the TransArmor First Data TransArmor Solution SM Solution Organizations who handle payment card data are obligated to comply
TABLE OF CONTENTS Purpose of this Tool... 2 How to Get the Most Value from this Tool... 2 Build and Maintain a Secure Network Requirement 1: Install and maintain a firewall configuration to protect data...
Enforcing PCI Data Security Standard Compliance Marco Misitano, CISSP, CISA, CISM Business Development Manager Security & VideoSurveillance Cisco Italy 2008 Cisco Systems, Inc. All rights reserved. 1 The
Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire D and Attestation of Compliance All other Merchants and all SAQ-Eligible Service Providers Version 1.1 February 2008 Table
Using the AppGate Network Segmentation Server TO ACHIEVE PCI COMPLIANCE Version 2.0 January 2013 Jamie Bodley-Scott Cryptzone 2012 www.cryptzone.com Page 1 of 12 Contents Preface... 3 PCI DSS - Overview
Payment Card Industry (PCI) Data Security Standard Requirements and Security Assessment Procedures Version 2.0 October 2010 Document Changes Date Version Description Pages October 2008 July 2009 October
Number 5.0 Policy Owner Information Security and Technology Policy Application Development Effective 01/01/2014 Last Revision 12/30/2013 Department of Innovation and Technology 5. Application Development
Catapult PCI Compliance Table of Contents Catapult PCI Compliance...1 Table of Contents...1 Overview Catapult (PCI)...2 Support and Contact Information...2 Dealer Support...2 End User Support...2 Catapult
Section 3.9 PCI DSS Information Security Policy Issued: June 2016 Replaces: January 2015 I. PURPOSE The purpose of this policy is to establish guidelines for processing charges on Payment Cards to protect
Visa Asia Pacific Account Information Security (AIS) Program Payment Application Best Practices (PABP) This document is to be used for payment application vendors to validate that the payment application
ARE YOU REALLY PCI DSS COMPLIANT? Case Studies of PCI DSS Failure! Jeff Foresman, PCI-QSA, CISSP Partner PONDURANCE AGENDA PCI DSS Basics Case Studies of PCI DSS Failure! Common Problems with PCI DSS Compliance
Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire C and Attestation of Compliance Payment Application Connected to Internet, No Electronic Cardholder Data Storage Version
Security Standards Compliance Payment Card Industry Data Security Standard PCI DSS Trend Micro Products (Deep Security and SecureCloud) - Detailed Report Document TMIC-003-PD Version 1.1, 23 August 2012
PCI DSS Quick Reference Guide Understanding the Payment Card Industry Data Security Standard version 3.1 For merchants and other entities involved in payment card processing Contents PCI DSS Quick Reference