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.1.1 requires, “For wireless environments connected to the cardholder data environment or transmitting cardholder data, change ALL wireless vendor defaults at installation, including but not limited to default wireless encryption keys, passwords, and SNMP community settings.” Complying with PCI Requirement 2.1.1 by changing all wireless vendor defaults is an important part of hardening your wireless network.

Interviewing the responsible personnel and examining supporting policies, procedures, and documentation is the best way to test that your organization has appropriately changed all wireless vendor defaults. The PCI DSS states that your organization needs to verify that:

  • Encryption keys are changed from default at installation
  • Encryption keys are changed any time anyone with knowledge of the keys leaves the company or changes the position
  • Default SNMP community strings are required to be changed upon installation
  • Default passwords on access points are required to be changed upon installation
  • Default SNMP community strings are not used
  • Default passwords on access points are not used
  • Firmware for wireless devices are updated to support secure protocols

The intent behind PCI Requirement 1.2.2 is to prevent hackers from maliciously entering your organization’s wireless environment. The PCI DSS states, “If wireless networks are not implemented with sufficient security configurations (including changing default settings), wireless sniffers can eavesdrop on the traffic, easily capture data and passwords, and easily enter and attack the network.” If your organization does not follow the guidance under PCI Requirement 2.1.1, you are leaving your wireless network open to attackers.

Your assessor should ask for all of the configurations that are associated with the wireless devices and work with you to understand how the infrastructure is organized and how the wireless network and devices play into your environment.

Requirement 2.1.1 within the PCI DSS requires that you change all of the vendor-defaults for the wireless. When you look at the parent requirement, PCI Requirement 2.1, it says that we need to change all of the vendor-defaults, and wireless is no exception to this. If you’re using wireless, and it’s within scope of the PCI DSS, we need to make sure that all of those vendor-defaults have been changed. Secondary to that, we need to make sure that all security-related function and features are enabled and that you’re using secure protocols, ports, and services as part of the authentication. So once again, if you have wireless in scope, you need to change all of those defaults as well.

Your assessor for this particular test should ask for all of the configs that are associated with the wireless devices and, as part of that, work with you to understand how the infrastructure’s laid out, how the wireless plays into your environment, and help identify how to be in compliance with this requirement.

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 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 applies to all default passwords (like those used by operating systems, security service software, payment applications, etc.), accounts, configurations, and NTP information. To test that you have appropriately updated the vendor-supplied defaults, your organization should do a couple of things. First, according to PCI Requirement 2.1, you should attempt to log on to a sample of system components using the vendor-supplied default passwords to verify that every default password has actually been changed. Then, you should do the same process with unnecessary default accounts to ensure they’ve been removed or disabled. It’s important to note that even you do not anticipate using a default account, you need to change the default password of that unnecessary to something unique, and then disable the account. This will prevent a hacker from re-enabling the default account with the default password and leaving your system susceptible to an attack. Your organization should also interview personnel or look at supporting documentation to verify that your organization always changes vendor-supplied defaults.

 

The reason that PCI Requirement 2.1 exists is because vendor-supplied default information is public information. Vendor-supplied default accounts and passwords are not a secret. Hackers know this, and so should you. Try searching “Oracle default passwords” on Google. What comes up? Thousands and thousands of passwords to try. If you can easily find this information, so can a hacker. When hackers come across a platform, application, or environment that they are unfamiliar with, all they need to do is search on Google for whatever technology they’ve encountered. It’s simple for malicious individuals to find the information needed to attack your system; this is why it’s so important for your organization to always change vendor-supplied defaults.

 

The beginning of PCI DSS Requirement 2, specifically PCI DSS 2.1, says that you need to change all of your vendor-defaults. The reason for this is that information is generally made public. I would ask you to spend some time at your PC and Google search “Oracle default passwords.” I was teaching a class one time and I had somebody do that for me. There were 30,000-50,000 hits available. Within the first couple of hits that came up that we looked at, there was probably no less than 1,000 passwords to try.

This information is not a secret, either. Hackers know how to do this as well. When they encounter a specific platform, a specific application, a specific environment that they’re not necessarily familiar with, it’s simple enough for them to Google search “default passwords” for whatever technology they’ve encountered. So when you look to alter that default information, this should include passwords, configurations, and NTP information.

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 focuses on hardening your organization’s systems and assets. We’re here to help you understand that PCI Requirement 2 is not just about your servers, it’s about any asset within your environment. Applications, databases, something your organization has developed, something your organization purchased – all types of assets must be compliant with PCI Requirement 2.

Our PCI Requirement 2 videos will provide you with an overview of these 12 sub-requirements:

  • 2.1: Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.
  • 2.1.1: For wireless environments connected to the cardholder data environment or transmitting cardholder data, change all wireless vendor defaults at installation, including but not limited to default wireless encryption keys, passwords, and SNMP community strings.
  • 2.2: Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
  • 2.2.1: Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server.
  • 2.2.2: Enable only necessary services, protocols, daemons, etc., as required for the function of the system.
  • 2.2.3: Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.
  • 2.2.4: Configure system security parameters to prevent misuse.
  • 2.2.5: Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.
  • 2.3: Encrypt all non-console administrative access using strong cryptography.
  • 2.4: Maintain an inventory of system components that are in scope for PCI DSS.
  • 2.5: 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.
  • 2.6: Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A1: Additional PCI DSS Requirements for Shared Hosting Providers.