PCI DSS Requirements 1 and 2

Questions about PCI DSS Requirements 1 and 2? You’ve come to the right place.

As you may know, AISN is a PCI compliant cloud hosting provider. Today. we’re fortunate to reprint highlights from an exclusive online interview sponsored by our valued partner, KirkpatrickPrice. In this interview, KirkpatrickPrice Information Security Auditor Barry Williams responded to some frequently asked questions about PCI Data Security Standard Requirements 1 and 2 and common compliance gaps. His specialized expertise fosters some clarity on the robust information security standard. Below are highlights:

Q: What are some of the serious consequences you have seen or heard about regarding inaccurate PCI scoping?

The most critical thing we run across, is there is no scoping. Often times, I find the network is flat and there is no segmentation of the network to separate the cardholder data environment from the rest of the network. The cardholder data environment (CDE) consists of all devices and applications that store, process, or transmit cardholder data. The scope should be determined by a good data flow diagram, showing the flow of the cardholder data. From there, you should be able to see where you can logically segment the data from the rest of the network.

Another issue that is common regarding scope, is oftentimes, the scope of a PCI assessment extends beyond the CDE. Any system connected to the CDE is also in scope. Applications, domain controllers, third-party SaaS providers, managed service providers — anyone who manages any part of your environment should also be PCI compliant.

Q: What does “no access” mean for PCI purposes?

It means “not in-scope of the assessment”. This brings up the need for access controls procedures, having a data control policy that documents and defines those procedures and restricts access to cardholder data by business need-to-know. The principle of least privilege with role-based access, and access approval, should be a clear, unambiguous policy.

Q: What are the most common gaps you see in Requirement 1: install and maintain a firewall configuration to protect cardholder data?

Mostly, I see a lack of policies and procedures, mismanaged scope, lack of a detailed data flow. All of these things must be clearly and fully documented. There have to be clearly documented description of groups, roles, and responsibilities for managing network components. 1.1.5 states that all duties need to be formally defined and documented, and if they’re not, you’re not PCI compliant.

Q: My firewalls are managed by an outside IT consultant. What requirements relate to their aspect of our environment?

A lot of times, you’ll get pushback from service providers, because they don’t think they’re directly involved in the storing, transmitting, or processing of cardholder data. If this company manages your firewall, they must be PCI compliant. They should provide you with an attestation stating they are compliant with the PCI standard. The new requirement for service providers says, they must acknowledge in writing that they will maintain all applicable PCI DSS requirements that pertain to them.

Q: In general, what constitutes an untrusted network?

The Internet. Also, your DMZ in your environment is also an untrusted network. Attackers are looking for your cardholder database. It should not be stored in your DMZ (web servers, DNS servers, email servers). Your DMZ should be considered an untrusted network and segmented from the rest of the network.

Q: I’m using wireless networks but only to administer my CDE. Are those networks in scope?

Yes. They are part of the “connected to”, so all wireless requirements apply. 1.1.2 – should be on network diagram. 1.2.3 – a firewall between wireless networks and the CDE. 2.2.1 – secure wireless configurations. 4.1.1 – strong encryption for authentication and transmission. 11.1 – ongoing testing for unmanaged wireless threats.

Q: What does the DSS mean by “public access”?

The DSS is trying to avoid direct contact with system components. This means, if your device has a publicly accessible IP address, then anyone on the internet can communicate directly with that device.

Q: If a client has Outlook Web Access enabled for Exchange, and they use NAT on the firewall to make it available to access their account from the Internet, does this break requirements 1.3.1 and 1.3.2?

You must isolate the CDE from the Exchange server in your DMZ or you’re not compliant. If the Exchange server is officially isolated so it can’t impact the security – in any way – of your CDE, you’re okay. This is where the firewall would come into play, to segment the DMZ from the rest of the network.

Q: What does PCI mean by “unauthorized outbound traffic” in requirement 1.3.5?

According to the standard, all traffic – both inbound and outbound – must be accounted for. Requirement 1.1.6 requires documenting all services, protocols, and ports that are required for the CDE to operate correctly. Firewall configurations should only allow traffic that is specifically authorized, and this applies in both directions. In our experience, this is one of the biggest challenges with having an overly expansive scope. These controls are often so restrictive, that employees are negatively impacted when we apply the DSS to wide swaths of the business. We encourage all of our customers to take a good look at how they might be able to reduce their PCI scope and segment their network as much as possible.

Q: What methods do most companies use to obscure private/internal IP addresses?

Use of network address translation/IP masquerading is a simple method in which the source and/or destination addresses of IP packets are rewritten as they pass through a router or a firewall.

Q: Do you have any comments regarding documentation? Policies and procedures seem to be a big deal in the DSS.

The phrase “known to all affected parties” is found throughout the PCI requirements. The idea is that policies and procedures need to be documented and disseminated to all appropriate personnel. This applies to all security policies and procedures.

Q: In 2.1, what are the most commonly overlooked systems that fall into this requirement?

Sometimes systems are overlooked. This applies to all default passwords for operating systems, software that provides security services, application and system accounts, point of sale terminals, etc. Don’t only change the passwords, but also ID names.

Q: What is an industry accepted hardening standard?

A hardening standard is used to help minimize security vulnerabilities. This is done by removing all unnecessary and non-essential software programs and utilities. Good standards would include NIST, SANS, and CIS (Center for Internet Security).

Q: One of the most common challenges we encounter on our PCI assessments is weak asset management. What are the most common ways companies maintain an inventory? How does a QSA verify it’s accurate during an audit?

I always look for 4 critical components when observing a clients’ asset inventory. These are host name, description of the primary function of the device, hardware model, and software components running on the hardware. These are the most critical components to have on your inventory list.

Q: What are the common gaps when “ensuring,” as stated in 2.5?

Compliance has to be achieved and then operationalized. Policies have to be documented and disseminated to all appropriate personnel.

Q: 2.6 is critical as many companies utilize third-party cloud providers. What do companies find most challenging in meeting the requirements for shared hosting environments?

Appendix A goes into some detail here regarding additional requirements for shared hosting providers. The key point to remember here is that hosting providers must protect the environment of each of their clients, according to all the controls you find in Appendix A. The simplification of your PCI compliance can be achieved by using a shared hosting provider who already has an issued PCI Report on Compliance (RoC).

Would you like to ask our auditors more specific questions? Email Sarah Morris at s.morris@kirkpatrickprice.com.

Looking for a PCI compliant hosting partner? Email Bill Peters at bill.peters@aisn.net.