PCI DSS标准性

Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users. 

 

Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data. However, Requirements 8.1, 8.2 and 8.5.8 through 8.5.15 are not intended to apply to user accounts within a point-of-sale payment application that only have access to one card number at a time in order to facilitate a single transaction (such as cashier accounts).

 

8.1 Assign all users a unique ID before allowing them to access system components or cardholder data.

 

8.2 In addition to assigning a unique ID, employ at least one of the following methods 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

 

8.3 Incorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties. (For example, remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; or other technologies that facilitate two-factor authentication.)

 

Note:

Two-factor authentication requires that two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication.

 

8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography.

 

8.5 Ensure proper user identification and authentication management for non-consumer users and administrators on all system components as follows:

 

8.5.1 Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.

 

8.5.2 Verify user identity before performing password resets.

 

8.5.3 Set passwords for first-time use and resets to a unique value for each user and change immediately after the first use.

8.5.4 Immediately revoke access for any terminated users.

 

8.5.5 Remove/disable inactive user accounts at least every 90 days.

 

8.5.6 Enable accounts used by vendors for remote access only during the time period needed. Monitor vendor remote access accounts when in use.

 

8.5.7 Communicate authentication procedures and policies to all users who have access to cardholder data.

 

8.5.8 Do not use group, shared, or generic accounts and passwords, or other authentication methods.

 

8.5.9 Change user passwords at least every 90 days.

 

8.5.10 Require a minimum password length of at least seven characters.

 

8.5.11 Use passwords containing both numeric and alphabetic characters.

 

8.5.12 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.

 

8.5.13 Limit repeated access attempts by locking out the user ID after not more than six attempts.

 

8.5.14 Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.

 

8.5.15 If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

 

8.5.16 Authenticate all access to any database containing cardholder data. This includes access by applications, administrators, and all other users.  Restrict user direct access or queries to databases to database administrators.

Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.

 

10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.

 

10.2 Implement automated audit trails for all system components to reconstruct the following events:

 

10.2.1 All individual accesses to cardholder data

 

10.2.2 All actions taken by any individual with root or administrative privileges

 

10.2.3 Access to all audit trails

 

10.2.4 Invalid logical access attempts

 

10.2 5 Use of identification and authentication mechanisms

 

10.2.6 Initialization of the audit logs

 

10.2.7 Creation and deletion of system-level objects

 

10.3 Record at least the following audit trail entries for all system components for each event:

 

10.3.1 User identification

 

10.3.2 Type of event

 

10.3.3 Date and time

 

10.3.4 Success or failure indication

 

10.3.5 Origination of event

 

10.3.6 Identity or name of affected data, system component, or resource.

 

10.4 Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time. 

 

Note: One example of time synchronization technology is Network Time Protocol (NTP).

 

10.4.1 Critical systems have the correct and consistent time.

 

10.4.2 Time data is protected. 

 

10.4.3 Time settings are received from industry-accepted time sources.

 

10.5 Secure audit trails so they cannot be altered.

 

10.5.1 Limit viewing of audit trails to those with a job-related need.

 

10.5.2 Protect audit trail files from unauthorized modifications.

 

10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter.

 

10.5.4 Write logs for external-facing technologies onto a log server on the internal LAN.

 

10.5.5 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).

 

10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS).

 

Note: Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6.

 

10.7 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).