Always change vendor-supplied defaults before installing a system on the network—for example, include passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts.
Implement only one primary function per server.
Disable all unnecessary and insecure services and protocols (services and protocols not directly needed to perform the device’s specified function).
Configure system security parameters to prevent misuse.
Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.
Encrypt all non-console administrative access. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.
Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) by using any of the following approaches:
§ One-way hashes based on strong cryptography
§ Truncation
§ Index tokens and pads (pads must be securely stored)
§ Strong cryptography with associated key-management processes and procedures
The MINIMUM account information that must be rendered unreadable is the PAN.
If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms (for example, by not using local user account databases). Decryption keys must not be tied to user accounts. [1]
Verify that cryptographic keys are stored securely (for example, stored on removable media that is adequately protected with strong access controls).[5]
Verify that cardholder data on removable media is encrypted wherever stored. [5]
Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse:
Restrict access to cryptographic keys to the fewest number of custodians necessary.
Store cryptographic keys securely in the fewest possible locations and forms.
Generation of strong cryptographic keys
Secure cryptographic key distribution
Secure cryptographic key storage
Periodic cryptographic key changes
– As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically
– At least annually
Retirement or replacement of old or suspected compromised cryptographic keys
Split knowledge and establishment of dual control of cryptographic keys.
Prevention of unauthorized substitution of cryptographic keys
Use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks.
Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release.[2]
Establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the Internet). Update configuration standards as required by PCI DSS Requirement 2.2 to address new vulnerability issues.[2]
Verify that processes to identify new security vulnerabilities include using outside sources for security vulnerability information and updating the system configuration standards reviewed in Requirement 2.2 as new vulnerability issues are found.[2][5]
Limit access to system components and cardholder data to only those individuals whose job requires such access. Access limitations must include the following:
Restriction of access rights to privileged user IDs to least privileges necessary to perform job responsibilities [3]
Assignment of privileges is based on individual personnel’s job classification and function [3]
Implementation of an automated access control system
Assign all users a unique ID before allowing them to access system components or cardholder data.
In addition to assigning a unique ID, employ at least one of the following methods to authenticate all users:
§ Password or passphrase
§ Two-factor authentication (for example, token devices, smart cards, biometrics, or public keys
Ensure proper user authentication and password management for non-consumer users and administrators on all system components as follows:
Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.
Verify user identity before performing password resets.
Immediately revoke access for any terminated users.
Enable accounts used by vendors for remote maintenance only during the time period needed.
Require a minimum password length of at least seven characters.
Use passwords containing both numeric and alphabetic characters.
Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used.
Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.
Implement automated audit trails for all system components to reconstruct the following events:
All actions taken by any individual with root or administrative privileges
Invalid logical access attempts
Creation and deletion of system-level objects
Record at least the following audit trail entries 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
Synchronize all critical system clocks and times.
Secure audit trails so they cannot be altered.
Limit viewing of audit trails to those with a job-related need.
Protect audit trail files from unauthorized modifications.
Promptly back up audit trail files to a centralized log server or media that is difficult to alter.
Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).
Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from back-up).
[1] Logical access control is used even though disk encryption is not used.
[2] Server General provides a security update service (comes bundled with the solution).
[3] Server General solutions use RBAC
[4] Smart-cards are used for two factor authentication as well as for key management.
[5] In order to clarify the mandate, the language of this mandate has been substituted by the corresponding “test procedure” recommended by the PCI council.
[6] Server General doesn’t store the encryption key anywhere.
[7] Server General uses soft tokens.
Note#1: The red characters indicate a strong match between a built-in product feature and a PCI mandate.
Note#2: The broad headings “7.1”, “8.5”, “10.2”, “10.3” are listed without check marks, because the sub-mandates of each heading are intended to address the directives accordingly.