PCI Requirement 2
Do Not Use Vendor-Supplied Defaults
Welcome to PCI Requirement 2. Did you know that vendor-supplied default information, such as account names and passwords, pose a serious threat to your organization’s security? Yes, vendor-supplied defaults might make installation or even support easier, but they also make it pretty simple for hackers to find the information needed to attack and exploit your system. How can we prevent this?
PCI Requirement 2 was created to help organizations fight hackers who try to compromise systems with vendor-supplied default information. In these videos, you will learn strategies for changing vendor-supplied defaults, implementing industry-accepted hardening standards, removing all unnecessary functionality, maintaining an inventory of your system components, and more. Click on a video below to get started with PCI Requirement 2.
Introduction to PCI Requirement 2
What is PCI Requirement 2? PCI Requirement 2 mandates, “Do not use vendor-supplied defaults for system passwords and other security parameters.” Were you aware that vendor-supplied default passwords and settings are well-known among the hacker community? PCI Requirement 2 was created to fight the malicious individuals who try to compromise systems with the vendor-supplied default information.
PCI Requirement 2.1 – Always Change Vendor-Supplied Defaults
Why should you change vendor-supplied defaults? Vendor-supplied accounts and passwords pose a serious threat to your organization's security. Although defaults might make installation or even support easier, PCI Requirement 2.1 instructs service organizations to always change vendor-supplied defaults because it is pretty simple for hackers to find the vendor-supplied information needed to attack and exploit your system. PCI Requirement 2.1 states, “Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network."
PCI Requirement 2.1.1 – Change all Wireless Vendor Defaults
Hardening Your Wireless Network - Similar to the parent requirement, PCI Requirement 2.1, PCI Requirement 2.1.1 focuses on changing vendor-supplied defaults. PCI Requirement 2.1.1, though, relates to all wireless environments. If you’re using a wireless network or device that’s within scope of the PCI DSS, you must ensure that you change all wireless vendor defaults upon installation. You must also ensure that all security-related functions and features are enabled and that you are using secure protocols, ports, and services as part of the authentication.
PCI Requirement 2.2 – Develop configuration standards for all system components
PCI Requirement 2.2 ensures that organizations configure their systems to fix security vulnerabilities. There are two parts that need to be completed in order to comply with PCI Requirement 2.2. First, PCI Requirement 2.2 directs organizations to, “Develop configuration standards for all system components.” Your hardening and configuration standards do not only apply to your servers; they extend to your organization’s applications, databases, and workstations as well.
PCI Requirement 2.2.1 – Implement Only One Primary Function Per Server
PCI Requirement 2.2.1 is another requirement focusing on hardening standards. PCI Requirement 2.2.1 states, “Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. Where virtualization technologies are in use, implement only one primary function per virtual system component.”
PCI Requirement 2.2.2 – Enable Only Necessary Services, Protocols and Daemons
We believe that the PCI DSS, or really any information security framework, boils down to a simple philosophy: if you do not need it or it is not required, get rid of it. PCI Requirement 2.2.2 directly correlates to this methodology. It directs, “Enable only necessary services, protocols, daemons, etc, as required for the function of the system.” Your business should be aware that some services and protocols are regularly used by hackers to compromise an organization’s network.
PCI Requirement 2.2.3 – Implement Additional Security Features
Under PCI Requirement 2, which focuses on hardening your organization’s systems and assets, we find PCI Requirement 2.2.3. PCI Requirement 2 is not just about your servers, it’s about any asset within your environment. PCI Requirement 2.2.3 is also about all types of assets within your environment. PCI Requirement 2.2.3 instructs, “Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.”
PCI Requirement 2.2.4 – Configure System Security Parameters to Prevent Misuse
There are two parts to compliance with PCI Requirement 2.2.4. First, the technical part: your organization’s system configuration standards and hardening guidelines should discuss security settings that have known security implications for each type of system in use. Assessors will need to examine the configuration standards as part of this assessment, to ensure that common security parameter settings are included.
PCI Requirement 2.2.5 – Remove all Unnecessary Functionality
PCI Requirement 2.2.5 states, “Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file system, and unnecessary web servers.” Unnecessary functions are yet another way that hackers could gain access to your system, so if a function is not needed, it needs to be shut off. The PCI DSS says that, “By removing all unnecessary functionality, organizations can focus on securing the functions that are required and reduce the risk that unknown functions will be exploited.” PCI Requirement 2.2.5 is not just focused on servers; it applies to means protocols, ports, services, applications, databases, etc.
PCI Requirement 2.3 – Encryption
Administrative Access and Strong Encryption
PCI Requirement…
PCI Requirement…
PCI Requirement 2.4 – Maintain an Inventory of In-Scope System Components
We believe that if management is not aware of an asset, it’s probably not appropriately protected. Based on PCI Requirement 2.4, we think the PCI Security Standards Council and major card brands believe this as well. PCI Requirement 2.4 states, “Maintain an inventory of system components that are in scope for PCI DSS.” In order to comply with PCI Requirement 2.4, your organization must maintain a list of the assets in your environment.
PCI Requirement 2.5 – Ensure Security Policies Are Known to All Affected Parties
PCI DSS Requirement 2.5 address one of the most important aspects of the assessment. It directs, “Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.” If vendor defaults and other security measures are not continuously managed, it’s harder to prevent insecure configurations; this is why security policies and procedures must be documented, in use, and known to all affected parties.
PCI Requirement 2.6 – Shared Hosting Providers Must Protect Each Entity’s Hosted Environment
What is a Shared Hosting Provider? PCI Requirement 2.6 exists to protect hosting environments. When multiple clients’ data is all on the same server, the security of the server often becomes susceptible to vulnerabilities. For example, one client could create insecure functions, but because the data is under the control of a single environment, the other clients’ data would also become compromised.
