Tuesday, June 23, 2009

PCI DSS Prioritized Webcast Slides and Q&A

It took a while, but here are some fun PCI Q&A from that PCI DSS Prioritized webinar we did a few days ago.

Some questions are way too deep to be answered in a blog post; still, I hope the answers are useful to my readers.

Q: I have a Windows 200X Server and “XYZ Charge” [A.C. - names anonymized] credit card processing software on it; the server is also a domain controller and overall the only server in network, can my network EVER be compliant? PCI DSS speaks of servers not running multiple services such as DNS, Active Directory, etc, on one server. That would mean a small network would need around four servers if they keep cardholder data. What should I do?

A: First, see Myth #6 from the previous webcast. Namely, PCI DSS is not about “compliant networks”; it is about the entire organization. Second, common interpretations of Requirement 2.2.1 do prohibit the use of your DNS server for payment processing. While you might be able to demonstrate compensating controls for other services, combining the actual payment application with public network services is not a good idea.

Q: We have “XYZ DB” as our database and “XYZScan” anti-virus as our security [A.C. - names anonymized]. As a non-profit org. what would be the best route to take to become compliant. Any huge pitfalls to avoid?

A: Obviously, we don’t know your exact situation such as your organization size and the method you use for processing credit cards, it is impossible to give any “authoritative” answer on how to become compliant. However, there is one thing that we can recommend: try not to do ANY card processing “in-house”, but instead outsource as much of it as possible to others who specialize in secure payments. This will limit your exposure to credit card data and thus reduce your risk of BOTH successful hacker attack and PCI non-compliance “assessor attack.” Risks of hosting your own card processing infrastructure are just too high nowadays. As one of my QSA friends once said about card data: “don’t touch that toxic sh*t!”

Q: What systems are in–scope?

A: In brief, systems that “store, process or transmit card data” and those directly connected to them. The PCI DSS document outlines an approach for determining scope; here is an excerpt:


Q: Please help to clarify what “reducing the scope means.” In our scenario we have two main servers that have the databases with credit card information. We are assuming that all computers connected to this network (even through VPN) are required to be PCI DSS compliant. However, would it be acceptable to move these servers to their own network? Does that reduce the scope and what are the most used methods of separating the networks e.g. VLAN, separate firewall segment or zone?

A: “Reducing the scope” means making sure that PCI DSS applies to a smaller part of your organization by limiting where card processing takes place AND by segmenting this part from the rest of the network. The reason for this is that PCI requirements apply to systems that process cards AND the ones connected to them. It is also explained in PCI DSS document. The scope can be reduced by things like:

1. Limiting the number of systems where card data is stored, processed OR even transmitted through

2. Separating such systems from the rest of the network via a firewall, filtering router or something else, described in PCI DSS. Using VLANs for separation seems to be a subject of debate in QSA community; my impression was that it is more often acceptable than not.

In your case, it most likely means moving the card servers to a separate firewall zone and applying the ruleset described in PCI Requirement 1. By the way, why do you have those “databases with card information”? Is there any way to not store the data at all? This will be a perfect example of scope reduction as well.

Q: If I place the database with cardholder data in a separate VLAN or behind a firewall does it reduce the scope? Are the computers outside of that network required to be compliant?

A: If your “database with cardholder data” is separated by the firewall (configured as per PCI DSS Requirement 1!) from the rest of the network, the scope will likely be limited to systems which are in the same firewall zone as the card data database. Computers that are not directly connected to the database due to firewall separation would not be in scope, provided the firewall is configured as per PCI DSS Requirement 1 and thus does indeed separate them. Again, why is there a database with cardholder data? Is there a way to not have such “hacker magnet” database?!

Q: I have heard that some companies require network firewall users to open things on the firewall in order to scan. Why?

A: This stems from the following requirement of “PCI DSS Security Scanning Procedures” [PDF]: “Arrangements must be made to configure the intrusion detection system/intrusion prevention system (IDS/IPS) [A.C. – as well as firewalls] to accept the originating IP address of the ASV. If this is not possible, the scan should be originated in a location that prevents IDS/IPS interference.” While it sounds risky to some, it is NOT “a security crime;” you actually doing this to increase security by letting the scanner assess the vulnerabilities on the exposed systems. It goes without saying that you need to ONLY allows access for the scanner IP addresses and ONLY for a limited time (“scan window”) AND to monitor such network assess, even if you are sure it is coming from your scanning provider.

Q: Is there any specific priority listing for meeting application security (6.3)?

A: “Prioritized Approach for DSS 1.2” document suggests that application security requirements 6.1, 6.2, 6.3 “Develop software applications in accordance with PCI DSS (for example, secure authentication and logging) and based on industry best practices and incorporate information security throughout the software development life cycle.” as well as 6.5 and 6.6 are handled in Phase 3.

Q: Are small businesses subject to the same PCI DSS requirements as large businesses?

A: The requirements are the same for everybody. However, the exact manner in which you accept credit cards does dramatically change the scope of required PCI DSS validation. For example, if you are a “card-not-present (e-commerce or mail/telephone-order) merchant” AND have “all cardholder data functions outsourced” and have overall volume of less than 20,000 transactions/year (Level 4, but depending on the card brand), you only need to answer about 13 question in the Self-Assessment Questionnaire (SAQ). If you process more than 6 million transactions and have your own payment infrastructure, you’d need to pass an actual on-site assessment, covering a broad range of requirements (all 12 requirements with more than 200 sub-requirements)

Q: Where do i get that free PCI eBook you mentioned?

A: “PCI Compliance for Dummies” eBook.

Enjoy! The next webcast will be a lot of fun; watch this blog and your email (if you are on Qualys mailing lists) for announcements.

Possibly related posts:

Dr Anton Chuvakin