The New Telephony Information Supplement

In case you missed it, the PCI SSC released their new information supplement on telephony this week.  Since I served on this Special Interest Group (SIG) I was involved in its development.  As a result, I thought I would share my thoughts on the new information supplement.

A Bit Of Background

At the start of the SIG a number of participants brought up the fact that the prior Telephony Information Supplement issued in 2011 had basically been ignored by the qualified security assessor (QSA) community and companies being assessed.  A number of QSAs and Participating Organization (PO) representatives explained to Council representatives that they had personally witnessed situations where QSAs ignored voice over IP (VoIP).

That brought about the following response from one of the Council members on the call:

“All QSAs are trained to understand that VoIP is in scope if CHD/SAD [cardholder data/sensitive authentication data] is discussed on any telephone calls.”

The consensus response was that while that is no doubt the case, many participants attested to the fact that they had encountered QSAs ignoring VoIP as being in scope.  Some had witnessed QSAs telling their clients and prospective clients to not worry about VoIP because it will not be in scope.  These same QSAs did worry about the security of call recordings, but they were leaving the rest of telephony out of scope.

That response seemed to send a chill through the Council representatives.  No one identified any particular qualified security assessor companies (QSAC) but the participants made it clear that VoIP was largely being ignored in PCI assessments.  The point was also made that some QSACs were benefiting handsomely in obtaining engagements because of their willingness to ignore VoIP.

But that exchange also identified a shortcoming with today’s telephony solutions.  QSAs and technology people do not seem to understand telephony solutions and appreciate their risks.  Therefore, they do not know where to even start in securing them let alone those that make an attempt only to find themselves in one or more “rabbit holes”.  As a result, it is easier to ignore these telephony solutions than to try and deal with the intricacies and vagaries of securing them.

There were also brief discussions about the shortcomings of the original information supplement from 2011.  The biggest complaint of which was that it was call center centric and did not reflect what was being implemented in the real world.  Various people explained that the 2011 document did not address call centers operated within corporations on a shared telephony solution with the rest of the business nor was there any useful guidance provided for PCI compliance.

Such configurations obviously complicate the scope of PCI assessments since any device connected to the shared VoIP system and network was therefore in scope (hence why a lot of QSAs ignore VoIP).  As we were to find out, the new version of the information supplement would do only a little to address this complex issue.

Disappointment

Trust me, it was not the SIG’s intent nor the Council’s intent to disappoint people, but I have a feeling that a lot of people will be disappointed with this information supplement.  Not that there are not good ideas and solutions presented, they are just not always as fleshed out as well as they should be and do not always represent what actually goes on with the solution.  The reason is for that is because telephony solutions all operate differently when performing various functions such as call forwarding, conference calling and the like.  As a result, providing real guidance depends greatly on how a given solution functions in a particular circumstance.  As we found out a number of times, this issue would come back to bite SIG participants repeatedly.

In my very humble opinion, the latest information supplement is lacking in detailed guidance to a lot of telephony situations particularly those that are complicated because of how vendors have approached Unified Communications which is the driving force now behind most vendors’ current telephony solutions.  The document points out a lot of scope and security concerns regarding the use of softphones and VoIP only to leave the reader essentially up to their own devices as to how to address those concerns using existing guidance from other information supplements.

That was a point of contention as the information supplement was developed.  There were a number of people that argued that more guidance was needed to be provided because the issues are more complicated and nuanced than the supplement leads people to believe.  They wanted more discussion with the card brands about the risks involved so that all parties could come to a consensus over what was acceptable risk and if there were better ways to address those risks and therefore provide more guidance.  Unfortunately, we were told that there was not enough time to have such discussions which drove in great part what resulted in the document that you now have access.

Then there are the threats to VoIP that seemed to be minimized in discussions.  At one point in a meeting someone stated that VoIP is not an attack vector so there is no need to worry about it.  This individual was almost immediately reminded that this is how we got into this situation in the first place.  People ignored the risks to processing, storing and transmitting payment card data and then we all had to do a fire drill to secure that information.

Using CVE Details, I was able to identify close to 400 specific threats to VoIP and/or specific VoIP vendor solutions.  Of those, there were around 250 to 300 that appeared to be able to compromise VoIP and by association, CHD/SAD.  While most had been patched, there were a around 20 that had no fix because they were flaws in the protocols themselves (mostly due to UDP streaming).  The bottom line in this research is that while VoIP might not be an active attack vector at this point in time, it is ripe for being turned into one.  Worse, current information security practices have minimal effect on a lot of the attack vectors thanks to UDP.  And if that was not bad enough, in a lot of cases all it takes is a telephone call to start the attack process.

With that as a background, while the new information supplement is a quantum leap above the 2011 information supplement, a lot of participants feel it is still somewhat lacking in guidance.

Telephony Guidance Anger

I can already anticipate the anger that will result from this one particular recommendation on page 55, section E.4 Unified Communications, where it states:

“As a result, entities can find that their only option to minimize the PCI scope of their VoIP environment is to implement multiple instances of in scope VoIP and out of scope VoIP.”

Say what?!?!?

That will be a huge burst of a bubble to a lot of organizations, QSAs and ISAs alike.  The rationale for this statement goes to Unified Communications and how most vendors have approached it.  The telephony system vendors have now so tightly integrated services such as voice, voice mail, facsimile, video, telepresence, instant message, email and other communication mediums that it has resulted in an inability to decouple and move say instant messaging or email to a different network segment from the call manager.  As a result, there are no easy ways to implement network segmentation around telephony solutions so that some are in the CDE (Category 1) and others are in Shared Services (Category 2).

Unfortunately, Unified Communications is not the only situation where two telephony solutions will be needed.  Softphones, call centers on common corporate telephony solutions and other telephony features/functions will also create situations where the only way to be PCI compliant will be to implement at least two separate telephony systems.

Speaking of softphones, if you were angry at the first statement, your anger will likely only grow when you read the following on page 24, 5.2.4 Softphones:

“It is important to note that the use of such systems [softphones] to capture payment card account data would bring the workstation and probably the network it is connected to into PCI DSS scope.”

The next paragraph after the quotation points readers to the Network Segmentation Information Supplement for guidance.  Unfortunately, the problem with that guidance is that regardless of how you try to segment the workstation, the softphone application will put the workstation in scope regardless.  No other guidance is provided regarding softphones.  It is not like this was not discussed within the SIG, it is just that there was no agreement on how to address this subject.  So, what you read in this section is the guidance you get.

One potential solution discussed to minimize scope is to put the softphone in a virtual desktop (VDI) workstation.  That would put the VDI in the CDE and the workstation as Shared Services.  However, the VDI approach can be fraught with compatibility issues and other technical problems that may not reliably provide telephony service to end users via the softphone.  There is also still some risk of eavesdropping through the end user’s workstation, but it is now limited to memory in the workstation versus the softphone software that can sometimes be addressed with other workstation controls.  This of course is assuming that the VDI solution is easier to control, secure and monitor than the physical workstations.  The bottom line is that there are a lot of moving parts that would have to be assessed on a case-by-case basis, so the consensus was that there was no general, one size fits all recommendation that could safely be made about the VDI approach.

Another scope reduction approach is to use “inexpensive” physical SIP phones for handling calls that are logically network segmented away from the workstation.  I have a number of clients with agents configured this way to limit telephony scope to just their SIP phone.  But then their router must support two VLAN connections and those VLANs cannot be allowed to access each other.  That is easy to do in a corporate environment but can complicate things with SOHO workers.  Such a solution can drive up networking and equipment costs to an unacceptable level for some organizations.  Particularly organizations that were looking at softphones to reduce costs.

There are plenty of other areas of the information supplement that will generate anger mainly because for the first time, the PCI SSC is calling out more areas that are in scope for PCI compliance that organizations and some QSAs/ISAs treated as, or thought were out of scope.

Miscellaneous Comments

There are a few more points that I felt should be discussed.

On page 43, 7.2.2 SIP Trunking, the following quote will be of interest.

“As the technology matures, technical boundaries between an organization and SIP Trunk provider may become harder to define. Scoping for these services will therefore require an understanding of how connections are made between the different entities.”

I feel this is already an issue because the boundaries are already blurred.  When you realize that VoIP is predominately a UDP protocol, there is little you can do from an information security point to protect your telephony system.

First the carriers will tell you that their SIP demarcation device will provide some amount of security for your organization.  Exactly what amount of “security” that device actually provides is questionable at best.

But speaking of UDP, page 54, E.1 Protocols, Ports and Network states the obvious.

“… the use of UDP may render the detection of malicious content or payload more difficult.”

More difficult?  In some ways, it can be impossible to detect malicious payloads because it is streaming, and you want to ensure continuity of a conversation.  This is the biggest security issue with VoIP, because it relies on UDP streaming, VoIP exploits use that stateless streaming to their advantage by embedding the attack in the voice/video stream.

This inevitably brings up the discussion of firewalling your VoIP because that seems to have been the answer for every other security issue.  While the firewall will provide some amount of control and monitoring of TCP connections, it will do nothing for the UDP streams that VoIP relies upon.

Yet I have actually had some firewall vendor sales people claim that their firewalls are “VoIP aware” and can identify certain “bad” VoIP packets.  I’m not sure exactly how you can identify bad UDP audio/video data streams, but they claim to have some sort of proprietary methods for doing just that.  Of course, when you attempt to drill down on that “proprietary method” you get essentially stonewalled because it is “proprietary”.  I take that as an indication of sales “smoke and mirrors”.

Then there is the solution of encrypting all VoIP traffic.  I have had a number of clients suggest this as a solution to the security of telephony.  While encryption of all VoIP traffic minimizes the ability to eavesdrop on calls via the network, it does not remove the risk of eavesdropping via compromised endpoints which is much greater than the network risk.  Encryption also does not remove the risk of malware injected via the UDP stream which is the bulk of the real threats to VoIP.  After all of the discussion surrounding encryption, I really see only marginal value in the use of encryption of VoIP traffic from a security perspective.

Also, on page 54, E.2 VoIP Attacks and Vulnerabilities you get this statement.

“VoIP equipment and software are susceptible to vulnerabilities that could allow someone with malicious intents to gain access to your network, intercept and gather customer data, or initiate a Denial Of Service attack.”

I cannot tell you how many IT professionals do not realize the risk presented by VoIP and its infrastructure.  They seem to treat it like the PABXs of old that used to be located in basements next to the telephone carrier’s point of presence (POP) at their organization’s facilities.

Granted, we have moved away from the Windows and Linux versions of call managers that were standard fare when VoIP originally came out.  Most of today’s call managers are based on some proprietary derivative of Linux or Unix stripped down and modified for telephony.  But there are open source solutions that run on Windows and Linux server editions.  The bottom line though is that regardless of what you run, these are still servers no different than any other servers and they need to be properly configured and get regular patching just like any other server.

That is my take on the latest telephony guidance from the Council.  Better than what was produced in 2011 but still lacking in some areas.

Advertisement

Email And PCI Compliance

This is a question we got from the recent PCI Dream Team session.

“If you receive emails with CHD and store them for a defined period — does the exchange infrastructure come in to scope? What are the suggested methods to descope apart from not receiving CHD via emails.”

By definition, if an application processes, stores or transmits sensitive authentication data (SAD) or cardholder data (CHD), it is in scope for PCI compliance.  The ONLY way to remove an application from PCI scope is to NOT process, store or transmit SAD/CHD.  So that should answer the questions presented.

With the question answered, I have written about email before, but I thought I would provide some additional guidance now that a lot of organizations are outsourcing their electronic mail (email) to providers such as Microsoft, Google and others.

Outsourcing email has become all the rage of late because it takes dealing with email off of IT’s plate.  IT people hate email because it is a huge operational pain with all of the problems it creates.  Not only does it typically take a lot of servers to operate, most organizations need a hot failover solution in order to ensure their business operations uninterrupted.  Never minding the fact that it is a problematic application that end users seem to often mess up.  Because of this, most IT operations look to a third party to deal with email and get it off their backs.

Over the years I have heard all of the business arguments as to why organizations need to use email for communications, particularly payments.  The most common of which is that it makes for easy communication with customers because everyone knows how to use it.  Add in file transfer, electronic facsimile delivery, voice messaging, unified communications and its ease of use – it is just too good to not use.  Talk about a business case that appears to be beyond reproach.

Here are the problems with email when it comes to PCI compliance.

The first problem, and it is HUGE, is that there is no way for an organization to obtain PCI scope reduction with email in scope.  By definition, an email solution that contains SAD/CHD, it is in the cardholder data environment (CDE).  You want everything in scope?  Well you got it because any workstation that uses email is at a minimum a “Connected To” system and at worst a CDE system if the end user processes the messages that contain SAD/CHD.  The bottom line is that your organization will not achieve any sort of meaningful scope reduction with email in scope because it brings every workstation in the organization into scope.

The second problem with email in scope is that it provides no real way of securing the information stored in the system.  Yes, inboxes can be individually encrypted, but it is trivial to work around that encryption and gain access to the messages, particularly if it is a shared or group inbox.  As a result, there is no way to effectively comply with the requirements in 3 regarding the encryption of CHD at rest.

Never mind the fact that you have to do something about redacting SAD if that is in messages.  That is because once a transaction is conducted, you are no longer allowed to store SAD.  Information redaction becomes hugely problematic in email systems because of where the data could have been sent unbeknownst to the original recipient as well as what email clients it exists.  This whole situation gets significantly worse if your organization must also comply with the European Union’s General Data Protection Regulation (GDPR).

The third problem is with requirement 4.2 that states:

“Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, SMS, chat, etc.).”

This means that ALL EMAIL MUST BE encrypted at all times including internal and external message transmissions.  While this is easily accomplished for internal users, it becomes problematic for external users that will have to either use: (1) PGP or a similar public key infraustructure (PKI) solution, or use (2) a solution provided by your organization such as Proofpoint or similar to ensure secure message delivery.  I can personally attest to the fact that when I have brought up using PGP, Proofpoint or similar for secure communications, I have heard nothing but complaints from users about how difficult it is to use.  All of a sudden, ease of use goes out of the window.

But outsourced email is the final nail in the coffin for PCI compliance.  When you outsource your email to Microsoft, Google or other public cloud providers, they will tell you that their email solutions are NOT PCI compliant and NEVER WILL BE PCI compliant.  Worse, they will not allow you to assess their email hosting environment for your own PCI assessment.  As a result, there is no way to comply with requirements in 12.8 as well as comply with the card brand requirements of only working with PCI compliant service providers.  Therefore, there is no way to obtain a compliant PCI Report On Compliance (ROC) or self-assessment questionnaire (SAQ).

But what about compensating controls?

Any effort to create compensating controls is a giant bottomless rabbit hole.  You will chase your tail forever trying to come up with ways to compensate for controls that cannot be compensated.

In the end, while email is a great tool with excellent ease of use, it is a tool that will not easily lend itself to PCI compliance.  Only bring it into PCI scope if you absolutely have no other choice.  Othwise, avoid having it in scope like the plague.

Requirement 12.8.2

I got a comment a while back about contracts and PCI compliance.  The two requirements that are relevant in this discuss are 12.8.2 and 12.9.  Requirement 12.8.2 is for all organizations (merchants and service providers) that are being assessed under the PCI DSS.  Requirement 12.9 is only for service providers.

As usual, the clarifications surrounding these requirements were all provided verbally over the years at various PCI Community Meeting presentations and Q&A sessions.  But the overall gist of these requirements can be readily determined.  It just takes a little bit of effort and looking at more than just the PCI DSS.

Requirement 12.8.2 states:

“Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.

Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.”

The Guidance provided for 12.8.2 states:

“The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients. The extent to which the service provider is responsible for the security of cardholder data will depend on the particular service and the agreement between the provider and assessed entity.

In conjunction with Requirement 12.9, this requirement is intended to promote a consistent level of understanding between parties about their applicable PCI DSS responsibilities. For example, the agreement may include the applicable PCI DSS requirements to be maintained as part of the provided service.”

If things are still not clear enough, it helps to look at the ROC Reporting Template to get clarification.  The tests being conducted for a given requirement usually clear up any confusion regarding what is being expected.  There is only one test for 12.8.2 and it states:

“Describe how written agreements for each service provider were observed to include an acknowledgement by service providers that they will maintain all applicable PCI DSS requirements to the extent the service provider handles, has access to, or otherwise stores, processes, or transmits the customer’s cardholder data or sensitive authentication data, or manages the customer’s cardholder data environment on behalf of a customer.”

The first thing to notice in all of these discussions is that nothing in the PCI DSS states that any organization is required to work with a PCI compliant third party.  None of the requirements in 12.8 specify that an Attestation Of Compliance (AOC) be provided.  A lot of QSAs will argue that requirement 12.8.4 requires it, but if you read the test:

“Describe how it was observed that the entity maintains a program to monitor its service providers’ PCI DSS compliance status at least annually.”

There is nothing in that test that explicitly mandates that an AOC is required to monitor third parties.  Granted an AOC is the easiest way to monitor service provider compliance, but there is nothing explicitly calling it out in this test.

So where does this “requirement” originate?  It comes from the merchant agreements with the card brands, specifically Visa and MasterCard.  They require that their merchants only work with third parties that are PCI compliant and can prove that compliance with a Service Provider AOC.  This is why it is important to read and understand the brands’ merchant agreements and their own security programs.  There are a number of key “requirements” that come from those documents that are just as important as what is in the PCI DSS.  So, read them as well as all of the PCI documents.

Getting back to the PCI DSS, what the Council wants QSAs and ISAs to look for in contracts, master service agreements, addendums and any other legal documents that describe the parties’ legal relationship is some sort of acknowledgement between all parties that they will abide by the PCI DSS and ensure that sensitive authentication data (SAD) and cardholder data (CHD) is kept secure.

Where a lot of QSAs/ISAs go wrong is demanding that the words “PCI DSS”, “PCI standards” or other explicit acknowledgement of “PCI” something to appear somewhere in those documents.  The Council has stated a number of times that explicitly using “PCI DSS”, “PCI standards” or “PCI” anything is not required.  It would be great if such documents did, but a lot of legal documents do not because they either predate the PCI DSS or lawyers argue it is not necessary.  That is what led to the Note in both requirements.  The key is the last sentence which explicitly states:

“The acknowledgement does not have to include the exact wording provided in this requirement.”

It is this sentence that the Council always points to and states that this is why explicit statements of PCI or any other direct reference to PCI is not necessary nor required.  My advice is, when in doubt, ask your client’s legal counsel for their legal interpretation of the legal agreements and whether they fell it covers the PCI responsibilities of the parties involved.

That will lead you to the fact that a lot of legal agreements reference the PCI DSS and PCI standards indirectly through language that obligates the parties to follow and comply with “regulatory or other legal requirements”.  The reason this language works is because “other legal requirements” will drag in the card brand legal agreements for taking and processing card payments.  Every card brand has legal agreements for merchants and service providers that explicitly call out that the customer of the brand will maintain PCI compliance for all relevant PCI standards.

Where this discussion becomes problematic is with service providers that do not directly process, store or transmit SAD/CHD such as managed service providers and the like that can affect the security of payments.  That is because they are not directly under the card brands’ legal agreements, so their contracts while using the same “regulatory or other legal requirements” will not necessarily be referencing PCI compliance because they are indirectly involved.  It is in these cases that I rely on getting a PCI AOC from the service provider which then provides the additional assurance that the service provider understands that they need to be PCI compliant.

It is when I cannot obtain an AOC from a service provider that I then explain to my client that this service provider’s environment needs to be assessed as part of their assessment.  Either that or my client needs to find a new PCI compliant service provider.

What a QSA/ISA needs to be looking for in a service provider’s AOC is a couple of things (actually, there are a lot of things, but these are the most important).

First, you need to ensure that the services provided to your client have all been covered by the service provider’s assessment.  Section 2a of the AOC documents the services covered and not covered.  The most common problem found with section 2a is that one or more services used by an organization were not assessed.  If services were not assessed, then you need to notify the service provider and develop a plan of how to handle this situation.

The next thing to review is the locations that were part of the assessment.  It still amazes me the number of AOCs I review where a client’s data center or processing center was not part of the assessment.  It gets worse when you bring this to the attention of the service provider and they get put out or worse, they argue with you over the fact that they must review every facility where a service is conducted.  I am sorry, the PCI SCC and the card brands are the ones that make the rules, I am just the poor assessor that must enforce and live by them.

Finally, you need to review section 2g for all of the services assessed (if they were assessed from section 2a).  Section 2g are a matrix of the 12 PCI DSS sections that explains who is responsible for the various PCI DSS requirements.  From this matrix an organization is to construct their PCI program to fit the controls that they need to implement to be PCI compliant for this service.

There should be a section 2g for every individual service assessed, but in instances where PCI coverage is the same for different services (e.g., SaaS application hosting), you can combine services in section 2g.  However, this is where problems usually are found.  My favorite example of such a problem is the day I found data center co-location and call center services listed in the same matrix.  I am sorry, but those services have very little similarity particularly in PCI controls.  When you encounter this situation, it is usually indicative of a QSAC that does not understand how to deal with service providers and is cutting corners to get the ROC and AOC out the door.  In addition, it also likely indicates a service provider that is just “checking a box” for PCI compliance to placate customers.  But worse is when that service provider is listed on the Visa or MasterCard service provider lists (it is rare, but I have seen it) which then indicates that the brands are also not doing their due diligence in their review of the AOC.

Hopefully, you now better understand requirement 12.8.2.  In a future post I will discuss requirement 12.9.

Shared Services (aka Category 2 In Scope)

All of us on the PCI Dream Team get the following question a lot as we consult with organizations on PCI scoping and network segmentation.

“With the guidance from the SSC at the Community Meeting regarding network isolation (they provided a slide that highlighted key concepts) we are expecting QSAs to dig deep into category 2 systems.  PCI controls are not applied to servers that support infrastructure outside of the CDE on these category 2 systems.  Is the council really suggesting we setup completely dedicated category 2 infrastructure for the CDE?”

For those readers that have forgotten what the PCI scoping categories are here is a quick refresher.

Category 1 systems are those that either: (a) directly process, store or transmit sensitive authentication data (SAD) or cardholder data (CHD), or (b) are on a network segment the same as or directly assessible to those systems that directly process, store or transmit SAD/CHD.  Category 1 systems are those that exist in or create the cardholder data environment (CDE) and are always in scope for PCI compliance.

Category 2 systems are those that do NOT directly process, store or transmit SAD/CHD but provide services to Category 1 systems such as directory services, DNS, DHCP, SIEM, NTP, etc. and are segmented from and have controlled access from/to those Category 1 systems through a firewall and/or jump box.  Category 2 is typically referred to as “Shared Services”, that is, services that are shared between Category 1, Category2 and Category 3 systems.

Category 2 systems include system administrator workstations that access Category 1 systems through a jump box.  Another example of Category 2 systems are workstations that work with Category 1 systems over virtual desktop (VDI) technology.  The reason is that the VDI is a Category 1 system therefore the workstations using the VDI are Category 2.

The bottom line though is that Category 2 systems are always in scope for PCI compliance because they can affect the security and controls of the CDE.

Category 3 systems are those that do not and never can access Category 1 systems in any way including via a jump box.  Only Category 3 systems are out of scope for PCI compliance. .  That said, Category 3 systems can be provided services by Category 2 systems and still be considered out of scope for PCI compliance.

The first part of the question I would like to address is:

“PCI controls are not applied to servers that support infrastructure outside of the CDE on these category 2 systems.”

Category 1 and Category 2 systems are deemed in scope for PCI compliance, so ALL relevant PCI controls are required to be applied to those devices.  With Category 2 systems, there may be a very, very few controls that do not apply, but they will be very, very few if there are any at all.  So, if you are not applying all PCI controls to Category 2 systems you are likely not in PCI compliance.

The next part of the question I would like to address is:

“… we are expecting QSAs to dig deep into category 2 systems.”

QSAs better be assessing Category 2 systems just as rigorously as Category 1 because they are, by definition, in scope for PCI compliance and no different from Category 1 systems.

Finally, there is this question.

“Is the council really suggesting we setup completely dedicated category 2 infrastructure for the CDE?”

If that is how you wish to approach the problem, that is your prerogative.

However, the QSAs I know would tell you to avoid that approach.  That approach only adds complexity, introduces even more chances for human error and usually creates ever more bizarre controls and nonsense that does nothing to improve security.

That is not to say that I have not encountered instances where directory services, DNS, DHCP and other services servers are located inside an organization’s CDE.  But they are connected to other services servers within the organization in Shared Services no different than any others to simplify management of those services.  They are only inside the CDE because of performance or availability issues, not for security reasons.

This is the whole point of Category 2 is to provide an area where such services can be located to serve all categories of systems.  Hence the name “Shared Services” because the services are shared between all of the categories.

That said, it is not unusual to have multiple shared services areas.  I have clients that isolate their directory, DNS and DHCP servers in their own shared services environment.  The SIEM is also isolated in its own area.  The reason is to allow for further granularity of monitoring and control as well as limiting the number of administrative personnel that have access.  They also have shared service areas for internal FTP and mainframe LPARs.  How many shared services network segments your organization will need is all up to your organization and what makes sense.  The bottom line though is to make sure you can monitor and control the shared devices and ensure that you are not putting CDE systems at risk.

Service Provider To A Service Provider

Another good question from our recent PCI Dream Team session.

“Are service providers to a service provider be required to provide report on compliance (ROC) to the service provider in a private cloud scenario?”

It depends.

The reason it depends is because the answer will depend on whether or not the service provider in question directly processes, stores or transmits sensitive authentication data (SAD) or cardholder data (CHD).  While our session this time was on ‘The Cloud’, the cloud has nothing to do with the answer, so the answer will be the same regardless.

If you are unsure if you are a service provider, read this post.  If you are trying to construct a story that gets your out of scope as a service provider, read this post.

Reporting Requirements

Before we can talk about what a service provider needs to provide to a merchant or another service provider, we need to ensure that everyone understands the PCI reporting requirements.

For any service provider that directly processes, stores or transmits SAD or CHD, if the volume of Visa/MasterCard/Discover transactions is greater than or equal to 300,000, then the service provider must go through a PCI assessment that produces a Service Provider ROC and Attestation Of Compliance (AOC).

For service providers that directly process, store or transmit less than 300K transactions or does not directly process, store or transmit, then that service provider can self-assess using the Service Provider SAQ D and related AOC.

Another key point regarding reporting that needs to be made is that there are differences between the Merchant AOC and the Service Provider AOC.  It is very important that service providers use the Service Provider AOC and not the Merchant AOC.

I still get too many Merchant AOCs from service providers.  Most often this is because these service providers are also merchants and they mistakenly believe their merchant PCI assessment serves as their service provider PCI assessment.  Not so!  These service providers need two assessments.  One that covers their merchant payment processes (usually a very small assessment) and one that covers their service provider processes which is usually the larger of the two.

The first key AOC difference is that the Service Provider AOC has a section 2a that discusses what services were assessed in the assessment and what services were not assessed.  This is important to customers of service providers because it allows them to ensure that all of their services have been assessed in this AOC.  If they have not, then the customer knows to ask the service provider for additional AOCs that cover those services.

The other key AOC difference is section 2g which documents the requirements tested during the assessment for each service assessed from section 2a.  The PCI SSC requires that individual 2g sections be used if the services assessed have different requirements matrices.

Finally, section 2c is also very important to customers as it explains what locations were included in the assessment.  I cannot tell you the number of AOCs I have reviewed from large service providers only to find that the location used to service my client was not part of the service provider’s assessment.  As a result, the AOC has no use to my client in their assessment.

Who Needs What?

Under the PCI rules, a service provider is required to provide their Service Provider AOC to all merchants and other service providers to which they provide services.  Yet time and again as a QSA, I end up in fights with service providers who refuse to provide their AOC to my clients.

This requirement of providing an AOC is all about proper vendor management and ensuring there are no gaps in meeting controls responsibilities.  The Service Provider’s AOC has a matrix in section 2g for each service assessed that explains what requirements the service provider is responsible, what requirements are the customer’s responsibility and those requirements where there is shared responsibility.  Without that matrix, a customer has no way to understand their responsibilities in maintain PCI compliance between themselves and their service providers.

Please notice that nowhere have a I mentioned sending anyone the ROC, only the AOC.  As you will recall, the question involved the sending of the ROC to another service provider.  That is not to say that you cannot send your ROC, it is just not required by the PCI SSC.

As a QSA, I have encountered a few situations where section 2g is not clear enough and have asked a service provider for their ROC to ensure that my client properly sets up their controls to mesh with the service provider’s controls.  If the service provider was unwilling to provide their ROC or even the section needed, I hold a lot of conference calls to clarify the situation.

With that said, if you want your organization listed on either the Visa or MasterCard Global Service Provider lists, you will have to submit your ROC and AOC to those card brands (as well as some money) to get on those lists.  If you are a service provider and can use the Service Provider SAQ D and you want to get listed on either brand’s service provider list, you will have to go through the ROC assessment process.  Visa and MasterCard will only accept a ROC for listing on their sites.

Hopefully you now understand what is required and what is not.

One Last Time On Disaster Recovery

I have written three posts on this topic, yet it still comes up.

• Disaster Recovery Sites and PCI
• Disaster Recovery and PCI
• Business Continuity and PCI

Here are the Cliff Notes from those posts.

Hot sites are always in scope for PCI compliance because they can support failover on demand.

Cold sites are never in scope for PCI compliance because there is nothing there that would be in scope.

Warm sites are only in scope if they have cardholder data (CHD) processed, stored or transmitted from that site.

There are nuances with all of this, so if you want more information, read the three posts.

PCI Council Advises On Approved PTS Devices

I received this communication from the Council today.

“PCI SSC has learned that certain PTS POI devices are being sold that use the version numbers associated with the Approved Devices but materially differ from the Approved Devices (“Substitute Devices”).

To help ensure that entities deploying PTS POI devices deploy equipment that is the same as the PCI approved version, PCI SSC recommends:

• Entities purchasing devices only purchase devices that are compliant with the requirements for labeling and displaying the hardware and firmware/application versions as stipulated above. Furthermore, the version numbers must be in accordance with the version numbers listed on the PCI SSC website for that specific device model name/number. Devices not meeting the aforementioned should not be considered the PCI approved product version.
• Purchase orders for point-of-interaction PIN-acceptance devices should specify compliance to the applicable PCI Point of Interaction Security Requirements document.  This should include specific vendor attestation as shown in the attached form that the PTS devices have been assessed and approved by PCI SSC.

Read the bulletin for more information: PCI Security Standards Council bulletin on purchasing PCI approved devices”

Sounds like a vendor or few are making changes to their POI and not following processes to document those changes to the Council.

So be careful out there with what POI are PCI compliant and those that are not compliant.

Open Source

One of the questions we received at the last PCI Dream Team session was:

“What about open source for 6.5?”

I am sure the person asking wanted to know whether open source payment solutions must comply with the PCI DSS requirements in 6.5.x?

The quick and simple answer is of course, ‘Yes’!  Why would it not?  It is source code after all, so therefore it must comply with the requirements in 6.5.x (as well as other requirements in section 6 and throughout the PCI DSS).  The PCI DSS does differentiate between different sources of application code.  For PCI compliance purposes, code is code is code, regardless of the source.

Now what does come into play is whether or not the PA-DSS validation standard applies to an application.  As PA-DSS relates to open source, I wrote about that over eight years ago, but it is still relevant today.  For the purposes of this post, I am not talking about PA-DSS validated applications.

The next question a QSA typically gets is, “Well 6.5 only applies to internet-facing payment applications, right?”

Wrong!  Any payment application needs to meet the requirements in 6.5.x whether it is internet-facing or internal facing.  Also, it does not matter whether a browser is involved or not although a significant number of the requirements in 6.5.x are related to browser-based applications.

But ensuring open source is PCI compliant goes beyond just 6.5.x.  There are other requirements that, at a minimum, must be applied as well.  Not every requirement in a section or group or requirements may apply, but some will be needed to be covered depending on how the application works.

• Section 3 related to encryption of stored data and encryption key management;
• Section 4 related to encryption of communications;
• Requirements 6.1 and 6.2 for patching and vulnerability management. This can become problematic for open source because as time goes on applications can develop vulnerabilities that the developer community does not address.  This is most likely because the community moved on and your application became an orphan;
• Requirements 6.4 for application development. Remember, just because your organization did not develop the application, if it is not PA-DSS validated, then it is your responsibility to ensure the code securely processes, stores or transmits sensitive authentication data and/or cardholder data;
• Requirement 6.6 is also in play regardless of whether or not the application is browser-based. At a minimum, code reviews must be performed.  If the application is browser-based, then you can add in a Web application firewall (WAF) for additional security;
• Sections 7 and 8 related to access control and user management; and
• Section10 related to application log data.

Remember, every time a new release of your open source solution becomes available, you have to go through all of this all over again if you intend to use the new release.

So those of you thinking that you can somehow leverage open source to reduce your PCI compliance footprint, think again.  All you have done is outsourced the development of your solution.  The rest is still on you.  In the end, it is really not much of a savings.