PCI DSS Requirement 2 - Apply Secure Configurations to All System Components

Requirement 2 of PCI DSS asks you to set up every system in your card data environment securely before it goes live, and to keep it that way. In practice that means three things: change or remove every vendor default password and account, turn off the services and features you don't need, and write down a configuration standard for each type of system so it gets built the same secure way every time. It covers servers, workstations, routers, firewalls, wireless access points, payment terminals, databases, cloud instances, and the software running on them.

Why do vendor defaults matter so much?

Default passwords are public. Anyone can look up the factory login for a router, a database, or a web control panel in the vendor's own manual, and attackers keep lists of them. Automated tools try these logins against addresses all over the internet, all day long. A device that still has admin/admin, or a database with a blank root password, can be taken over in seconds with no skill at all. The same goes for other defaults: sample files, demo accounts, and setup pages left in place after an install. It is one of the cheapest fixes in the whole standard, and still one of the most common ways in.

What counts as a vendor default?

Anything that came preset from the vendor and is the same on every copy of the product. That includes admin passwords on routers, firewalls, and switches, built-in accounts on operating systems and databases, SNMP community strings like "public" and "private", default wireless network keys, and the admin login on a POS system or payment application. Requirement 2.2.2 says that if you use a vendor default account, you must change its password following the rules in Requirement 8.3.6, and if you don't use it, you must remove or disable it. Requirement 2.3.1 adds that on any wireless network connected to the card data environment or carrying card data, all wireless vendor defaults must be changed at installation, including encryption keys, access point passwords, and SNMP defaults.

What is a configuration standard?

It is a written recipe for building each kind of system securely. Requirement 2.2.1 says these standards must cover all system components, address all known security vulnerabilities, and be consistent with an industry-accepted hardening standard or the vendor's own hardening advice. Common sources are the CIS Benchmarks, NIST guidance, and the hardening guides that vendors like Microsoft and Cisco publish. The standards must be updated when new vulnerabilities come to light, applied whenever a new system is set up, and confirmed in place before or right after the system goes into production. You don't have to write one from scratch. Most small businesses start from a CIS Benchmark and write down where they do things differently, and why.

Which services should be turned off?

Anything the system doesn't need to do its job. Requirement 2.2.4 says only the services, protocols, and functions you need are enabled, and everything else is removed or disabled. A web server doesn't need a print spooler, file sharing, or an FTP service. If you must run something insecure, such as an old protocol a legacy system depends on, Requirement 2.2.5 asks you to document the business reason and the extra security features that reduce the risk. Requirement 2.2.3 also asks you to keep functions with different security needs apart. The simplest way is one main job per server, so your public web server is not also your database server. Where two functions must share a machine, they need to be isolated from each other, or both secured to the level of the more sensitive one.

Does Requirement 2 cover remote administration?

Yes. Requirement 2.2.7 says all non-console administrative access must be encrypted using strong cryptography. Non-console means any admin access that isn't done by sitting at the machine: SSH, Remote Desktop, a web-based control panel, or the management page on a router. Telnet and plain HTTP admin pages don't meet it, because they send the password across the network as readable text. Use SSH, HTTPS with current TLS, or a VPN instead, and keep admin interfaces off the public internet wherever you can.

What else does Requirement 2 ask for?

Requirement 2.1.1 asks for documented security policies and procedures for this requirement, and 2.1.2, added in version 4.0, asks that roles and responsibilities for it are written down, assigned, and understood. Requirement 2.2.6 asks that system security settings are configured to prevent misuse. Requirement 2.3.2 asks you to change wireless encryption keys when someone who knows them leaves the company or the role, and whenever you suspect a key is compromised. If you remember an older version of the standard, the inventory of system components is no longer part of Requirement 2. It moved to Requirement 12.5.1 in version 4.0.

How does an ASV scan help with Requirement 2?

A quarterly external scan under Requirement 11.3.2 sees your systems the way an attacker on the internet does. It can't read your configuration standard, but it does find the things that slip past one: a Telnet or FTP service left running, a database port open to the internet, a router or control panel login that anyone can reach, or an admin page without proper encryption. ServerScan is a PCI Approved Scanning Vendor, and each finding in our reports comes with plain-language guidance on how to fix it. Our guide to common scan failures covers the default-credential and open-port findings in more detail, and the pricing page shows what a plan includes.

Go on to Requirement 3 - Data Protection.

Go back to Requirement 1 - Firewalls.