Payment Card Industry Data Security Standard (PCI DSS v.2.0)
Requirements to be met by Service Providing Systems
At Indiana University
The following are the requirements from the PCI DSS version 2.0 that must be met by those systems that only provide services to other PCI DSS compliant systems at Indiana University. These systems will be referred to as Service Providing Systems, or Service Systems. Service Systems must never store, transmit, or process cardholder data, and must never come in contact with Primary Account Numbers (PANs). Some requirements may have additional information or detail stricter versions of a requirement that are specific to Indiana University. In addition, at the end of the document some additional requirements that are specific to Indiana University are detailed.
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
1.1. Establish firewall and router configuration standards that include the following:
1.1.1. A formal process for approving and testing all network connections and changes to the firewall and router configurations
IU Specific Detail: All network connection and firewall changes that qualify for the PCI Operations Committee’s Change Management process, must be submitted through that process, as well as any documented process internal to the unit administrating and/or operating the Service System.
1.1.2. Current network diagram with all connections to cardholder data, including any wireless networks
IU Specific Detail: Each unit administrating, and/or operating a Service System must provide and maintain a network diagram detailing all connections to and from a Service System. Accompanying this network diagram will be a spreadsheet detailing each connection detailed in the “IU Specific Detail” section of 1.1.5. These documents will be stored in the administrating and/or operating unit's folder on the SharePoint site. Information on the SharePoint site can be found in the "Additional details and requirements" section below. They both must be updated as part of the unit's change management process at the time the change is implemented.
1.1.3. Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone
IU Specific Detail: All network connected components of a Service System must be inside the PCI VRF, or other approved PCI only network. An exception may be made for laptops used for remote administration on a case by case basis. These laptops must met all other applicable requirements in this document and only connect to hosts inside the PCI VRF, or other approved PCI only network, via a secure VPN connection approved by the PCI Operations Committee.
IU Specific Detail: All network traffic going to a host outside the PCI VRF, or other approved PCI only network, or originating outside the PCI VRF, or other approved PCI only network, going to a host inside the PCI VRF, or other approved PCI only network, must be filtered by the PCI VRF firewall, or in the case of another approved PCI only network, the firewall segregating it from all other networks. Each host is required to have a host-based stateful packet inspecting firewall, that filters all inbound and outbound network traffic, has a default deny policy for both inbound and outbound network connections, and logs both successful and failed connections. The firewall must allow only that traffic that has been documented in the network diagram and companion spreadsheet. Logs must be centrally stored for no less than 90 days active and 9 months archived (for a total retention of at least one year). If a host does not have the capability to have a firewall that meets these requirements, then a hardware firewall or equivalent (reviewed and approved by the PCI Operations Committee) must be placed between such a host and any network it is attached to.
1.1.4. Description of groups, roles, and responsibilities for logical management of network components
1.1.5. Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure. Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet, POP3, IMAP, and SNMP.
IU Specific Detail: Accompanying the network diagram (requirement 1.1.3), will be a spreadsheet detailing each connection including the following information: Connection Number (linking the graphical representation of the connection on the network diagram to this row of the spreadsheet), Source host or group name, source IP address(es) or CIDR notation subnet(s), Destination host or group name, Destination IP address(es) or CIDR notation subnet(s), network protocol, Source port number, Destination port number, short description of network connection, Justification for its use, Comments (to detail any additional information about the connection needed, such as security measures in place for insecure network protocols). This spreadsheet will be a document internal to Indiana University only. Both this spreadsheet and the network diagram will be stored in the administrating, and/or operating unit's folder on the PCI Operations Committee SharePoint site. They both must be updated as part of the unit's change management process at the time the change is implemented. A modified version of the spreadsheet can be made available to external groups if required. The modified version will list the following information: Connections Number (linking the graphical representation of the connection on the network diagram to this row of the spreadsheet), Source port number, Destination port number, short description of network connection, Justification for its use, Comments (to detail any additional information about the connection needed, such as security measures in place for insecure network protocols).
1.1.6. Requirement to review firewall and router rule sets at least every six months
1.2. Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment. Note: An "untrusted network" is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity's ability to control or manage.
1.2.1. Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.
IU Specific Detail: All configurations of components of a PCI DSS compliant system on Indiana University's network must restrict network traffic to only that which is required to fulfill the purpose and scope of that component's service. These includes, but not limited to: Host-based firewall configurations, policies configured on the PCI VRF firewall, web server configurations, and data base configurations. Where possible, both inbound and outbound network traffic must be monitored and restricted.
1.2.2. Secure and synchronize router configuration files.
IU Specific Detail: No unit, with the exception of Indiana University Campus Network Infrastructure, may operate any device that fulfills the role of a router, Network Bridge, or in another way extends the PCI VRF network, or another approved PCI only network. Therefore, although this requirement still applies, it is facilitated and performed by Indiana University Campus Network Infrastructure. This document does not cover the operation of the PCI VRF, or other approved PCI only networks by Indiana University Campus Network Infrastructure.
1.2.3. Install perimeter firewalls between any wireless networks and the cardholder data environment, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.
IU Specific Detail: Wireless networks are not allowed to be directly connected to the PCI VRF in any way.
1.3. Prohibit direct public access between the Internet and any system component in the cardholder data environment.
1.3.1. Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.
IU Specific Detail: All network traffic going to a host outside the PCI VRF or originating outside the PCI VRF going to a host inside the PCI VRF, must be filtered by the PCI VRF firewall. Each host is required to have a host-based stateful packet inspecting firewall, that filters all inbound and outbound network traffic, has a default deny policy for both inbound and outbound network connections, and logs both successful and failed connections. The firewall must only allow that traffic that has been documented in the network diagram and companion spreadsheet. Logs must be centrally stored for no less than 90 days active and 9 months archived (for a total retention of at least one year). If a host does not have the capability to have a firewall that meets these requirements, then a hardware firewall or equivalent (reviewed and approved by the PCI Operations Committee) must be placed in-between such a host and any network it is attached to.
1.3.2. Limit inbound Internet traffic to IP addresses within the DMZ.
1.3.3. Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.
1.3.4. Do not allow internal addresses to pass from the Internet into the DMZ.
1.3.5. Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.
1.3.6. Implement stateful inspection, also known as dynamic packet filtering. (That is, only "established" connections are allowed into the network.)
1.3.7. Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.
IU Specific Detail: No system that has the primary role of providing services to other PCI DSS compliant systems may, in any way, store, transmit, or process cardholder data. Also, they may not come in contact with any PANs in any way.
1.3.8. Do not disclose private IP addresses and routing information to unauthorized parties. Note: Methods to obscure IP addressing may include, but are not limited to: Network Address Translation (NAT), Placing servers containing cardholder data behind proxy servers/firewalls or content caches. Removal or filtering of route advertisements for private networks that employ registered addressing. Internal use of RFC1918 address space instead of registered addresses.
IU Specific Detail: NAT is not supported on the PCI VRF. Network proxy servers are allowed under strict restrictions and requirements. All proxy servers must: log all network traffic that passes through the proxy, make these logs available to the University Information Security Office, and restrict use of the proxy to only specific authorized internal hosts and destinations. All hosts that are system components of PCI DSS complaint systems, must have statically assigned IP addresses. Public IPv4 addresses will be in the external DNS zone, private addresses will be in the internal DNZ zone.
1.4. Install personal firewall software on any mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization’s network.
IU Specific Detail: No employee-owned devices, including but not limited to, desktop computers, laptop computers, netbooks, tablets, phone, or pocket computers may be used to connect to any host inside the PCI VRF for purposes of administration of that host or a service or application running on that host. Only devices owned by Indiana University and designated and configured for use with PCI DSS compliant hosts may be used to connect to any host inside the PCI VRF for purposes of administration of that host or a service or application running on that host. Part of the configuration of any device for use with PCI DSS compliant hosts, must be a correctly configured host-based stateful packet inspecting firewall, that filters all inbound and outbound network traffic, has a default deny policy for both inbound and outbound network connections, and logs both successful and failed connections. The firewall must only allow that traffic that has been documented in the network diagram and companion spreadsheet. Logs must be centrally stored for no less than 90 days active and 9 months archived (for a total retention of at least one year).
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
2.1. Always change vendor-supplied defaults before installing a system on the network, including but not limited to passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts.
2.1.1. For wireless environments connected to the cardholder data environment or transmitting cardholder data, change wireless vendor defaults, including but not limited to default wireless encryption keys, passwords, and SNMP community strings.
IU Specific Detail: Wireless networks are not allowed to be directly connected to the PCI VRF or other network used by PCI DSS compliant systems in any way. The IU Wireless Network is separate from and does not directly provide access to the IU PCI network.
2.2. Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards. Sources of industry-accepted system hardening standards may include, but are not limited to: Center for Internet Security (CIS), International Organization for Standardization (ISO), SysAdmin Audit Network Security (SANS) Institute, National Institute of Standards Technology (NIST)
2.2.1. Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.) Note: Where virtualization technologies are in use, implement only one primary function per virtual system component.
2.2.2. Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system. Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, SSL, or IPsec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.
2.2.3. Configure system security parameters to prevent misuse.
2.2.4. Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.
2.3. Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web- based management and other non- console administrative access.
2.4. Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers.