QUESTION & ANSWER

PCI DSS Q&A: Answering your questions

By Ed Moyle, Contributor 25 May 2009 | SearchSecurity.com

Security UK Tips and Expert Advice Digg This!     StumbleUpon     Del.icio.us

By policy, our organization does not store any data. Do the workstations that process and send credit card data to our acquirer still need to be segregated from the rest of our network?
Ed Moyle:
I get this question quite often. The requirement applies to any system that stores, processes or transmits credit card information. So, even if there are devices that only transmit the data and don't store it, and are not adequately segmented, your entire network would need to be compliant.

Our company has segmented its payment application to a different environment (including the database for the card data), but this payment application also needs to connect to the Web application's MySQL database on the DMZ. Is this allowed?
Ed Moyle:
I'm not trying to dodge your question, but the answer really depends on what the database stores and what the application is doing with that data. If, for example, the database stores payment information, you're going to run up against requirement 1.3.7, which requires the database to be in an "internal network zone" rather than your DMZ.

If the database doesn't contain data of a sensitive nature, then the primary issue is whether the connectivity into the DMZ breaks your segregation model. Realistically, this is going to depend on the specifics of what you're doing and what other controls you have in place. The guidance provided by the DSS (page 5) in the section on scoping makes it clear that evaluation of particular segmentation methodologies is discretionary.

My advice? If you're going through an assessment, make this one of the first things you discuss with your QSA. Provide a document that outlines your rationale for why you think the segmentation is intact despite the connectivity to the database (provided that you think it is). Your QSA will tell you pretty quickly if he or she doesn't agree.

PCI DSS scope question: Would an application that transfers files from point to point (a file-transfer program) be in scope for PCI DSS if that application can never analyze or process the contents of the files?
Ed Moyle:
Great question! It depends on if you're a merchant building/using the tool or the developer manufacturing it. If you're a merchant and you're using a tool that might or might not transfer credit card data (but you don't necessarily know one way or the other), the scope of the compliance effort would include the tool just as it would include any other component that may be in the payment environment.

On the other hand, if you're a software developer making a general purpose file-transfer tool, the situation is different. Provided the tool is not specifically a payment application (for example, to support the point of sale), then it's going to be your customers that are going to have the burden of compliance. That means the tool might be in scope for their compliance process, in which case they'll probably come to you with questions about security controls. However, the software developer doesn't really have any compliance obligations just because someone else might elect to use the tool for credit card data at some point.

Consider the following process: Payment data is received over the phone, stored on a computer on the corporate network and then sent out to a third party to be processed. Are all computers that touch that one computer now within the scope of PCI?
Ed Moyle:
Once again, keep in mind that segmentation and scoping is a discretionary call on the part of the individual/organization doing the assessment. However, my interpretation of the requirement is that, yes, without segregation the entirety of the network would be in scope. This is because page 5 of the DSS specifically includes all systems connected to the cardholder environment (machines that store/process/transmit data) unless there is segmentation. On the plus side, it should be pretty easy to segment that one system to reduce scope.

Regarding scoping and segmentation, if one system from another network is permitted into the cardholder network, and that system can connect to hundreds of other outside systems, are all those systems in scope?
Ed Moyle:
You really have to use your best judgment here. There's a pretty broad spectrum of what could be going on that effects the scope, given this set of circumstances.

For example, on one end of the spectrum, it could be a tightly controlled system that connects into the cardholder network to perform a specific administrative task and nothing else (to kick off usage reports, for example). You'd have a pretty good argument that this would not break segmentation.

On the other hand, a relatively uncontrolled system connecting to download payment data is a different matter entirely. In that case, you'd be pretty hard-pressed to make a case for how segmentation is preserved.

Think about it this way: The intent isn't to bring every system in scope just by virtue of the fact that some connectivity exists between that network and the CDE. After all, what systems aren't connected in some way to pretty much every other system in the world? But the intent is to protect the payment information from threats on other networks that could potentially get access to the payment network.

Would a frame-relay network service provided by a carrier be considered a public or private network? And how does requirement 12.8 apply? Does the carrier need to accept responsibility for card data in its possession as it passes over its network devices?
Ed Moyle:
I'll preface the first part of the reply by saying that QSAs disagree about the frame-relay question. You can follow the back-and-forth on it by surfing over to pcianswers.com and checking out the threads on what exactly constitutes a public network vs. what doesn't. I can tell you from my own personal experience, I generally consider frame-relay to be a private network (for example, for the purposes of requirement 4, i.e., "open, public networks").

As to the second part of the question: If you're just providing connectivity, you're going to care about PCI, but it's going to be customer driven rather than driven by your own need to comply with the standard. You referenced requirement 12.8, and that's exactly where the drivers are going to come from. Your customers need to comply with 12.8, so they're going to come to you to track your compliance status.

Sure, you provide a pipe -- and it's true that a customer might at some point decide to pour card data down that pipe. But just because someone potentially could transmit cardholder data over it doesn't all of a sudden mean you have to start filling out RoCs.

While standard FTP usage in the payment processing environment isn't typically condoned, would FTP via a VPN tunnel to the destination be PCI compliant?
Ed Moyle:
I would be careful with this one. FTP is specifically mentioned in the test criteria for requirement 2.2.2. So, while you might meet the requirement to protect the data in transit by using a VPN, you're likely to run up against other requirements where FTP could be at issue.

Even if you do everything perfectly and take specific steps for every requirement where it comes up, your QSA is required to sample system configurations. When this happens, he or she will see FTP enabled and (since it's specifically mentioned in the test criteria), will most likely conclude that you're not compliant.

My advice? Avoid it. Especially since it's so easy to implement an alternate solution, such as ssh/sftp or another type of secure transfer solution. Granted, you can't avoid it in every case, but you'll find that keeping it on isn't easy.

Is a quarterly rogue wireless point scan necessary outside of the protected environment, or just inside of the PCI environment or zone?
Ed Moyle:
This is only necessary inside the cardholder data network. Other facilities that are segmented from the cardholder data environment can be scoped out.

A small portion of our organization is a bookstore that accepts credit cards for payment. We run an IBM on an IBM Power System. It has very robust security separating the various functions. The "Understanding the Intent of the Requirements" document from the PCI Security Standards Council website states that requirement 2.2.1 is not intended for mainframes. How do I mark the Self Assessment Questionnaire (SAQ) to reflect this?
Ed Moyle:
First off, "Navigating the PCI SSC -- Understanding the Intent of the Requirements" (.pdf) is a great resource, so I'm glad you brought it up.

Insofar as addressing the issue on the SAQ goes, this requirement gives a lot of people pause. In a virtualized environment, for example, what counts as "per server"? Is it one function per virtual machine, or one function per device? But if you look at why this requirement is in the document you reference, the SSC tells us this requirement is really targeting issues of the "our email server is also our payment server and domain controller" variety.

Similarly, when they say the requirement is for server systems (they say "usually Unix-, Linux-, or Windows-based") and not for mainframe systems, what do you do when your system isn't a mainframe per se, but also doesn't fall into the Unix/Linux/Windows bucket? My view is that, just like virtualization, running logical partitions that are segmented from each other doesn't violate what the council is trying to prevent.

What are the PCI compliance issues involved with an outsourced IDS? Does the provider need to be PCI compliant as would a Web hosting provider?
Ed Moyle:
First of all, you're going to want to make sure the hosting provider implements its service in a way that meets the IDS-specific requirements in the standard (e.g., 11.4, 10.6). That's the No. 1 concern. Additionally, you're going to want to govern them the same way you would any other vendor under 12.8. Keep in mind that in order for the provider to do its job, it's going to need to see a lot of the traffic on your network, which puts it in scope for compliance efforts. So track the provider's status, validate that it is compliant, and play it close to the line when it comes to 12.8.

Other than that, the council deliberately left the door open for flexibility in terms of how firms meet individual requirements. In fact, for some organizations an outsourced IDS can actually provide more security than would be the case if a company ran the IDS itself.

Is it possible for a company to act in a role as a merchant via a compliant service provider's PCI-approved system and also work with customers to provide avenues for payment processing via that same system? Can the company in the merchant role be subject to the compliant service provider's PCI compliance certification if it cannot provide its own certification?
Ed Moyle:
I would caution you to be careful in how you approach this. First of all, by offering processing capability to customers you're putting yourself at the heart of customers' compliance concerns when it comes to requirement 12.8. In other words, customers are going to start knocking at your door expecting you to be compliant with the standard and demanding evidence that you are. Just telling them that you use a compliant service provider probably isn't going to cut it.

Think about it this way: if you were trying to satisfy requirement 12.8 and one of your vendors didn't offer any evidence of compliance as it pertains to its own firm, but instead said it used a compliant service provider, would you buy it? Maybe there are some situations in which this would fly, but a whole lot of folks are going to want to dig deeper. I know I would.

So can you reduce your scope of compliance by outsourcing much of the payment mechanics? If you can really pull yourself out of the store/process/transmit loop, then you can. But I'd approach sharing that relationship with others cautiously. Not that you can't do it, but your customers will expect you to comply with the requirements and be able to demonstrate that you are doing so.

What PCI guidance applies to banks that issue and process cards and run POS terminals?
Ed Moyle:
The PCI DSS applies to all organizations that store, process or transmit cardholder data. So you have to comply. Compliance validation for a bank is much different than for a merchant or service provider (because you're interfacing directly with the card brands), but you do still have to comply.

Can you recommend any tools (free or otherwise) for finding sensitive information (credit cards, SSNs, etc.) on desktops or file shares?
Ed Moyle:
There's a ton of tools that do this. On the freeware side, there's an open source tool called ccsearch from SourceForge.net (full-disclosure that this tool was written by CTG so I have a bias here). You can also find regular expressions on pcianswers.com that can be plugged into grep to do the searching.

On the commercial side, most of the tools that do this are in the DLP (data leak prevention) space. For example, tools like Symantec Corp.'s Vontu, Code Green Networks Inc.'s TrueDLP, McAfee Inc.'s Data Loss Prevention Monitor, and the like, will search for and report on sensitive data of this type.

We recently upgraded our POS machines to truncate the primary account number (PAN) on both the merchant and customer receipts. Do we need to worry about securely storing daily batch totals and merchant copy receipts from POS machines even though they don't contain the full PAN?
Ed Moyle:
No. On page 4 of the standard, it outlines pretty clearly what's in scope and what isn't from a protection and storage perspective. Of course, don't let this stop you from protecting that data for other security reasons.

Requirement 1.2.2 speaks to verifying that router configuration files are secure and synchronized. Could you expand on what this means?
Ed Moyle:
In approaching this one, I find it's useful to break it down into two parts: the "secure" part and the "synchronized" part.

The "secure" part would include traditional hardening and configuration activities: making sure you're running the latest version of the firmware, that you have the router locked down, that you're not still using any vendor default passwords, and so on. If you're not familiar with how to do this, there are some good guides available to walk you through it. The Center for Internet Security (CIS) has tools and guidance on its site, as does the National Security Agency SNAC.

As far as "synchronized" is concerned, the gist is to make sure the router configuration is manageable. Looking at the test procedure for this requirement gives a good idea of the council's intent. It says "Verify [that] … configuration files (used when machines are re-booted), have the same, secure configurations." So to paraphrase, they want you to synchronize a secure configuration across the entire router population; to prevent one off configurations that aren't hardened. For example, if you have a hundred different routers, do they all use a baseline configuration or are they each running a different configuration? If they're all running different configurations, trying to maintain that is challenging (to say the least) and is likely to be less secure. So really, you want to synchronize your known, hardened configuration across all the devices in scope.

If an organization is using a virtual terminal system like PayPal, and accesses it from a computer on company premises, does the desktop computer need to be segregated or isolated from other internal systems in order to keep those other systems outside the scope of PCI DSS?
Ed Moyle:
Not all QSAs agree, but my in my opinion, yes, it should be segregated. The requirement is pretty clear: Any system that stores, processes or transmits cardholder data is in scope, and the only way to reduce scope is through segregation. So because the device transmits the data, you'd need to segregate to reduce scope.

If you're actually using the PayPal virtual terminal product, PayPal offers a free e-book entitled "Disclosure & Payment Compliance: How to Shape Policies That Gain Customer Confidence" (.pdf) that's pretty useful. You have to sign up for PayPal to get it, but it doesn't take long to do so.

I work for a government organization, and it's mandated that any vendor I work with must be PCI compliant. What questions should I be asking potential vendors? How can I verify they are compliant?
Ed Moyle:
First, ask if the vendor has gone through the compliance validation process and if it can show you its RoC. If it won't show you the RoC directly, you could ask to see a copy of its attestation of compliance, which it is required to complete (even if it's just self-assessing using the SaQ).

Is GFI Software's Languard network security scanner considered a network vulnerability scanner that satisfies PCI DSS requirement 11.2?

From a tool perspective, there are a number of different tools -- some free, some commercial -- that you can use to do internal scanning (including the one you reference). But remember that when it comes to external scans, you need to use an approved scanning vendor (ASV). There's a list of approved scanning vendors on the PCI Security Standards Council website.

A consultant helping us with PCI issues related to application development said the encryption key requirements in requirement 3 also apply to SSL private keys. Is this the case?

About the author:
Ed Moyle is currently a manager with CTG's Information Security Solutions practice, providing strategy, consulting, and solutions to clients worldwide as well as a founding partner of SecurityCurve.

Tags: Compliance Regulation and Standard Requirements,  VIEW ALL TAGS

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Compliance Regulation and Standard Requirements PCI DSS requirements still baffling as compliance deadline approaches Make PCI DSS compliance easier by reducing scope, outsourcing data Cloud computing compliance: Exploring data security in the cloud Encryption basics: How asymmetric and symmetric encryption works SIEM systems streamline compliance processes, offer security benefits No major PCI DSS revision expected in 2010 PCI QSAs, certifications to get new scrutiny Tips to achieve PCI compliance PCI DSS requirements: Get ready for stricter enforcement, fines Data Protection Act breach could cost companies 500,000 pounds

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary Basel II  (SearchSecurityUK.com) Code of Connection (CoCo)  (SearchSecurityUK.com) EU Data Protection Directive  (SearchSecurityUK.com) Financial Services Authority  (SearchSecurityUK.com) IFRS (International Financial Reporting Standards)  (SearchSecurityUK.com) UK Identity Cards Act  (SearchSecurityUK.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary