PCI Requirement 8

The Payment Card Industry Security Standards Council (PCI SSC) maintains, evolves, and promotes Payment Card Industry standards for the safety of cardholder data across the globe. The PCI SSC provides technical and operational requirements for organizations accepting or processing payment transactions. The guidance also applies to software developers and manufacturers of applications and devices used in those transactions.

The Payment Card Industry Data Security Standard (PCI DSS) helps entities understand and implement standards for security policies, technologies, and ongoing processes that protect payment systems from breaches and theft of cardholder data. The standards have historically been revised on a 2-3 year cycle, but the PCI SSC is transitioning to a posture of revising the PCI DSS as required based on changes to the current threat landscape. The current standard revision is PCI DSS Version 3.2, released in April 2016. Any organization that handles payment card information must adhere to the PCI DSS and must demonstrate compliance annually. Tenable's Tenable.sc Continuous View (CV) is able to help organizations monitor ongoing PCI DSS compliance by integrating with Tenable Nessus.

The PCI Requirement 8 ARC analyzes policy statements related to the eighth PCI DSS requirement. This requirement mandates that access to system components is identified and authenticated. The requirement seeks to establish accountability and auditability for user activity by requiring that each user be assigned a unique identification. User accountability ensures that actions taken on critical data and systems are performed by, and can be traced to, known and authorized users and processes. Security teams can use this ARC to identify and monitor controls and compliance related to user access in order to meet requirement 8 of PCI DSS.

Organizations can configure repositories or asset lists in order to tailor the focus of the ARC. When the dashboard is added from the Tenable.sc Feed, the appropriate assets, IP addresses, or repositories can be specified. Assigning one of the options to the dashboard will update all filters in the components. By creating static or combination asset lists that include all systems in the Cardholder Data Environment (CDE), each component can be filtered to display results directly related to ongoing PCI security. Using an asset list filter will also allow traffic into and out of the CDE to be monitored. In order to accurately measure an organization’s PCI security posture, asset lists need to be applied as filters to provide results focused on the CDE.

This ARC is available in the Tenable.sc Feed, a comprehensive collection of dashboards, reports, Assurance Report Cards, and assets. The ARC can be easily located in the Tenable.sc Feed under the category Compliance. The ARC requirements are:

• Tenable.sc 5.3.1
• Nessus 8.5.1

Tenable's Tenable.sc provides extensive network and compliance monitoring by leveraging a unique combination of detection, reporting, and pattern recognition utilizing industry recognized algorithms and models. Tenable.sc is continuously updated with plugins to detect and audit system configurations, account settings, and regulatory compliance. Tenable constantly analyzes information from our unique sensors, delivering continuous visibility and critical context and enabling decisive action that transforms the security program from reactive to proactive. Active scanning examines the devices on the network, enabling the verification of account and system configurations. Periodically scanning the network helps prioritize issues related to misconfigurations and noncompliance. Monitoring the network for accounts and systems that to not meet policy or compliance requirements is essential to ongoing security efforts. Tenable’s network monitoring capabilities can check systems for compliance and configuration concerns, enabling ongoing improvements to an organization’s security posture.

This ARC includes the following policy statements:

No password configuration checks failed (8.2): This policy statement displays the number of failed to total password compliance checks. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Password settings may include password length, complexity, and age requirements, among other things. Compliance is measured against those policy checks that reference one or more of the following standards:

• PCI DSS requirement 8.2 (Ensure proper user-authentication management)
• NIST 800-53 control IA-5 (AUTHENTICATOR MANAGEMENT)
• DoD Instruction 8500.2 control IAIA (Individual Identification and Authentication)

No account lockout configuration checks failed (8.1.6, 8.1.7): This policy statement displays the number of failed to total account lockout compliance checks. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Account lockout settings may include failed logon counts and lockout duration requirements, among other things. Compliance is measured against those policy checks that reference one or more of the following standards:

• PCI DSS requirement 8.1.6 (Limit repeated access attempts by locking out the user)
• PCI DSS requirement 8.1.7 (Set the lockout duration)
• NIST 800-53 control AC-7 (UNSUCCESSFUL LOGON ATTEMPTS)
• Center for Internet Security Critical Security Control 16-7 (Account Monitoring and Control: Lockouts)
• DoD Instruction 8500.2 control ECLO (Logon)

No session lock/termination configuration checks failed (8.1.8): This policy statement displays the number of failed to total session lock and termination compliance checks. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Session lock and termination settings may include screen lock and idle time requirements, among other things. Compliance is measured against those policy checks that reference one or more of the following standards:

• PCI DSS requirement 8.1.8 (Idle session requires re-authentication)
• NIST 800-53 control AC-11 (SESSION LOCK)
• NIST 800-53 control AC-12 (SESSION TERMINATION)
• Center for Internet Security Critical Security Control 16-5 (Account Monitoring and Control: Auto logout)
• DoD Instruction 8500.2 control PESL-1 (Screen Lock)

No Windows systems have unused or disabled accounts (8.1.4): This policy statement displays the number of Windows systems that have unused or disabled accounts to total Windows systems. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Unused or disabled accounts are vulnerable to exploitation and should be deleted in order to ensure that they are not used for malicious purposes.

All Windows guest accounts are disabled (8.5): This policy statement displays the ratio of Windows systems with disabled guest user accounts to the total number of Windows systems. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Guest user accounts should be disabled in order to improve security and reduce the risk of compromise. This policy statement helps to identify Windows systems and accounts that may be misconfigured. Systems with enabled guest user accounts should be investigated and reconfigured as necessary.

No Windows systems have accounts that have never logged in or never changed their password (8.2.6): This policy statement displays the ratio of Windows systems with user accounts that have never logged in or never changed their passwords to all Windows systems. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Accounts that have never logged in should be reviewed for necessity, and all accounts should be required to change their password on first login. Accounts that have never changed their password should be disabled or forced to update their password.