The Zeroth Step: Urgent Remediation

Before we get into the meat of the series, let me emphasize the importance of taking a risk-prioritized approach from day one.  Compliance should not be your motivation.  Iron-clad protection of sensitive cardholder data should be your goal.  Compliance will follow naturally… eventually.  The subtext here is that while you develop your compliance strategy, high-risk activities should be identified and addressed immediately.

We recommend scheduling interviews with representatives from each line of business that owns a merchant account, as soon as possible.  This may be difficult if you don’t already have your cross-functional team assembled and if no one other than you knows anything about PCI compliance, yet.  But the bad guys may already be rattling the doorknobs on your systems, and there should be a sense of urgency about getting the base knowledge and the minimum number of pieces in place to make effective interviews happen sooner, rather than later.  Remember, “just because you’re paranoid, doesn’t mean they’re not out to get you.”

You have three goals with these interviews.  First, you want to be reasonably certain that nothing insane is going on, security-wise.  Second, you want to establish a rapport with the merchant account owner to promote cooperation going forward.  Third, you want to gather the information you need to complete your initial inventory of payment card-related activity.

When you approach the merchant account owner, recognize that this is the beginning of a new kind of partnership with this person.  Tell them that the organization’s ability to continue to process credit cards is contingent upon validating compliance with a new set of security standards. (Well, they’re new to you, right?)  Ask to meet with them to tell them about the new standards and to talk about the organization’s strategy for helping them confirm and maintain compliance.  Let them know that you are trying to determine the scope of “our” (vs. “their”) compliance gaps, and ask them who on their staff can talk to you about the business processes related to their merchant account, from end-to-end.  Let them know that you also will need access to the person responsible for the technologies associated with the merchant account.

By now, they’re scared (which can manifest itself as reticence, irritability, etc.), so you need to minimize the FUD factor.  That is, at least try to address the fear, uncertainty, and doubt that your initial contact inevitably generated.  You can do this upfront by sending a preliminary questionnaire ahead of the meeting.  (We’ll post a sample.)  Tell them that you just want them to know what to expect.

It is possible—and if your organization has hundreds of merchant accounts or if your business is distributed geographically it may be necessary—to do this initial inventory exclusively through a questionnaire.  But having a pair of boots on the ground serves two important purposes.  First, it puts you face-to-face with your new partner, and second it helps you gain a better sense about whether or not the situation is reasonably secure.

Going into this meeting, you will be well served if you can bring a business-process lead and a technical lead (preferably an information security specialist).  Establish with your superiors in advance the process by which any untoward findings will be escalated or addressed.  Depending upon your organization’s structure, it may be appropriate to include legal counsel in this process, which may afford some protection if attorney client privilege pertains to your findings.  At any rate, your organization needs to be prepared to take steps—perhaps painful steps—to address risky activities or, worse still, if a system is found to be compromised.

Coming out of this meeting, you will have minimal (not minimum) documentation of business processes and technologies in use.  You will have introduced the merchant account owner to the PCI Data Security Standard as an ongoing concern.  The account owner also will be aware that this is an initial inventory of the organization’s card processing environment, and that meeting the full set of requirements will involve more substantial effort.  Ideally, you have articulated the next step that pertains to the account owner and a general time frame for when that step should occur.   More likely, your plan is still forming.  In that case, keep the next action high-level.  Tell the account owner that the initial inventory will inform your planning of a more appropriate gap analysis and that you will keep them apprised of your progress.

• Merchants will not be required to validate PCI compliance, but they are still subject to the requirements of PCI DSS. If you have a breach and are found to be non-compliant, you will still be subject to the normal fines and sanctions.


• The fine print states that 75% of transactions have to be processed through chip enabled terminals. It does not specify any requirement that transactions actually use the chip-and-PIN technology. This is good news for merchants, as they are not responsible for driving the transactions, only enabling them.


• To be eligible, terminals must support both contact and contactless transactions, including mobile NFC transactions.

According to Ellen Richey, chief enterprise risk officer at Visa, “The migration to chip technology will be an important security layer and a critical step in a comprehensive strategy to use dynamic authentication across all markets and all channels.”

Overall, this is a great move forward for PCI. While the true benefits will only accrue to merchants who process a large number of card-present transactions and are willing to invest in capital equipment upgrades, the philosophical statement made here is significant. Like the release of SAQs A, B, C and D several years ago, this marks a move toward reducing the compliance burden on merchants who take steps to reduce their risk profile.

What do you think? Share your thoughts in the comments section below!

It Begins…

So you’ve gotten a letter or a call or a visit from your merchant bank.  They’ve told you about this PCI Compliance thing-a-ma-bob, and now you’re preparing to explain it to the next level up.  What do you tell them?

Whatever it is, you need to be prepared to respond to the following questions: What are we expected to do?  How much is it going to cost?   How long will it take?  Should we bring in a QSA?  (I’m just kidding: they’ve never heard of a QSA.)  Is this mandatory?*  Are you sure?  Who says?  OK then, shouldn’t this be owned by [insert any other department!]?

Or maybe it was your boss who brought PCI compliance into your world.  Chances are s/he didn’t bring this compliance challenge neatly packaged and topped with a bow.  S/he had similar questions to those above, and your first monumental task is just getting your arms around this thing.

Well, get ready.  In the first stage of your effort, you’ll need to educate yourself, your superiors, and their counterparts in relevant departments (which probably haven’t been identified, yet); create a sense of shared ownership; establish executive sponsorship; develop a road map for achieving compliance; secure cross-functional resource commitments; and find ways to tackle high-risk activities despite business impact.  Oh, and you’ll need to do this while continuing your other duties (at least until it becomes clear to everyone that this is a full-time job).

Don’t worry.  It’s all cake from there…

A Road Map for Building a Road Map

The good news is that you aren’t covering new ground here.  The PCI Security Standards Council provides many useful resources, including their own guide to getting started and an even more useful approach to pursuing recommended compliance priorities†.  Our guide doesn’t depart from the PCI SSC advice.   But where the PCI SSC guides help you understand what you need to do, this series attempts to help you decide how to go about it.  Moreover, the PCI SSC (perhaps appropriately) provides no guidance on how to overcome the organizational inertia that one inevitably faces on such pervasive change management projects.  We do, though your mileage may vary.

In the course of this series, we will describe each of these steps, many of which must be pursued in parallel:

Program Initialization
0. Urgent remediation.
1. Educate yourself on PCI and your organization.
2. Create a sense of shared ownership.
3. Establish executive sponsorship and governance structures.

Compliance Attainment
4. Inventory the merchant card processing environment and conduct a gap analysis
5. Develop a phased (prioritized) remediation plan.
6. Create project plans and secure cross-functional resources by phase.

Compliance Maintenance
7. Revise governance.
8. Establish compliance monitoring
9. Reporting.

* A variation might be, “What will happen if we just ignore it?”
† This guide is accompanied by this Excel tool for pursuing this prioritized approach.

We have a secure web page that is server out from a secure PCI server. Can this be served out in a new browser window or embedded as a frame? Does the URL need to be displayed to prove it is secure (e.g. https://….)?

That’s a good question, Gareth. The PCI DSS standard doesn’t speak to whether your webpage must be “obviously secure” to your customers. If the server publishing the page is operating within the confines of the standard and you are following the encryption requirements of PCI DSS Section 4.1, you are probably in good shape as far as the regulation goes.

That said, you should also think about this from a marketing perspective.

Consumers are savvy and many have been well-trained to look for the signs of a secure website before entering sensitive information. If you embed your secure content within a page that contains insecure content, it defeats the mechanisms users are trained to spot. As you point out, you won’t have “https” at the beginning of your URL and you won’t have the “lock at the bottom of the screen” that users expect to see on a secure site.

I would suggest that you avoid these activities to make sure that your site is not only secure, but that it also gives the appearance of being secure. After all, perception is reality!

Are network switches in the Cardholder Data Environment in scope for PCI DSS? We are having trouble with this one. We have a vlan that run campus wide that transmits card data back to our servers. Are all the switches that carry this vlan in scope? If so how can we test changes to this network. We can’t afford another network infrustructure just for PCI. Any guidance you can provide would be great. Also, keep up the good work with your site. Its very helpful to newbs like me.

That’s a great question, David, and it’s the subject of a lot of debate within the PCI DSS community.

Virtual LANs (VLANs)

First, a little background on the technology David references. Virtual LANs, or VLANs, are a networking technology that allows you to span broadcast domains across multiple switches. Basically, you can make it appear to hosts as if they are on the same local network when they are actually geographically separate. In addition, you prevent hosts connected to the same switch, but placed on a different VLAN, from observing the traffic associated with hosts on that VLAN.

VLANs provide some security protection against eavesdropping, but an entire class of attacks, known as VLAN hopping attacks exist that allow an intruder to skip from one VLAN to another. The key idea to remember is that VLANs are intended to isolate hosts, but not to provide security protection.

VLANs and PCI DSS Compliance

Many organizations are tempted to use VLANs to reduce the scope of their cardholder data environment because they’re easy to implement and don’t require the purchase of any additional gear. Furthermore, the standard itself is quite vague on this issue and leaves much discretion to the QSA. Here’s what PCI DSS says about the matter:

If network segmentation is in place and being used to reduce the scope of the PCI DSS assessment, the assessor must verify that the segmentation is adequate to reduce the scope of the assessment. At a high level, adequate network segmentation isolates systems that store, process, or transmit cardholder data from those that do not. However, the adequacy of a specific implementation of network segmentation is highly variable and dependent upon a number of factors, such as a given network’s configuration, the technologies deployed, and other controls that may be implemented.

Most QSAs that I know interpret this to mean that the use of VLANs alone is not an acceptable way to segment your cardholder data environment from your public networks. At a minimum, you will need to place a firewall to control traffic between the VLANs. The bottom line is that you should tread very carefully here. If you’re going to try to use VLANs as a security control, your switch fabric will definitely fall in scope for PCI DSS compliance. You should not attempt to do this without first obtaining a written opinion from your QSA.

Encryption Instead of VLANs?

One common practice we’ve seen is to use encryption as a substitute. As you may be aware, the standard does allow the use of strong encryption to transmit cardholder data across an open, public network. In the cases where you have card processing devices geographically distant from your servers, why not treat the intervening network as an open, public network?

A great way to do this is to purchase inexpensive firewall devices and place them in front of your card processing systems. You can then use those devices to establish a VPN connection back to your data center. Both firewalls (and everything behind them) are then in scope for PCI DSS compliance, but the network in between is not.

VLANs and Wireless Networks

It’s important to make a specific note about VLANs, PCI DSS compliance and wireless networks, because the PCI Security Standards Council takes care to highlight the added risk of wireless networks. Specifically, they say:

Relying on Virtual LAN (VLAN) based segmentation alone is not sufficient. For example, having the CDE on one VLAN and the WLAN on a separate VLAN does not adequately segment the WLAN and take it out of PCI DSS scope. VLANs were designed for managing large LANs efficiently. As such, a hacker can hop across VLANs using several known techniques if adequate access controls between VLANs are not in place.

So, if you’re deploying a wireless network, make sure to pay added attention to the security controls segmenting your cardholder environment from your public networks.

Background from PCI DSS

The standard intentionally draws a distinction here between employees and vendors/business partners, creating different requirements for each category of remote access user.  The idea is that you would normally allow system administrators and other employees who need ad hoc access to cardholder systems to connect on an as needed basis.  Allowing this same unrestricted access privilege to vendors and business partners exposes your network to an unacceptable level of vulnerability (at least in the eyes of PCI DSS).

Implementing Requirement 12.3.9

We’ve seen two main ways that organizations meet this requirement.  The first is fairly straightforward – enabling and disabling accounts for only those periods of time that the third party requires access to your network.  The standard doesn’t specify the length of the time window you can open access, but the phrase “immediate deactivation after use” makes it clear that you should be allowing access on a connection-by-connection basis.

The second, more creative approach, is to make innovative use of two-factor authentication, as one organization did.  This group uses keyfob-based authentication for two-factor control.  Normally, keyfobs are issued to individual employees, who may then use them to access the network when needed.  In the case of vendors and business partners, the keyfobs are instead kept at the 24-hour NOC.  Here’s how that works:

1. Vendors who need access must call the NOC and authenticate using a verbal protocol.
2. The NOC consults vendor-specific instructions to determine whether additional approval is required.
3. If additional steps, such as contacting the employee who maintains the vendor relationship, are required by the vendor-specific instructions, the NOC staffer who receives the calls follows those steps.
4. The NOC operator accesses the keyfob for the vendor’s account and provides the vendor with the code on the fob.
5. The vendor accesses the network using that one-time password.

The beauty of this approach is that access is automatically deprovisioned as soon as the vendor connects.  The one-time password from the keyfob is no longer valid and the requirement is met!

No matter what approach you choose, remember to implement an audit trail!  QSAs will be looking for evidence that you’re following the process that you’ve designed.  This can be as simple as a paper log in the NOC where you record vendor access requests.

What If That’s Not Feasible?

Cases can arise where 24/7 access by a vendor or business partner is required to meet your business requirements.  If that’s true in your environment, the answer is to identify a compensating control and have it approved by your acquiring bank.  Some examples of compensating controls that you may wish to consider include:

• Background screening of vendor/partner employees identical to that used for your own employees
• Real-time notification to administrators when vendor/partner accounts are used.
• Placing the vendor/partner in a network subnet that strictly limits their access.

When you design your controls, it’s helpful to remember the intent of the rule: providing an added safeguard for accounts that have an inherently higher risk.  If you design with this principle in mind, you’ll be on a great path!

Thankfully, these conversations now are a rarity.  However, as the banks extend their compliance focus to level three and four merchants, who may rely on locally grown applications and services, situations still may arise where a vendor does not know about PCI or PA DSS.  Or the vendor simply may not consider their service subject to the standards.

For that matter, you may wonder if you are a service provider yourself!  Many organizations make use of multiple merchant accounts for a variety of legitimate business reasons.  In such circumstances, organizations may wrestle with this question.*

So, how does service provider compliance relate to merchant compliance?  And how is service provider status determined?

Impact on Merchant Compliance

Section 12.8 of the PCI DSS requires merchants sharing cardholder data with service providers to “maintain policies and procedures to formally identify service provider responsibilities for securing cardholder data” and to conduct annual monitoring of the provider’s compliance status.

You may wonder why merchants are charged with policing service providers.  The answer is that the card brands have no direct authority over these players.  As we’ve noted before, the mechanism for propagating the security improvements desired by the payment card industry is through a sort of chain reaction: the card brands require their member banks to enforce PCI with their merchants, whose own compliance is dependent upon their insistence on service provider compliance.

This strategy has been very effective at moving providers toward compliance or out of the business.  In one case, I recall a vendor who became persuaded that their service was in fact in scope.  For this vendor, the hosting service they provided relating to cardholder data was not a significant part of their business.  They quite reasonably chose to stop providing the service rather than undergo the compliance effort.

Service Provider Defined

The PCI DSS Glossary version 2.0 defines a service provider as a “business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. Entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded.”

Naturally, the SSC has made this category incredibly broad.  The key here is in the actual requirement, which refers to a specific class of service providers:  those with whom credit card data is shared.  Others have restated this definition as “any third party that stores, processes, or transmits cardholder data on your behalf.”

This is also the key for those organizations owning multiple merchant accounts.  If the organization holding the accounts is one entity, it is not handling data on behalf of others.  Each of the merchants accounts must still be managed in a PCI compliant manner, but no external service is provided.

Leveraging Service Providers

While monitoring service providers is an additional burden for merchants, there also is the potential to reduce scope, risk, and compliance headaches.  This can be accomplished by migrating unsafe or internally managed processing to an affordable, compliant service provider (when one is available).

Usually, such a move requires business process revision, but this is another place where a burden can become an opportunity.  We have seen successful process improvement initiatives grow out of new service provider relationships.   In one case, a merchant was able to shorten one of their busiest times of the year by weeks while getting better reporting.  In this particular case, the costs of the new, PCI compliant service were more than offset because they were able to reduce their reliance on seasonal workers.

I’ve never heard a PCI compliance initiative described as fun, but they can be used to move an organization forward in domains other than risk management.

*You may also wonder about your merchant level in such situations.  This is determined in conjunction with your bank.  But to meet the intent, the bank should count the transactions in each payment channel to determine the level for the merchant accounts.  In other words, if your organization has three merchant accounts and two of them share the same payment system while the third uses a completely different payment system, compliance and validation requirements should be assessed for the two payment systems.  More detail will be provided in a future article.

“A corporate service organization stores, processes, or transmits cardholder data on behalf of different departments. Each department is a merchant and there are thirty merchants . Is the corporate service organization a Service Provider under PCI even [if] it is internal?”

We saw this question arise about three years ago for a large institution (having just over 40 merchant accounts and over a dozen payment systems).  We maintained (and the institution’s acquiring bank agreed) that because the merchant accounts belonged to a single entity the services provided by that entity to its internal constituents did not make that organization a service provider.

Obviously, all of those merchant accounts were still in scope for PCI DSS and each system had to be certified compliant.  Here is another post that elaborates on the definition of a service provider under PCI.

Verifying Scope

When a Qualified Security Assessor (QSA) prepares a Report on Compliance (RoC) for your company, they first must identify the scope of their assessment. They’re required to document that they’ve verified your approach in four ways. PCI DSS 2.0 states that they must verify:

• The methods or processes used to identify and document all existences of cardholder data
• How the results were evaluated and documented
• How the effectiveness and accuracy of the methods used were verified
• That the assessor validates that the scope of the assessment is accurate and appropriate

As you prepare your own compliance plan, you should engage in these steps yourself, to ensure that you’ll be ready when the QSA arrives.

Using an Assessment Tool

In working with my clients, I’ve found that the easiest way to verify scope is to search for the presence of cardholder data outside of the defined PCI DSS scope. My technique for doing this is to install a tool on all of the organization’s systems that searches for and reports the presence of credit card numbers.

You have a few options here:

• Use a commercial tool. This is, by far, the easiest approach. While there are a number of very expensive data loss prevention tools available on the market, my preferred choice is IdentityFinder. This is an easy-to-use desktop tool that reports information in a way that users can easily interpret and remediate. It also reports data back to a central console, providing you with administrative oversight.
• Use a free tool. There are some open-source tools available that perform similar tasks. These include Cornell University’s Spider and the SENF Sensitive Number Finder from the University of Texas. While these will save you a few bucks, they’re much less user friendly and lack any centralized administration. I strongly encourage you to go the IdentityFinder route.
• Brew your own. If you have too much time on your hands, you can try building your own tool. If you decide to go this route, you probably want to read more about the Luhn algorithm and how credit card numbers are constructed to help limit your false positive rate.

As you’ve probably figured out by this point, I’m a strong proponent of the commercial tool option on this front. I like the ability to set up IdentityFinder and let it do its thing. Once you sort through the initial results (which can be time consuming), you can leave it alone until it triggers an alert that requires investigation.

“When will merchants be contacted with the questionnaire for compliance? I have had card processing for 8 years and have never been contacted previously.”

Depending upon your size, that may or may not be surprising. PCI SSC does not contact merchants of any size directly. The card associations place the onus on the acquiring banks to reach out to their customers and make them aware of the requirements.

Acquiring banks began this process with their largest merchants (Levels 1 and 2) back when the compliance deadline of June 2005 was set. A year and a half after the deadline, only 65% of Level 1 and 15% of Level 2 merchants had certified compliance.

Adoption was deemed too slow by the associations, which initiated the PCI Compliance Acceleration Program. The program was an attempt to move the industry along through both sticks (fines on the acquiring banks ranging from $5K to $25K per month) and carrots (incentive payments to the acquirers, if they met a new 2007 deadline).

Now Level 1 and 2 merchants were hearing from their acquirers; but Levels 3 and 4 were quite often ignored by the banks, who were risk prioritizing their efforts. In recent years, with the top merchants in compliance, banks have turned their attention to their smaller clients. Thus some merchants may only now be hearing about these requirements, first published about five years ago!

As for the requirements and questionnaire, they are available in the PCI SSC Document Library. As you get started on your PCI DSS Journey, you may wish to read An Introduction to PCI DSS.