Encrypted Cardholder Data – Out Of Scope?

I had an interesting exchange on Google+ the other day regarding whether or not encrypted data is in scope for PCI compliance.  In the end it was suggested that I write a blog entry regarding this topic as they said how to treat encryption has not been articulated very clearly by the PCI SSC.  I would argue that the rules regarding encryption and scope have been very clearly articulated in the PCI SSC’s FAQ #1086.  However, based on the conversation we had, it was obvious that this is not the case.  So here are the rules as practiced by most QSAs.

The key to how to interpret whether or not encrypted cardholder data is in-scope is in the FAQ.  Encrypted cardholder data (stored or transmitted) being out of scope is based on whether or not that data meets the following definition.

“It is possible that encrypted data may potentially be out of scope for a particular entity if, and only if, it is validated (for example, by a QSA or ISA) that the entity in possession of the encrypted data does not have access to the cleartext cardholder data or the encryption process, nor do they have the ability to decrypt the encrypted data.”

The important phrase in the aforementioned definition is “if, and only if.”  The only way encrypted cardholder data (CHD) is out of scope is if the entity being assessed for PCI compliance cannot decrypt the encrypted CHD.  This is a very important concept that gets constantly misinterpreted by QSAs and their clients.  However, it is up to the QSA to confirm that the organization being assessed cannot decrypt the encrypted CHD and to document the procedures conducted to prove that fact.

With that as background, let us look at storing and transmitting encrypted data and how they can be out of scope and what that means.  As you will see, out of scope can mean different things depending on the implementation of encryption.

Stored Cardholder Data

Under requirement 3.4, one of the methods recommended for the storing of the primary account number (PAN) is:

“Strong cryptography with associated key-management processes and procedures“

One of the ways organizations accomplish this is through a hardware security module (HSM) that manages the cryptographic key process.  The HSM generates the keys, manages the keys and provides an application programming interface (API) for code to access the keys.  Since the HSM is a “black box” a lot of organizations point to that fact as the reason their encryption is out of scope.

There is an additional condition to the encryption out of scope definition that usually gets forgotten.  This is what allows for the scope of the cardholder data environment (CDE) to be reduced.

“Systems performing encryption and/or decryption of cardholder data, and any systems performing key management functions, are always in scope for PCI DSS. Scope reduction for encrypted data may only be considered when that data is isolated from these processes.”

As such, since the organization using the HSM technically has access to the cryptographic keys through the HSM’s APIs, the encryption is in-scope.

Where stored encrypted CHD is out of scope is when a third party controls the encryption keys.  This most often occurs with tokenization.  Under a tokenization scheme, the CHD is sent to a third party who then securely stores the CHD and returns a token that links the CHD at the third party to the token stored by the merchant.  If the merchant needs to make any subsequent charges to the account, the merchant sends the stored token to the third party and the third party substitutes the stored CHD for the token and the transaction is completed.  But since the merchant does not have access to the token creation process, the token is out of scope because it is no longer considered CHD.

Transmitted Cardholder Data

Secure transmission of CHD can be accomplished through a number of methods.  The most common of these methods is secure sockets layer (SSL) or transport layer security (TLS).  In either case, if the organization being assessed has one of the endpoints in the SSL/TLS encryption, then the SSL/TLS process is in scope.  This is obviously most common in the conduct of e-Commerce when the merchant’s Web site has an SSL/TLS certificate for securing the transmission of the CHD to pay for the customer’s purchases from the Web site.

However we are also seeing SSL/TLS used more and more as the encryption method of choice for point-to-point encryption (P2PE) solutions.  Again, if either of the endpoints in the P2PE environment are under the control of the organization being assessed, then the endpoint or endpoints are in-scope for the PCI assessment.

One way we do see to get everything but the merchant’s endpoint out of scope is terminals that are encrypted from the terminal to the processor and the processor controls the encryption keys for the P2PE.  This is most often used in the gas station environment where the pump card reader does P2PE to the processor using derived unique key per transaction (DUKPT) or similar techniques to create an encrypted connection.

That said, what happens to the users and devices in between the two encryption endpoints on an encrypted communication link?  They are out of scope as long as they do not have the ability to decrypt the data stream.  This is another misunderstood interpretation of the FAQ.  While some personnel inside an organization have access to encryption keys, if a user or device does not have access to the encryption keys or the communication endpoints, they too are out of scope.  This is how an SSL/TLS/IPsec connection can be used for isolating the transmission of CHD from the rest of the network and satisfy network segmentation.

Another issue that comes up with managed service providers (MSP) is when the MSP has access to firewalls or routers that are encryption endpoints.  Even if the MSP does not have access to the encryption keys, they do have access to the encryption endpoint(s) and cleartext CHD, therefore their personnel and relevant device management practices are in-scope for PCI compliance.

The bottom line in all of this is; if your organization has the ability to decrypt either the stored CHD or transmissions of CHD, then you are in-scope for PCI compliance.

And as a reminder to everyone, just because something is out of scope it does not mean that it does not need to be assessed.  It is always necessary for a certain amount of testing procedures to be conducted to determine that the item is out of scope.

Hopefully we can now all operate from the same set of rules.

Scoping Clarification

At the 2012 PCI Community Meetings, the PCI SSC made a presentation titled ‘PCI Standards Updates and Future Insights’.  Embedded in that presentation were a series of slides titled ‘Scoping & Segmentation Clarified’.  A number of writers have given reference to this clarification, but I have yet to see a discussion regarding the content of these slides.  So I felt someone should share with the world the content of these slides so that we are all on the same page.

“PCI DSS requirements apply to all system components, defined as any network component, server, or application that is included in or connected to the CDE [cardholder data environment]”

The first thing discussed are the misconceptions about PCI DSS scoping and what “connected to” really means.  Those examples of misconceptions pointed out as FALSE included:

• Encrypted cardholder data (CHD) is always out of scope
• “Connected to connected to” systems are not in-scope
• Only systems that connect directly to the cardholder data environment are in-scope
• Only inbound connections are in-scope
• Directly connected to systems are not in-scope if they pass through an in-scope firewall

Encrypted CHD Is Out Of Scope

The only way encrypted cardholder data is ever considered out of scope is if, and only if, the organization being assessed does not have the ability to decrypt the data.  That said, it is up to the organization or their QSA to prove that the organization does not have access to the keys by documenting the assessment procedures that were performed to determine that the encryption keys could not be accessed and the cardholder data could not be decrypted.  So even though it may eventually be judged out of scope, there must be some form of investigation that proves that fact.

“Connected to connected to” Systems Are Not In-Scope, et.al.

The remaining four examples given as false are all related.  The guidance being provided by the PCI SSC should have been common sense to any security professional and QSA, but apparently was not as clear as we all thought.  As a result, the PCI SSC documented their thought process and provided this “guidance.”

“If a system can impact the security of the CDE (whether it is directly or indirectly connected), it is in-scope.

To be considered entirely out of scope, a network or system must be isolated from, with no connectivity into, the CDE (such that even if the system is compromised, it cannot impact the security of the CDE).

Restricting access by IP or port may limit the exposure of the CDE but does not automatically remove systems/networks from scope since there is still connectivity.

If connections are limited to specific ports or services, those systems are included in the PCI DSS scope to verify applicable controls are in place.”

Talk about opening a can of worms.  To a lot of people, this definition sounded a lot like Stalin’s “Doctor’s Plot.”  Exactly where do you draw the line on a network and what is connected to what?  To a lot of hard-line QSAs and some participating organizations (POs), this clarification essentially put everything back in-scope for PCI compliance because, in theory, any device on the internal network can be used to ultimately compromise the CDE.  To all of you out there that think this, take a pill and chill.  That is not what the clarification is saying unless there are no systems on your network that are truly isolated from the CDE.

The PCI SSC has left this decision to your QSA/ISA to determine where the boundaries of your CDE get drawn.  And that is based on the risk presented and how you have controlled access for the outliers on your network.  So, while in theory any device sitting on a network could be used as a staging point or beachhead to ultimately compromise the CDE, it all depends on the controls in place to minimize that potential risk.

As an easy example of what the PCI SSC is getting at with this clarification, any systems with access to the CDE are in-scope for PCI compliance.  According to the PCI SSC, a lot of QSAs were ruling systems out of scope such as backup systems, domain controllers, DHCP and DNS servers, management consoles and anything else used to manage, monitor or control devices inside the CDE.  The bottom line is that should any of these systems be compromised, the CDE is also likely compromised.  Limited access or not, these systems have access to the CDE and are therefore in-scope for the assessment.

The other part of the clarification is about just because a system has access to the CDE does not imply that all PCI requirements apply.  There are big differences between the access a backup system may have from a call center operators’ or an accountants’ PCs may have to the CDE.  As a result, it is up to the QSA/ISA to determine what PCI requirements are relevant based on the risk presented by the system and how it accesses the CDE.  At a bare minimum, any PC that has access to the CDE needs to be properly configured and security hardened, patched current, have anti-virus and anti-malware software and a firewall implemented.  If the PC has direct access to the CDE through something other than HTTPS as with a backup server or domain controller, then you should be treating these devices no different than a device inside the CDE. Whether or not additional requirements may be required will depend on the assessment of the PC and how it accesses the CDE.

Given this clarification, what should you be doing to determine the boundaries of the CDE?  Here are some of my ideas.

• Scan you network for cardholder data (CHD) using OpenDLP, custom queries of databases and similar tools.  Document all systems that are found with actual CHD.  Make sure to check that the data found is actually CHD and not just 15 – 16 digit numbers that happen to pass a Luhn check.  We have encountered a lot of random log data from firewalls and intrusion detection/prevention solutions over the years that upon further inspection turned out to not be CHD.  The purpose of doing this scanning is so that you are reasonably certain that CHD does not exist on systems you did not know about.
• Review your virtual LANs (VLAN) and related access control lists (ACL) and document what controls are in place to isolate systems from the CDE.  If ports are open between the CDE and a network segment, document why they are open.  A lot of times this sort of review results in discovery of systems that do not need CDE access but were granted access just in case.  The purpose of this review is to make sure that the CDE is truly isolated from the rest of the networks.  If not isolated, it may be possible to move systems into a few VLAN segments and isolate those segments to minimize your total CDE.
• If possible, locate critical servers such as domain controllers, backup servers, etc. inside the CDE.  A lot of organizations have located one or two domain controllers inside their CDE and then limited communications to/from those domain controllers and domain controllers outside the CDE.  While the domain controllers outside the CDE are still in-scope if they communicate with the CDE domain controllers, such a move puts the majority of the risk on the CDE domain controllers.  In today’s SAN world, putting a backup server with a fiber channel connection back to the SAN used for virtual tape allows you to isolate your CDE backup process.
• For those organizations that have virtual desktop technology implemented, consider creating virtual systems for providing access to the CDE.  A lot of organizations with virtual desktop technology have segregated this technology onto servers that only provide access to the CDE therefore limiting what virtual servers are in-scope.  Depending on the controls of the virtual environment will determine how much of that environment is necessary to be included in the assessment.  These virtual desktops should be built from a standard image and be strictly locked down so that new software cannot be installed by the user as well as they should be configured to log all user actions.  When using this approach, the user must have authentication credentials (i.e., user identifier and password) different from their other credentials.  You are also going to want some form of firewall between these virtual systems and the rest of the network and granting access to those systems that require access.
• Another opportunity to minimize the CDE is the use of “jump boxes” on the network.  Jump boxes are accessed via remote desktop technologies to then gain access to the CDE and are typically used for network and server administration and management.  The jump box is configured so that any user’s activities are recorded and logged for later review.  Jump boxes are no different than the virtual desktop solution other than jump boxes are typically physical devices versus virtual devices.  The reason for using a physical device versus a virtual device is the jump box can be physically accessed if necessary in emergencies.  As with the virtual desktop solution, users of jump boxes must have user identifiers and passwords different from their other credentials and you will also need a firewall protecting the jump box.
• For systems that have access to virtual desktops or jump boxes, these should still be security hardened, have anti-virus and anti-malware with current signatures and should also be timely patched.

A lot of people would think a virtual private network (VPN) over SSL, TLS, SSH or IPsec solution would also meet the requirement of isolation.  The problem with the VPN solution is that there is no isolation or gap between the system used to access the general network and the CDE.  The VPN does provide isolation of data transmissions but, if the system is compromised, the CDE is also likely compromised.  With the other solutions there are multiple ways that the CDE systems are isolated from the rest of the network.

Now we should all be on the same page.

What Is “In-Scope?”

You would think this question would be an easy question to answer when talking about the PCI standards because anything that processes, stores or transmits cardholder data is in-scope for PCI compliance.  However, the nuances in the implementation of technological solutions do not always allow a black and white answer.  Here are some of the most common in-scope issues we seem to come across.

Defining The Cardholder Data Environment

The first step in any PCI assessment is determining the extent of an organization’s cardholder data environment (CDE).  However, it should come to no surprise to anyone that defining an organization’s CDE can be difficult even in the smallest of organizations.

The first question is who is responsible for defining the CDE?  Until the release of the PCI DSS v2.0, this was not clear, but had always been implicitly defined by the PCI SSC and the card brands as the responsibility of the organization, not the QSA.  The QSA’s role is to take the CDE definition provided by the organization and confirm that the CDE definition is accurate based on the QSA’s assessment work.

The next question that inevitably comes up is how does an organization prove that its CDE is its CDE?  There are a variety of things an organization can do to define their CDE.  The first thing to do is to document the cardholder data flow.  This effort should define all of the applications involved as well as which applications actually store cardholder data.  Once the data flow is defined, then an organization should develop a network diagram that documents all of the firewalls, routers, switches, access points, servers and other network devices and how they are architected.

The final step in proving the extent of the CDE is for the organization to scan their entire network to confirm that cardholder data is not stored anywhere outside of the CDE.  For organizations that have invested in data loss prevention (DLP) technology, it usually means setting their DLP solution to look at all computers on their network and determine if any unencrypted cardholder data exists anywhere outside of the proposed CDE.  However, some DLP solutions have not capability to look at data stored in databases, so just because you have a DLP solution does not mean you have searched everything.

For those organizations that do not have a DLP solution, the process is the same but possibly a bit more complicated.  For organizations that have a budget, they can license GroundLabs’ Enterprise Recon utility to scan their network and databases.  For smaller organizations, GroundLabs also has Card Recon that it licenses on a number of PCs/servers basis.  There are also free or open source utilities available such as Spider from Cornell University, SENF from the University of Texas and CCSRCH from Sourceforge.  I personally prefer Spider from Cornell as I think it finds the fewest false positives of the three free utilities.  However, none of these utilities can scan a database and find cardholder data stored in a database.  And just so we are clear, all of these utilities are no absolute guarantee that an organization has truly found all cardholder data they may have stored on systems.  But, it is better than have done nothing.

For organizations that are not using a utility that understands database scanning, there is a manual way to conduct your assessment.  Unload any credit card account number (PAN) fields as well as all comment fields into a CSV or similar file format and then use whatever utility you are using to scan those files for cardholder data.

Networks and Managed Service Providers

Networks that are used to transmit cardholder data in the clear are always in scope – no exceptions.  Where things seem to get confusing for people is when encryption is brought into the mix.  However, going back to the original definition, if cardholder data is in the clear, then that portion of the network is in-scope.  But, believe it or not, this just creates more confusion and arguments.

The bottom line is that any network encryption endpoints are also always in-scope.  That is a statement that I have almost come to blows over more than once with managed service providers (MSP) that thought their devices and network were totally out of scope because of encryption.  In a lot of these instances, the MSP is the one managing the encryption keys and since they managed those endpoints and the related encryption keys, those endpoints are in-scope for PCI compliance and so are the MSP’s policies, standards and procedures for managing those devices (Requirements 1, 2 and 4) and keys (requirements 3.5 and 3.6).

“But the cardholder data is encrypted,” is the common refrain from the MSP.  Agreed.  But a QSA still needs to gauge compliance for the endpoints, not the connectivity between the endpoints.  However, MSPs argue that the endpoints are also out of scope because of encryption.  That would be right if someone other than the MSP managed the encryption keys.

Another battle QSAs run across is about MPLS networks.  At this year’s PCI Community Meeting, the question of MPLS networks being private was brought up and discussed.  What the PCI SSC and the card brands told QSAs is that it is up to the QSAs to confirm that the networks are in fact private.  That means that QSAs are going to have to examine the configuration of the endpoint routers to ensure that the MPLS network is in fact private.  I can tell you that this will put QSAs in a battle with a number of carriers who treat their MPLS networks and their configuration as intellectual property.  I can tell you from personal experience that these battles to get carriers to reveal their configurations can become very contentious and downright ugly.

The bottom line is that a lot of MSPs do not agree with their activities being in-scope and they refuse to allow an assessment of their environment where their activities are in-scope.  In those instances, we have no choice but to mark the client as not having those requirements in place.  I have constantly asked MSPs that fight us to explain why the MSP is not responsible when the client cannot respond to the requirement because the MSP performs that function?  More often than I would like to admit, we get the “trust us” response.  In a few instances, I have been told that, “The PCI SSC and card brands never meant it to be treated that way.”  Really?  Because in QSA training the PCI SSC has been very consistent on the explanation of what is in-scope and MSPs are in-scope if they perform functions that are required to comply with the PCI standards.  While the majority of MSPs have come to this realization, there are still holdouts out there that still refuse to cooperate.

Applications

Applications that process, store or transmit cardholder data are always in-scope – period.  I think everyone understands that statement; however, it is the nuances within applications that create the problems.

In today’s integrated application environment, it is no wonder that determining what applications are in-scope is difficult, if not impossible.  Most organizations have gotten out of the complete application development game and are now in the application package integration game.  As a result, organizations are relying more and more on the application package vendors to understand data flow, particularly cardholder data flow.  While the PA-DSS process has greatly helped in getting data flow diagrams, there are still a lot of credit card processing applications where the data flow diagram is just not supplied.

Then we have “middleware” that further obscures things.  Middleware reformats information streams so that one application package can communicate with another application package.  The biggest problem with middleware comes from the fact that a lot of application integration teams are not really sure as to whether the cardholder data is in cleartext or encrypted.  The other problem we have encountered with middleware is the lack of security surrounding the administration consoles of the middleware.  Most middleware consoles are browser-based and can be accessed by anyone on the network.  Worse yet, a lot of these consoles can have serious security issues that make then susceptible to compromise.

Hopefully this explains the most common issues we see with scoping PCI assessments.  If you have any situations where you question scoping, please share them with the group and hopefully we can explain what is in-scope and what is not in-scope.

Advice To Merchants

Barring the card brands developing a truly secure card processing process, the PCI DSS and related standards are likely to be with us for quite a while.  That said, what is the future of complying with the PCI DSS?

For merchants, if you are not seeking out point-of-sale (POS) solutions that do not store cardholder information, you should be as soon as you possibly can.  That includes finding card processors that do not require you to store cardholder information and can provide you access to cardholder information when you need it for resolving disputes and chargebacks.  According to Robert McMullen, CEO of TrustWave, the majority of breaches TrustWave investigated occurred with POS systems.  So the rational approach to resolving this problem is to get rid of the cardholder data stored on these systems.

The problem with this is that most merchants, large or small, think that they need to store this information for some reason.  If you are a merchant in the United Kingdom, France, Italy and other select European countries, then you do need to have the PAN unencrypted, however it only is required on an original printed receipt, it is not required to be stored anywhere else.  So, all merchants need to put POS solutions in place that do not store cardholder data.  You do not need it and it puts you at risk if you do store it.

The next thing merchants need to do is to find a card processor that does not require the merchant to store cardholder data.  This can be a processor that uses tokenization or whatever, but the bottom line is that the processor does not return cardholder data to the merchant’s systems.  These processors typically provide secure Web-based systems that allow the merchant to view all of their transactions processed and, if necessary, provide a method to decrypt the PAN for dispute research and chargebacks.  Merchants need to restrict access to the processor’s applications to only those people that absolutely need access to perform their job.  These people should be reviewed at least quarterly to ensure that they continue to require access.

For those of you that just cannot get rid of cardholder data, there is the option of hashing.  Hashing allows applications such as fraud discovery, member tracking, rewards programs and similar functions to continue, they just do not have access to the actual PAN.  A hashed PAN results in the same hashed value, so research and analysis of PANs can still occur.  It is just that if you need to see the real PAN, you will have to go to the processor’s system to obtain the real PAN.

The travel industry, in particular hoteliers, are really behind the eight ball on PCI because of their need to keep the PAN for sometimes years because of the way reservations work.  However, this is where tokenization can earn its keep.  If a hotel takes a reservation and gets back a token when the credit card is authenticated, then the hotel can use the token however many times in the future for check in and check out.  Again, there is no reason for the hotel to need to retain the actual PAN.

The bottom line to all of this is that there are ways to minimize your organization’s PCI compliance efforts just by getting rid of the data in the first place.  So, stop putting forth efforts to comply and get with the movement to get rid of the cardholder data in the first place.  I have had a few clients go down this road and PCI compliance is now a piece of cake.  Their networks are still in scope for transmission, their applications in some cases do process cardholder data, but there is not storage which makes them much, much less of a target.

Call Center FAQ Significantly Changes

On January 22, 2010 the PCI SSC issued an update to their clarification regarding their FAQ on call centers storing CVV/CVC/CID in their call recordings.  The bottom line is that call centers are no longer allowed to store such cardholder information in recordings that are maintained digitally, regardless of whether they are encrypted.

The new FAQ (#5362) states that:

“It is a violation of PCI DSS requirement 3.2 to store any sensitive authentication data, including card validation codes and values, after authorization even if encrypted.

It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization; as card data can easily be extracted using freely available software.

On an exception basis, storage of CAV2, CVC2, CVV2 or CID codes in an analog format after authorization is allowed; as these recordings cannot be data mined easily. However the physical and logical protections defined in PCI DSS must still be applied to these analog call recording formats.

Audio recording solutions that prevent the storage or facilitate the deletion of CAV2, CVC2, CVV2 or CID codes and other card data are commercially available from a number of vendors. All other recordings containing cardholder data captured by call centers must be protected in accordance with the PCI DSS, including PCI DSS requirement 3.4.”

I am assuming that this change in policy is the result of the PCI SSC determining that, regardless of what we have been told in the latest reports from Verizon Business Services and other sources, there have been breaches of cardholder data that were the result of compromising digital audio recordings.

A big thank you to Emma Jenkins at VeriTape for pointing out this change.

UPDATE:  It appears that the FAQ has been changed again.  It now reads “It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization if that data can be queried; recognizing that multiple tools exist that potentially could query a variety of digital recordings.” adding back the “if that data can be queried” language.  There are plenty of commercial and open source tools that will search audio recordings, so of course this data can be queried.  Not sure of the motive here in this change.

How Email Ends Up In-Scope And What To Do About It

Let us clarify this issue.  I am not talking about the occasional email that contains cardholder data.  Try as your organization might, a small percentage of customers are going to email their cardholder data to you no matter how often and how strictly you remind them not to do such things.  In the immortal words of the comedian Ron White, “You can’t fix stupid.”  The way to address these customer indiscretions is to immediately print them out and delete them from the email system so that you minimize the chance that they end up on the email system’s backups.  Once done with the print out, shred or redact it.

These occasional customer “brain farts” does not, in my humble opinion, place an organization’s email system in-scope.  If your QSA says that such occasional messages do place it in-scope, I would seriously push back on this issue.  The risk involved along with the randomness of occurrence does not warrant the time and resources to totally eradicate such problems.  However, your management needs to understand the risk this presents and agree to accept that risk.

With that said, there is nothing worse than telling a client that their email system is in-scope for PCI compliance.  Most of the time, they look like a deer caught in a car’s headlights.  They just stare at you like you just slapped them across their face or dumped a bucket of ice cold water on them.  So, just how does this happen?

Interestingly, the primary cause of an email system being in-scope is due to the fact that it is not segmented away from the ecommerce environment that processes, stores or transmits cardholder data.  Some of this is not due to improper implementation.  In a number of instances, this situation occurs because the ecommerce environment requires integrated access to the email system and putting a firewall between the two is not an option.

The second reason email ends up in-scope is that in almost every email system implementation, the email system has been extended to handle other forms of communication.  As a result, the email system becomes the communications hub of an organization.  The most common extension is the integration of a facsimile system.  These integrated facsimile solutions were a God send when they were introduced as they improved efficiency and accuracy in handling facsimile communications.  They allow facsimiles to be received and automatically delivered directly to either an individual’s or a team’s Inbox based on pre-defined rules.  However as any IT person will tell you, these facsimile solutions have ended up being a compliance nightmare when security and privacy requirements like PCI were introduced.

Another application that gets integrated with email is instant messaging (IM).  IM inside an organization is typically just as secure as internal email.  However, users typically want the ability to not only IM their fellow employees, they also want to IM customers and business partners.  It is the use of IM outside of the organization that creates the problem because the security measures available inside are not typically available through Yahoo, AOL and Microsoft.  Not that IM applications cannot be secured; it is just that they usually are not secured outside of an organization.

With all of these potential risks with email, what should an organization do to ensure PCI compliance?

• Do whatever you can to get your email system out of scope.  The last thing you need is to have the email system in-scope.
• Physically or logically segregate your organization’s email system from your cardholder data environment.  If it cannot be segregated, then implement separate email solutions for your cardholder data environment and the rest of your organization.
• If you are using your email system for communicating cardholder data, stop that practice immediately and begin remediating your current email database and the backups of that database.
• If you need to use facsimile for transmission of cardholder data, have those facsimiles delivered to secure devices, not through your integrated facsimile/email system.  Most printer and multi-function device manufacturers produce devices that can provide a secure facsimile delivery capability including encrypted storage of facsimile transmissions.  If you really need the automation capabilities, then implement a separate instance of email and facsimile solutions for this purpose.
• Make sure that everyone in your organization understands the risks that email, instant messaging, facsimile and other forms of communication present to the cardholder data environment.  Train all personnel to never transmit cardholder data via any electronic communications.
• If you are printing out electronic communications that contain cardholder data, make sure that you also have proper destruction or redaction procedures documented and implemented.  Periodically test those destruction and redaction procedures to ensure that they are operating as expected.
• As best you can, restrict IM capability to only internal use.  If IM connectivity is required outside of your organization, implement it securely over an encrypted VPN link or other secure communications channels.

Decommissioning Applications

Here is a question that comes up from time to time.  Particularly because a lot of my clients are remediating their PCI compliance issues by replacing older applications with PCI compliant new ones.

What do I need to do in regards to PCI DSS compliance if I’m replacing an application?

There is no guidance in the PCI DSS regarding the decommissioning of applications that are in-scope.  So what should an organization do when they are getting rid of an in-scope application?

The first problem is the application’s cardholder data.  Cardholder data usually ends up everywhere, particularly with systems that are not PCI compliant.  Cardholder data is not only on hard disks and disk arrays; it is also on backup tapes and other backup media.  In the case of point-of-sale (POS) systems, cardholder data can end up on every POS as well as the POS servers.

The bottom line is that you need to track down all of this cardholder data and make sure that you properly dispose of it.  The key problem is making sure you have located all of the cardholder data.  You should use this opportunity to scan all of the systems to be decommissioned with a tool to locate cardholder data.  While this is not necessarily a perfect technique, it will identify all of those systems that likely have cardholder data and those that do not.  Those that do have cardholder data will be remediated first.  Those that do not have cardholder data will be remediated last.

Since these non-compliant applications typically did not securely store cardholder data, you need to make sure that the data that remains is properly disposed.  That means performing Department of Defense (DoD) grade erasing of data from hard disks and tapes.  If the hard drives are old and are not going to be reused, then I would recommend contracting with a reputable DoD certified firm to have them degaussed with your tapes.  Industrial strength degaussing will usually damage the electronics of the hard drive, so if you intend to reuse the hard drive, do not have it degaussed.  If you are going to reuse the hard disks, then they should be erased with a DoD grade disk wiping utility.  There are plenty of these available on the Internet.

The next issue is proving that the application is decommissioned.  Make sure to document all of the steps you took to ensure that the cardholder data has been removed from all systems.  Have management sign off on this documentation so that they are aware of what was done and how it was done.  This documentation will be useful for your filing of a Report On Compliance or Self-Assessment Questionnaire as well as should anything happen in the future that comes back to try an haunt you.

Hopefully this will assist those of you that are going through such a process to become PCI compliant.

PCI SSC Issues Clarification On Encrypted Data Being In-Scope

On October 27, 2009 the PCI SSC and the card brands issued a clarification on whether or not encrypted cardholder data is still in-scope (Article Number 10359).  For such a simple clarification, there was a lot of verbiage, so I thought it might be good to take a closer look at the FAQ in question.

The FAQ starts out stating the obvious facts regarding encryption that we all know.

“Encryption solutions are only as good as the industry-approved algorithms and key management practices used, including security controls surrounding the encryption/decryption keys (“Keys”). If Keys are left unprotected and accessible, anyone can decrypt the data. The DSS has specific encryption key management controls (DSS 3.5 and 3.6), however, other DSS controls such as firewalls, user access controls, vulnerability management, scanning, logging and application security provide additional layers of security to prevent malicious users from gaining privileged access to networks or cardholder data environments that may grant them access to Keys. It is for this reason that encrypted cardholder data is in scope for PCI DSS.”

The FAQ then goes on to give an exception.

“However, encrypted data may be deemed out of scope if, and only if, it has been validated that the entity that possesses encrypted cardholder data does not have the means to decrypt it. Any technological implementation or vendor solution should be validated to ensure both physical and logical controls are in place in accordance with industry best practices, prohibiting the entity, or malicious users that may gain access to the entity’s environment, from obtaining access to Keys.”

It appears that the PCI SSC and the card brands have recognized that if you do not have the ability to decrypt, then the data cannot be treated as in-scope.

However, if an encryption algorithm is used, there must be a way to decrypt.  As a result, the next sentence addresses this fact.

“Furthermore, service providers or vendors that provide encryption solutions to merchants who have administrative access and controls to Keys along with the management of termination points for encryption to process transactions, are required to demonstrate physical and logical controls to protect cryptographic keys in accordance with industry best practices (such as NIST referenced in PCI DSS requirement 3.6), along with full compliance with PCI DSS. Merchants should ensure their solution providers who provide key management services and/or act as the point of encryption/decryption are in compliance with PCI DSS.”

While we now have an exception, it appears to be only valid if the merchant do not have access to the encryption keys.  Notice, this exception does not include service providers that may also not have access to encryption keys, only to merchants.  In addition, the exception specifically calls out that vendors and service providers that have control of the encryption keys must prove that the keys are protected in accordance with industry best practices such as the NIST standards called out in requirement 3.6.  Notice, they MUST prove.  Therefore this nonsense of “trust us, we do this” is no longer acceptable.  They must provide proof that they are managing encryption keys under industry best practices.

Finally, merchants do not necessarily get off scot-free if their encryption keys are managed by a third party and the merchant does not have access to the keys.  The final statement in the FAQ covers this point.

“Merchants should be aware that encryption solutions most likely do not remove them completely from PCI DSS. Examples of where DSS would still be applicable include usage policies, agreements with service providers that deploy payment solutions, physical protection of payment assets and any legacy data and processes (such as billing, loyalty, marketing databases) within the merchant’s environment that may still store, process or transmit clear text cardholder data, as that would remain in scope for PCI DSS.”

So, in my opinion, here is the bottom line for this FAQ.  You can rule encrypted cardholder data out as long as the merchant does not have access to the encryption keys and the third party in control of the encryption keys can prove that it is properly managing the keys.  However, all other relevant PCI DSS requirements still apply.

UPDATE:  It has been pointed out to me that as long as there is an independent internal party available to manage the key, that that would also satisfy the exception.  While I agree with that assessment, with most small and mid-size merchants and service providers, I would argue that the only way they can comply with this exception is to use an external, third party to manage the keys.  Therefore, I stand by my interpretation that a third party needs to manage the keys.

In Scope – Example I

I thought I would write about a recent meeting I had with a client regarding whether or not their proposed point-of-sale (POS) solution was going to be in or out of scope.  Obviously, the hope was that it would be out of scope.

I would like to commend this organization for taking the high road to PCI compliance.  I wish there were more organizations like them.  After slugging through a very ugly PCI compliance process last year with a multitude of compensating controls to get them compliant, senior management set a goal of removing all cardholder data (CHD) from their point-of-sale (POS) systems over the next year and a half.  To accomplish this, they are going to implement a tokenization solution on their centralized transaction switch that they are developing in-house.  As part of this effort, the company is purchasing a new POS solution that is PABP compliant with the vendor stating that the next version will be PA-DSS compliant.  The discussion at my meeting was to determine if the POS solution would be in or out of scope.

Prior to the meeting, the client had provided me with some documentation describing their plans for the POS implementation.  I have taken some editorial license to protect the identity of the client, but here is the verbiage that I was provided regarding the configuration of the POS solution.

“The POS PC is connected to a separate credit card terminal by a USB connection.  There is a software client running that communicates with their centralized transaction hub that then submits transactions for authentication as well as handling settlement.  The only interaction between the PC and the terminal is to pass the amount of the transaction from the PC to the terminal and for the terminal to tell the PC whether or not the transaction was approved or declined.”

On the face of things, the solution appears to keep the POS solution out of scope.  However, this is a prime example of why documentation must be complete, clear and accurate.  Interpreting the documentation and lacking a detailed network diagram, I assumed that the credit card terminal and the PC had separate network connections.

As Paul Harvey was so famous for saying, “And now for the rest of the story.”  It turned out that the documentation had a slight flaw.  The person who wrote the majority of the documents had inconsistently used the terms ‘terminal’ and ‘POS’ through out.  A common mistake since most people that develop documentation are usually very close to the implementation process and make the assumption that everyone that reads the document has the same background with the topic in question.  As a result, it was not clear whether the terminal was the PC or the terminal was the credit card terminal.  What the meeting uncovered was that the client software that communicated with the centralized transaction server was in fact running on the PC, not the credit card terminal.  This meant that all communications to and from the credit card terminal were routed through the PC to the centralized transaction server.  That means that the POS solution is in scope.

The moral of the story is that a good QSA never assumes they know everything about a solution and why they seem to ask many questions about something you would think they would know.  The reason is that a good QSA knows that it is your organization’s implementation of the product, not another organization’s implementation and there will be differences.  And those differences could mean the difference between in scope and out of scope.