In our first tutorial on the PCI security standards, we explored the first requirement of the standard, Install and Maintain a Firewall Configuration to Protect Cardholder Data, part of the Build and Maintain a Secure Network portion of the standard. We reviewed the documentation and configuration of the firewall and router and the standards required to pass this portion of the SAQ. In this section, we explore changing vendor defaults to ensure our networking environment is less prone to hacking.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
There are four sub sections to this requirement. Vendors ship equipment out with default setup configurations and default passwords. This section of the security standard ensures you change the default configuration and default passwords on security and networking equipment.
A couple years ago, I was asked to consult with a medium sized client. Specifically, I was asked to perform penetration testing on the client’s network. During this exercise, I found a load balancer which still had the default vendor password. Since the client’s network was flat with no DMZ, the statistics and reporting section of the web-based management interface gave me insight into the network structure, internal IP scheme, all of the servers in the environment, and a couple of methods to gain access. One of the network administrators had setup an IRC (chat) server through which I was able to gain access to the network. Change those default passwords!
Requirement 2 Security Standard
Requirement 2.1: Are vendor-supplied defaults always changed before installing a system on the network?
Examples include passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts.
2.1.1 (a) Are defaults for wireless environments connected to the cardholder data environment or transmitting cardholder data changed before installing a wireless system?
(b) Are wireless device security settings enabled for strong encryption technology for authentication and transmissions?
We cannot say enough about wireless security! I do not know any statistics to support this, but many of the most publicized credit card hacking cases from recent years have been through insecure wireless networks.
When you install any device on your corporate network, you must ensure that all vendor default strings and passwords are changed including access and administration passwords. If given the opportunity, I also recommend changing the default user names (e.g. change from admin or administrator to something less common). You should also change any default SNMP or management names/strings. Hackers seek out as much information as they can from a networking device and leaving default settings is one method they can gain access. If you do not use SNMP (or for that matter, any of the many services available on these devices), disable the service to reduce the footprint for a hacker to gain access.
There are several methods of wireless device security which is considered secure. WEP and “no security” are not secure access method and should be avoided. As a part of your audit, your wireless security will be tested. Implementing WEP is not a solution and your QSA will not allow you to pass with an insecure wireless protocol implemented in your environment.
Requirement 2.2: (a) Have configuration standards been developed for all system components?
(b) Do these standards address all known security vulnerabilities and are they consistent with industry-accepted system hardening standards—for example, SysAdmin Audit Network Security (SANS), National Institute of Standards Technology (NIST), and Center for Internet Security (CIS)?
(c) Do controls ensure the following?
2.2.1 Is only one primary function implemented per server?
2.2.2 Are all unnecessary and insecure services and protocols disabled (services and protocols not directly needed to perform the device’s specified function)?
2.2.3 Are system security parameters configured to prevent misuse?
2.2.4 Has all unnecessary functionality—such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers—been removed?
In requirement 2.2, PCI is ensuring that proper configuration standards have been developed (read: have been written down and documented) for all system components. It’s a good idea, and considered a best practice, to standardize your configurations as much as possible. You are required to document your configuration standards and if a system component is checked, it must meet the specifications you documented. It’s not good enough to write some best practices documentation and then in reality, find your systems a no where near specs.
These configuration standards must meet some hardening standards such as those from SANS (http://www.sans.org/reading_room/) or NIST (http://csrc.nist.gov/). Server software makers have improved on the process recently and include utilities to lock down many aspects of the server. Even though you may use a wizard, go back and check to ensure it worked correctly and locked down the things required per the hardening specifications from an industry standard source such as SANS or NIST.
Requirement 2.2.1 defines that only one primary function is implemented per server. For example, your mail server should not be your database server. This is a recommended best practice, but in reality it can be limited based on your budget. If you don’t have the budget necessary to separate every function into a separate server, it may not be possible. However, there are some configurations which will need to be corrected to ensure security standards in requirement 1 can be met along with this security requirement.
In requirement 2.2.2, we review whether or not unnecessary services and protocols are disabled on servers. For example, if you are configuring a web server which does not need FTP access, you should disable the FTP service. This is to ensure a hacker does not access your server using an unconfigured or unused service. Early Windows server were notorious for having extra services installed, over time, Microsoft has improved its approach so now you must install just about anything to get have a service functioning in Windows Server. From a security perspective, this is a huge improvement.
Requirement 2.2.3 states that system security parameters must be configured to prevent misuse. The servers and devices on your network should be configured to reduce the chance someone could gain unnecessary access or have unnecessary rights. You should configure each device and machine with least privilege in mind – what are the least rights required for someone to perform their job.
As in requirement 2.2.2, requirement 2.2.4 defines that all unnecessary functionality should be removed from system. For example, if you’re configuring a system as a web server, the default site should be removed and the default admin site (if not required) should be removed. You should also remove the underlying files to ensure someone does not maliciously interact with them.
Requirement 2.3: Is all non-console administrative access encrypted? Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.
Console access to a server is access directly on the machine. Non-console access is remotely via some remote connection technology such as VPN or remote desktop. Requirement 2.3 defines that accessing an administrative console must be performed from a connection which is secure and encrypted. This requirement is for a specific type of remote access – one which your IT staff will need to implement for remote server or machine management.
Requirement 2.4: If you are a shared hosting provider, are your systems configured to protect each entity’s hosted environment and cardholder data?
For most companies, requirement 2.4 will not apply. However, if you are a shared hosting provider, you will need to make each hosted environment secure and separate for cardholder data. A shared hosting provider places several customers on a single machine or cloud of machines. The cardholder data must be secure for each client so one client cannot access another client’s cardholder or sensitive data.
In this section of the self assessment questionnaire (SAQ), we learned that the PCI security standard requires that we change vendor defaults and secure our networking equipment.
