QUESTION & ANSWER

Tough questions on PCI DSS: Private networks, self-assessment and segmentation

By SearchSecurity.com Staff 01 Apr 2008 | SearchSecurity.com

Security Wire Daily News Digg This!     StumbleUpon     Del.icio.us

How does PCI apply to merchants whose card transactions are conducted via telephone card readers?
Ed Moyle: If an organization has a point-of-sale system that does authorization via dialup to its acquirer, it still must comply with PCI. That being said, keep in mind that only the "cardholder environment" needs to be compliant. In other words, the scope of the "cardholder environment" in retail locations is going to be small (usually just the point of sale terminal and the procedures around the people/processes using it).

Given the limited scope of the cardholder environment in that case, the number of controls that an enterprise will have to address is also much smaller than might otherwise be the case. For example, controls about network segregation, malware prevention, and so on are likely to be largely inapplicable. If you have any questions about the scope of the cardholder environment, don't forget that an organization's QSA or acquirer can offer guidance on setting the appropriate scope.

Ed Moyle

Does PCI compliance require that data transmissions over private networks be encrypted?
Ed Moyle: Not necessarily. Requirement 4 of the PCI DSS requires that data be encrypted over "open, public" networks. For most purposes, this applies to the Internet and not necessarily to internal networks.

There are a few possible "snags" here that should be taken into account. Be aware of stored records that could contain sensitive authentication data or the PAN. While this type of data doesn't need to be encrypted during transmission, there are different requirements if that data is stored. If the data is being sent across the network, make sure that there aren't devices that could keep this type of data in transaction logs.

If our retail organization stores only the last four digits of credit cards at our stores, do we need security measures such as cameras, unique login IDs, etc., to be PCI compliant?

Yes, most likely. Keep in mind that whether the data is stored isn't the only factor. The determination of whether companies need to comply is made based on whether they "store, process or transmit" card information. If card information is being processed or transmitted – even if none of it is stored – that organization still needs to comply. If a corporation needs to comply, it must address all the areas of the standard for the scope of the cardholder environment; this includes all the physical security requirements (e.g. cameras) as well as the technical requirements (IDs).

If our retail organization stores only the last four digits of credit cards at our stores, do we need security measures such as cameras, unique login IDs, etc., to be PCI compliant?
Ed Moyle: Yes, most likely. Keep in mind that whether the data is stored isn't the only factor. The determination of whether companies need to comply is made based on whether they "store, process or transmit" card information. If card information is being processed or transmitted – even if none of it is stored – that organization still needs to comply. If a corporation needs to comply, it must address all the areas of the standard for the scope of the cardholder environment; this includes all the physical security requirements (e.g. cameras) as well as the technical requirements (IDs).

Is a private network over a public domain between two datacenters PCI compliant?
Ed Moyle: Yes and no. For the purposes of Requirement 4 ("encrypt transmission of cardholder data across open, public networks"), a VPN between two data centers over a public network counts. In fact, VPN is a perfect example of how to address Requirement 4. However, as always, keep in mind that organizations also need to adhere to all the other requirements as well – for example, making sure that the network is protected by a firewall (Requirement 1) and that VPN devices are configured appropriately (e.g. as per Requirement 2). So, for Requirement 4, yes – but actions need to taken to ensure all the other requirements are met as well.

A new version of the PCI self-assessment questionnaire was recently released, and some of the questions specifically mention that the scope is the cardholder data environment, while others do not. For example, question 1.3.9 specifically asks about personal firewall software on any mobile and employee-owned computers with direct access to the Internet that are used to access the organization's network. In this instance, it's not clear if the organization's network is the entire network or just the cardholder data scoped network. How do you treat these types of questions as a QSA? Do you typically limit the scope to the cardholder data environment?
Ed Moyle: I do limit assessments to the cardholder environment. If I come across a security issue in a system that's not part of the cardholder environment, I'll point it out to the organization informally (since it's better that they know about it rather than not), but I won't include that issue as a factor for compliance/noncompliance for the purposes of the RoC.

That being said, I hear where you're coming from on 1.3.9. I interpret the scope of this (and some of the other requirements that look like they have universal applicability) in light of the scoping guidance given by the standards council in the audit procedures (it is page five of the "PCI Audit Procedures 1.1.") In there, they're pretty clear that the scope of compliance validation only applies to the cardholder environment, and that segregation of other systems limits the scope provided the segregation is properly applied.

Our organization, which is based in Canada, is implementing a mobile POS system. What kind of PCI certification or validation do we need?
Ed Moyle: If you are a merchant/service provider implementing someone else's product, it would depend on the volume of transactions set by the supported card brands and/or your acquirer. If the threshold for compliance validation is met, all merchants/service providers have to go through the assessment process.

Now, if you are authoring the product, my advice to you would be to take a serious look at the PA-DSS (formerly known as the "Payment Application Best Practices" or PABP). In this case, adhering to the requirements and ensuring that your product is ready for compliance to support your clients.

Can you clarify the types of data that PCI is intended to cover? Exactly what data must be protected? Does the standard cover personal information like names, addressees, phone numbers, etc., that are not associated with actual card numbers?
Ed Moyle: For PCI version 1.1, the full list of the data that is considered "cardholder data" is provided in matrix format on page two of the standard documentation, which can be downloaded from the PCI Security Standards Council. The standard acknowledges that other personally identifiable information (PII) such as addresses or phone numbers are covered by other regulations (state breach disclosure laws), but the PCI DSS itself only applies to systems that store, process or transmit the PAN.

Our network is not segmented, but the cardholder data environment is separated from the rest of the environment by a firewall. What is the network scope?
Ed Moyle: There are a number of factors that influence this, but in most cases, provided that it's configured like most firewalls (e.g., that the rules are robust and that the firewall is deployed for the purposes of logically segregating the networks), the firewall separating the rest of the network from the cardholder data environment could be used as a justification for reduced scope. That being said, an organization's QSA must agree that the firewall is sufficient to reduce scope.

If there are questions about whether your particular situation is sufficient to reduce scope, a good guide to answer questions about scoping is on page five of the PCI auditing requirements, which is available on the PCI Security Standards Council website, as well as your QSA and/or acquirer.

For more information: Richard Mackey explains why the ISO 27002 can help organizations comply with PCI DSS and provide more structure to an overall enterprise compliance program. Mike Rothman highlights the biggest compliance mistakes seen in the information security industry, and offers advice on how your company can learn from them. Stephen Cobb examines Visa's Payment Application Best Practices and how businesses may soon have to update their strategies to remain PCI compliant.

If a company has international subsidiaries, how should it determine its applicable merchant levels? Could an organization be level one in the U.S. but level four in Canada and Mexico?
Ed Moyle: The best person to answer this question is an acquirer. There are a number of factors that affect how this will apply in an organization's particular circumstance, and acquirers will have all the information at their disposal to make sure that the organization accounts for them all. The card brands do have levels that they define for merchants, but these are defined per organization. An acquirer has a vested interest in making sure that the enterprise toes the appropriate line given its size, transaction volume and particular set of circumstances.

When did the internal audit team option for self-assessment become a viable alternative to a third-party assessment?
Ed Moyle: The self-assessment applies only to the compliance validation requirement (i.e., the assessment that culminates in the creation of the RoC,) and not to any of the requirements that specifically require a third party, such as the quarterly scanning requirement. It's important to recognize that because while a corporation can (provided it is a Level 1 merchant) choose to use internal audits to prepare the RoC, it cannot use internal resources for the requirements that specifically require an external party.

As far as the history, the self-assessment provision for Level 1 merchants has been in place since "the beginning" (PCI version 1.0), but it's not all that common in practice. It is provided to give the largest merchants an option for assessment in the event that the scope of the assessment would be prohibitively expensive to the organization. This was a concern among the largest merchants when the standard was introduced. Remember too that the acquirer has to agree; if an organization intends to do this, it should make sure it meets the requirements and gets buy-in from its acquirer.

Could you provide detail on how the Verified by Visa program works? Is verification confirmed through tests, auditors, or related means?
Ed Moyle: The Verified by Visa (VbV) program is a technical program designed to: a) limit cardholder data that is handled by the merchant during an online authorization, and b) allow for more robust authentication of the cardholder during the checkout process.

The way that Verified by Visa typically works is that a secure channel with the "issuing member" (card issuer) is established between the cardholder's PC and the issuer during the checkout process. This allows the issuer to implement robust authentication of the cardholder prior to allowing the transaction to proceed. For example, the issuer could require that the cardholder authenticate with a biometric or certificate. It could also implement a robust password. All of this can be done in a manner that's relatively non-intrusive to the checkout process. While there are security benefits to using VbV, use of this technology is not required for compliance with PCI.

Tags: PCI Data Security Standard,  VIEW ALL TAGS

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT PCI Data Security Standard Chip and PIN adoption Chip and PIN adoption serves lesson for U.S. payment industry Heartland CIO is critical of First Data's credit card tokenization plan Heartland CIO on end-to-end encryption, credit card tokenization Heartland CIO on PCI, E3 project Wireless network guidelines for PCI DSS compliance Visa probes tokens, encryption for PCI card data protection Feds push cybersecurity jobs, PCI DSS changes ahead. Voltage, RSA spar over tokenization, data protection Experts, vendors search for PCI's holy grail

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary PCI DSS (Payment Card Industry Data Security Standard )  (SearchSecurity.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