Rethinking Default Credentials Testing

When it comes to PCI DSS compliance, one of the critical requirements to address is the hardening of systems to prevent unauthorised access and protect sensitive cardholder data. Under Requirement 2 of PCI DSS (v3.2.1), the focus is on system hardening.  The requirement is intended to ensure that organisations wishing to process payment cards have an implemented process to change the default credentials and configurations on all relevant assets within the organisation prior to their deployment into the production environment. This includes assets such as operating systems, software that provides security services, application and system accounts, POS terminals, wireless access points, Simple Network Management Protocol (SNMP) community strings, etc. At Data Protection People, we’ve encountered an intriguing debate surrounding the testing methodology for this requirement, which we’d like to share with you in this blog.

During a recent review of a client’s Self-Assessment Questionnaires (SAQs), we delved into the subject of Requirement 2.1. This requirement involves ensuring that default credentials and unnecessary default accounts are modified and removed or disabled on all relevant assets before they are introduced into the production environment. Our client used Tenable.io to test system components for default credentials, prompting an internal discussion within our Qualified Security Assessor (QSA) team about the acceptability of this method.

Digging into the Testing Procedure

The client employs Tenable.io for its capability to continuously scan for default credentials, deeming it a valuable tool for continuous monitoring. While most documents we’ve reviewed outline the testing procedure as an assessor’s attempt to sign into devices and apps using default credentials (like “admin” for both username and password) based on vendor guidelines and online resources. The PCI DSS v3.2.1, requirement 2.1 defined a standard testing procedure as: “Choose a sample of system components, and with a system administrator’s help, try logging into devices and applications using default vendor-supplied accounts and passwords.”  However, the updated PCI DSS v4.0 (the requirement has been moved to 2.2.2.b) and states, “examine vendor documentation and observe a system administrator logging on using vendor default accounts to verify accounts are implemented in accordance with all elements specified in this requirement”.  The main focus of this requirement is to ensure that system components remain inaccessible with default accounts.

A Shift in Emphasis and Considerations

While the use of automated tools like Tenable.io might offer operational efficiency for monitoring, it doesn’t necessarily translate to outright compliance satisfaction. Our assessment suggests that relying solely on such tools would require additional checks and balances:

1. Risk Assessment: Organisations should conduct a risk assessment before employing automated systems for testing default credentials. This assessment should be documented and periodically reviewed.
2. Evidence of Testing: When this requirement comes up for assessment, evidence of actual default credentials scanning should be presented. An audit trail of previous tests, scan outcomes, and an inventory of tested items are crucial.
3. Library Accuracy: The library of default credentials within the system should be comprehensive, accurate, and up-to-date. This library must be cross-referenced with vendor documentation.
4. New Asset Integration: Organisations must ensure that any newly introduced assets are added to the credential scanning library and that the automated scan works effectively on these new items.

Assessor’s Role and Recommendations

Utilising an application for vendor default scanning might be an acceptable method for operational purposes and it may also align with the spirit of the requirement given the right checks and balances. However, this doesn’t absolve assessors from thoroughly scrutinising the methodology’s reliability. Instead,  the assessor’s testing emphasis would likely shift towards evaluating the effectiveness and reliability of the testing method.

Collaboration and Discussion

Before implementing an auto-credential scanning approach, it’s advisable to engage with your acquirer and discuss the strategy. Consider the points outlined above to ensure that while you embrace operational efficiency, you’re not compromising the rigor required for PCI DSS compliance.

At Data Protection People, our team boasts three Qualified Security Assessors who can provide a wide range of support services to assist you in navigating the complex landscape of PCI DSS and data protection. Don’t hesitate to reach out for guidance tailored to your specific needs.

Written collaboratively by Phil Brining and Kenechi Obetta