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

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.
June 30, 2017/by Jeff Wilder
PCI Requirement 2.1 - Always change vendor-supplied defaults

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."
June 30, 2017/by Jeff Wilder
PCI Requirement 2.1.1 - Change all wireless vendor defaults

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.
June 30, 2017/by Jeff Wilder
PCI Requirement 2.2 - Develop configuration standards for all system components

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.
June 30, 2017/by Jeff Wilder
PCI Requirement 2.2.1 - Implement only one primary function per server

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.”
June 30, 2017/by Jeff Wilder
PCI Requirement 2.2.2 - Enable only necessary services, protocols, and daemons

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.
June 30, 2017/by Jeff Wilder
PCI Requirement 2.2.3 - Implement additional security features

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.”
June 30, 2017/by Jeff Wilder
PCI Requirement 2.2.4 - Configure system security parameters to prevent misuse

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.
June 30, 2017/by Jeff Wilder
PCI Requirement 2.2.5 - Remove all unnecessary functionality

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.
June 30, 2017/by Jeff Wilder
PCI Requirement 2.3 - Encryption

PCI Requirement 2.3 – Encryption

Administrative Access and Strong Encryption
PCI Requirement…
June 30, 2017/by Jeff Wilder
PCI Requirement 2.4 - Maintain an inventory of in-scope system components

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.
June 30, 2017/by Jeff Wilder
PCI Requirement 2.5 - Ensure security policies are known to all affected parties

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.
June 30, 2017/by Jeff Wilder
PCI Requirement 2.6 - Shared hosting providers must protect each entity’s hosted environment

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.
June 30, 2017/by Jeff Wilder