Payment Card Industry Data Security Standard
In January 2005, VISA and MasterCard aligned their respective merchant security programs, Card Holder Information Security (CISP) and Site Data protection (SDP) to create a new common industry requirement for information security. The new standard is known as the Payment Card Industry (PCI) Data Security Standard. Additional payment card brands were added to the updated standard. PCI defines a standard of due care for securing cardholder data, wherever it is located. PCI compliance has been required of all entities storing, processing, or transmitting cardholder data. Members must comply with PCI and are responsible for ensuring the compliance of their merchants and Agents—whether they support Issuing or Acquiring activity—for all payment channels, including retail (brick-and-mortar), mail/telephone-order, and e-commerce.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.
Hackers (external and internal to a company) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known in hacker communities and easily determined via public information.
2.1 Always change the vendor-supplied defaults before you install a system on the network (for example, passwords, Simple Network Management Protocol [SNMP] community strings, and elimination of unnecessary accounts).
2.1.1 For wireless environments, change wireless vendor defaults, including but not limited to, Wireless Equivalent Privacy (WEP) keys, default Service Set Identifier (SSID), passwords, and SNMP community strings, and disabling of SSID broadcasts.
Enable Wi-Fi Protected Access (WPA) technology for encryption and authentication when WPA-capable.
2.2 Develop configuration standards for all system components. Make sure these standards address all known security vulnerabilities and industry best practices.
2.2.1 Implement only one primary function per server (for example, Web servers, database servers, and DNS should be implemented on separate servers).
2.2.2 Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the devices’ specified function).
Requirement 6: Develop and maintain secure systems and applications
Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed via vendor security patches, and all systems should have current software patches to protect against exploitation by employees, external hackers, and viruses. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.
6.1 Ensure that all system components and software have the latest vendor-supplied security patches.
6.1.1 Install relevant security patches within one month of release.
6.2 Establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the Internet). Update your standards to address new vulnerability issues.
6.3 Develop software applications based on industry best practices and include information security throughout the software development life cycle. Include the following:
6.3.1 Testing of all security patches and system and software configuration changes before deployment.
Requirement 11: Regularly test security systems and processes
Vulnerabilities are continually being discovered by hackers/researchers and introduced by new software. Systems, processes, and custom software should be tested frequently to ensure security is maintained over time and through changes.
11.1 Test security controls, limitations, network connections, and restrictions routinely to make sure they can adequately identify or stop any unauthorized access attempts. Where wireless technology is deployed, use a wireless analyzer periodically to identify all wireless devices in use.
11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (for example, new system component installations)
