system components

PCI DSS Requirement 2 | Vendor Supplied Defaults | Expert Advice

PCI DSS Requirement 2 is the second out of 12 requirements of the PCI DSS initiatives. What’s important to note about PCI DSS Requirement 2 is that it deals largely with removing vendor supplied default password before putting these new system components on the network in the cardholder environment.

Specifically, as stated by the PCI DSS, Requirement 2 is stated in the following:

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Malicious individuals (external and internal to a company) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.

Under this main requirement, which is essentially just a statement, are a number of “tests” that organizations have to undertake for ensuring they meet the demands of PCI DSS Requirement 2.

Many of the tests that are undertaken for PCI DSS Requirement 2 (and for many of the other requirements also) used the phrase “system components” often and often. You need to really understand what this phrase means, and, according to the official PCI DSS wording, “system components” is Any network component, server, or application included in or connected to the cardholder data environment.

You will see the phrase “system components” in Requirement 2 often, so again, understand what it really means. I will be delving much deeper into each of the 12 requirements, but am first giving readers a high level, common understanding of what each requirement actually means and will then circle back in the coming weeks and months.

If you want to learn more about PCI DSS compliance, visit pciassessment.org

PCI DSS Requirement 1.1.2 | Network Diagrams | Easier Said Than Done

PCI DSS Requirement 1.1.2 is an often overlooked area within the PCI framework for assessment. That’s also a shame because it’s such a critical component for helping lay the groundwork for true clarity and transparency for the assessment itself. The problem with most organizations that have network diagrams and topology documents in place is that they are old, outdated, too high-level, void of the necessary detail you need to clearly help understand the cardholder environment for purposes of PCI DSS compliance. A good rule of thumb is to include as much information in the network diagrams and topology documents for helping assess scope and all “system components” that are directly or indirectly related to the storage, transmission, or processing of cardholder data.

Take a look at this comprehensive list I recently put together for a client regarding his network diagram and topology documents. I asked the organization to clearly identify and illustrate these system components in their drawings:

• List of ll IP Addresses in use
• Firewalls
• Demilitarized Zone (DMZ)
• Routers and Switches
• Intrusion Detection Systems (IDS)/Intrusion Prevention Systems (IPS)
• Any enterprise wide applications (CRM systems, etc.)
• Remote Access
• Data transmission methods used for data traversing back and forth on the network
• Wireless Networking or Networks
• Web Servers
• Proxy Servers
• Email Servers
• DNS Servers
• Operating Systems
• Databases
• Applications
• Anti-virus

Quite a list, but then again, it tremendously aids in the overall PCI DSS assessment, not to mention sufficing for PCI DSS Requirement 1.1.2.