Blog
PCI DSS Blog Series – Requirement 2
The Payment Card Industry Data Security Standard (PCI DSS) consists of nearly 400 individual controls, and is a critical part of staying in business for any merchant, service provider, or subservice provider who is involved in handling cardholder data. We find that companies considering PCI are often caught off guard by how comprehensive the PCI DSS is. So, we thought we would help!
CompliancePoint’s PCI blog series will analyze each of the 12 Requirement families. We will outline common challenges our customers face with each requirement, answer some frequently asked questions, and finally, we will provide some pro tips on becoming PCI Certified.
This week we will address Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.
What does this requirement require at a high level?
PCI DSS Requirement Two is all about system hardening. The requirement is intended to ensure that organizations wishing to process payment cards have an implemented process to change the default credentials and configurations on all assets within the organization prior to their deployment into the production environment. This includes all organization 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.
Why is compliance with this requirement important (beyond getting certified)?
Malicious actors are typically very aware of the default credentials utilized by the assets they are attempting to exploit. Therefore, leaving these default accounts and passwords unchanged could allow a system breach.
Common Challenges & Tips for Success:
- As part of the requirement, inventory all hardware and software in scope for PCI DSS. However, it is best practice to do this with the entire organization’s environment.
- In addition to being a requirement of PCI DSS, maintaining an up-to-date inventory of all assets also enables an organization to track, update, and validate patches for all systems more easily. This inventory can also be used to identify scope and respond to incidents quickly.
- This requirement is best satisfied using automated tools. Manually updated inventories are the most likely to have missing equipment and software. Active discovery tools can automatically update the inventory with assets connected to your network, reducing the resources needed to manage this control.
- Remember that Requirement Two does not only apply to passwords. Although the main task associated with this control is changing default passwords, to comply with Requirement Two fully, an organization must also:
- Ensure that the wireless environment and all non-console administrative access support strong encryption and default encryption keys have been changed.
- Disable all default accounts, such as the default administrator and guest accounts on all systems.
- These are the most likely accounts to be targeted during an attack.
- Develop and maintain configuration baselines consistent with accepted industry standards and implement them for all system components prior to deployment in production. This includes preventing misuse and implementing the principle of least functionality (disabling unnecessary services, protocols, etc., and removing scripts, drivers, features, etc.).
- There are automated tools available to apply industry-accepted baseline configurations. Utilizing these automated tools also reduces the cost of resources needed to manage the control.
- Once baselines have been developed, organizations should create an offline image of the system to utilize when needed during recovery operations.
- Ensure that servers only provide a single primary function (including virtual servers).
- As with almost all standards, once you have developed the processes and identified the required controls, you must document them. Maintaining robust policies and operation procedures creates a repeatable process that can be executed even during personnel transitions. Conducting vulnerability scans and penetration tests can help to verify a successful implementation of this requirement. Unnecessary services, protocols, and default passwords are easy targets for penetration testers (just as they are for attackers). If these tests contain these findings, it is not only an indicator that you have to correct the finding, but also an indicator that your process has not been properly implemented. It is important to find the root cause that led to the deficiency so that you can prevent similar issues from occurring in the future.
Common Questions:
- What’s the best standard to use for system configurations?
- Two of the most popular industry standards for creating baseline system configurations include the Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs) and the Center for Internet Security (CIS) Benchmarks. Both provide a standardized, repeatable process and defined set of system configurations that can help organizations harden their assets and protect their data. Both also come with automated tools that can assist with validation and implementation. STIGs were created for the US Government and are intended to meet the requirements that are placed upon those entities. On the other hand, the CIS Benchmarks are targeted at commercial organizations and are more widely used in the private sector.
- It is important to note that you will almost always need to make trade-offs between security and functionality when implementing these standards. Systems must implement a set of minimum control baselines to meet PCI objectives. However, beyond the PCI requirements, there will likely be settings that can detract from system functionality. Organizations must weigh the pros and cons of implementing these more restrictive configurations and make an appropriate business decision that is right for their specific organization.
- What’s the difference between system hardening and patching?
- Although hardening can include patching, there is a significant difference between the two. Security patches are deployed on systems to address security vulnerabilities found in a program. Hardening is a process used to reduce systems’ attack surfaces. Part of reducing the attack surface includes patching known vulnerabilities. However, in addition to patching, hardening can be done by applying the principle of least functionality (removing unneeded programs, accounts, ports, services, permissions, etc.) and configuring the system with more restrictive controls, such as those listed in the DISA STIGS, or CIS Benchmarks mentioned above. To fully comply with the hardening requirements of PCI DSS, an organization must go beyond system patching and demonstrate the documented process and standards they utilize to reduce the attack surface of their system.
- Do all PCI DSS requirements apply to every system component?
- PCI DSS requirements apply to all system components unless it has been verified that a particular requirement is not applicable for a particular system. Decisions about the applicability of PCI DSS requirements should not be based on an organization’s perception of the risk of not implementing the requirement. Organizations may not choose which PCI DSS requirements they want to implement, and risk assessments cannot be used as a means of avoiding or bypassing applicable PCI DSS requirements.
- For example, PCI DSS Requirement 2.1.1 for securing wireless technologies would not apply to a system component that was verified as not having any wireless technology. Similarly, PCI DSS Requirements for secure firewall configurations (Requirements 1.1 – 1.3) apply only to those components performing firewall functions.
Conclusion
PCI DSS is intended to set a baseline of minimum-security controls required to protect cardholder data in transit or at rest. Inventorying the assets within that environment, ensuring that default configurations and passwords have been changed, and implementing baseline industry-accepted configurations that adhere to the principle of least functionality are all important steps in that process. For those considering going down the path of PCI compliance, hardening all assets that will be within the PCI DSS scope is critical.
Check Out Other Posts in this Series
- PCI DSS Requirement 1: Install and maintain a firewall configuration to protect cardholder data
- PCI DSS Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
- PCI DSS Requirement 3: Protect stored cardholder data
- PCI DSS Requirement 4: Encrypt transmission of cardholder data across open, public networks
- PCI DSS Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
- PCI DSS Requirement 6: Develop and maintain secure systems and applications
- PCI DSS Requirement 7: Restrict access to cardholder data by business need to know
- PCI DSS Requirement 8: Identify and authenticate access to system components
- PCI DSS Requirement 9: Restrict physical access to cardholder data
- PCI DSS Requirement 10: Track and monitor all access to network resources and cardholder data
- PCI DSS Requirement 11: Regularly test security systems and processes
- PCI DSS Requirement 12: Maintain a policy that addresses information security for all personnel
CompliancePoint is a Qualified Security Assessor Company (QSAC). Our consultants have decades of experience as practitioners and auditors. Please reach out to us at connect@compliancepoint.com if you have any questions about this requirement or how CompliancePoint can assist your organization with preparing for your PCI DSS Certification.
Finding a credible expert with the appropriate background, expertise, and credentials can be difficult. CompliancePoint is here to help.
