25
Jan
19

Where Is EMV When You Need It?

Juniper Research (not Juniper Networks) issued a report recently that stated that card not present (CNP) fraud would be $130B by 2023.  In response, there were a lot of people asking where EMV was to address this issue?  Apparently there are a lot of people that are confused about EMV including some that are directly involved in PCI compliance.

First a bit of background.

People need to understand that EMV as it is implemented anywhere today was originally developed for eliminating or minimizing card present (CP) fraud.  Europe became a hotbed of CP fraud in the early 1990s after the fall of the Iron Curtain.  To address this problem, Europay, MasterCard and Visa Europe (hence the acronym “EMV”) joined forces to develop the standard in an effort to minimize the CP fraud problem in Europe.  EMV was introduced in the UK in 1996 and continued to rollout throughout Europe for the next decade.

Then there is the term “Chip and PIN” that people inadvertently confuse with EMV.  Using an EMV card with a PIN is not a requirement as consumers in the US have discovered.  The term “Chip and PIN” comes from that original UK rollout.  The banks in the UK decided on requiring a cardholder to not only put their card into the card terminal but also to require a personal identification number (i.e., PIN) in order to complete a transaction.  That standard has continued pretty much throughout the world with the exception of the US.

The next key thing to understand about EMV is that it is no more secure than the magnetic stripe it replaced.  I know that fact might shock some people given all of the press EMV has gotten regarding security.  Somewhere along the line, people began to believe that EMV by itself was more secure.  I believe a lot of this misunderstanding was the result of other security technologies that were bundled as countries converted to EMV.

The biggest security feature was the requirement of a PIN for transactions.  A PIN is essentially implementation of multi-factor authentication (MFA).  The EMV card is the something you have, and the PIN is something you know.  Both of which are also known as two factor authentication (2FA).  2FA is great for dramatically reducing CP fraud, but still does not protect the data being transmitted and likely stored by any point of sale (POS) solution.

What came next in the evolution of EMV was the addition of end-to-end encryption (E2EE) between the card terminal or point of interaction (POI) and the transaction gateway or processor.  E2EE encrypts the sensitive authentication data (SAD) transmission from the POI to the processor meaning that any devices or networks between the two cannot access the data unless they have the encryption keys (which they will not if E2EE is properly implemented).

The final security feature that came to EMV was the addition of tokenization.  Tokenization takes the primary account number (PAN) and converts it to a token which can then be returned to the merchant’s POS solution without the worry that it was storing cardholder data (CHD).  Tokenization can be either be performed at the POI or by the processor upon completion of a transaction (most common).

With that as the background, I think most readers can start to understand why EMV and its currently used security features are not going to address the CNP fraud problem.  All of those security features we are familiar require a CP environment and exactly how does that translate into a CNP environment?  The answer is, they do not translate, at least easily.

It turns out that we have been here before with EMV although most people are probably not aware of that fact.  Around 2000 to 2002, a few UK banks and a card brand thought about addressing the growing CNP fraud issue with EMV.

In the UK, Barclays and Standard Chartered came up with competing application programming interface (API) standards for eCommerce sites to use.  Both Barclays and Standard Chartered paired their APIs with card readers that connected to PCs.  Their solutions relied on the new EMV cards that were being issued in the UK and used Chip and PIN for conducting transactions.

At around the same time in the US, American Express was rolling out their first iteration of their Blue card.  That card had a chip although it did not conform to the EMV standard.  Customers that were in that Blue rollout also got a handy USB chip reader along with the card.  As with the implementations in the UK, American Express also relied on Chip and PIN for completing transactions.

The idea with all of the schemes was to have consumers connect the reader to their computer and install some software for the reader.  Then when making a purchase online the consumer would insert their EMV card into the reader, key their PIN through the computer’s keyboard and complete the purchase.  No different than in a traditional brick and mortar store.

Unfortunately, there were some issues with all of these approaches.  The largest of which was that the APIs were all different.  As a result, the consumer could not make a secured payment unless the online merchant supported the payment API the consumer had installed on their local PC.  In the case of American Express, they had signed on Amazon as a merchant, but Amazon was a very small but up and coming fish in the eCommerce world at the time.  In the case of the UK, the banks had only signed a very few small online UK merchants.  As a result, with no large eCommerce merchants on board no API gained critical mass to win out.  The end result was that by 2003 the EMV CNP experiment had effectively died.

To those observant readers, I earlier alluded to the fact that there are other EMV security features that might be useful for addressing CNP fraud.

There are two features in the EMV standard that could be used and those are dynamic PAN and dynamic card verification value (CVV).  These two EMV fields are included in every EMV card but are not currently used.  The reason is that using them would require significant programming on the transaction processor’s end to make them work.  But using them would still require a card reader solution for eCommerce given the cards in circulation today.

Obviously with CNP, what is needed is a solution that would not require a card reader and therefore a standard API.

In the age of mobile applications, it would be relatively easy for an app to provide the dynamic PAN and dynamic CVV for entry into a Web site.  Granted this app would have to communicate with a bank or processor to ensure the generation of valid dynamic values, but it should be no more difficult than what RSA or Symantec do for multifactor authentication.

Another option would be to provide a browser widget or a whole PC application that would generate the dynamic PAN and dynamic CVV while the user was purchasing items online.

But what about people that do not have smartphones or prefer physical cards?  What immediately came to my mind is something like the FUZE, Edge or Dynamics cards.  While all of these are currently not EMV capable, they are expected to be at some point.  They all come with displays that could easily display the dynamic PAN and dynamic CVV just as from a smartphone.  Unfortunately, all of these electronic cards require a smartphone but could probably be easily adapted to program from a Web site through a PC since they need to be charged.

The bottom line is that there are solutions to the problem.

Advertisements
19
Dec
18

The Remote Worker Dilemma

We received the following question during the last PCI Dream Team session back in October.

“We have a call center that sometimes takes a credit card numbers from customers.  Our senior management keeps pushing us to come up with a work-from-home option for some of our call center employees in case of DR and Business Continuity.  We keep telling them that PCI says that all components of such a home setup is subject to PCI standards and thus is impossible, Have any of you seen any solution that would allow this?”

Since that session the Council released the new telephony information supplement that has created a stir in the PCI community.  I wrote about the new information supplement a few weeks back so I will not cover that here, but I will rely on it to answer this question.

First and foremost, remote workers are allowed under the PCI DSS as there are no requirements that prohibit it.  However, there are PCI-related considerations when you want to implement such an approach.

You will obviously need to develop PCI compliance policies, standards and procedures that will support remote working.  If your organization already has policies, standards and procedures for clean desks, secured work area, protection of information, proper handling of sensitive authentication data (SAD) or cardholder data (CHD), then you probably have the bulk of what you need.  You will need somewhere in your documentation to allow for your organization to conduct annual and spot inspections of remote working environments for compliance with organization policies, standards and procedures.

If you do not have those policies, standards and procedures, then you will need to get those published, approved and all employees and contractors to formally acknowledge them.  Most organizations’ policies, standards and procedures work just fine for corporate environments but do not consider the situation when workers are not in a corporate facility.  As a result, it is not unusual to see organizations develop policies, standards and procedures that take into account that the remote workers’ working environment might not necessarily be as secure as those at a corporate controlled office.

The annual inspection can consist of the remote worker taking a picture of their work environment and filling out a form that ensures the remote worker is complying with relevant organizational policies, standards and procedures as related to remote working.  I have clients that have remote workers fill out the relevant PCI SAQ depending on their remote worker environment.  In all cases, the employee signs the form/AOC stating that they are compliant with all relevant policies, standards and procedures.

It is when the organization has questions, issues or concern with a remote worker is when the spot inspection clause becomes useful.  The spot inspection capability allows organization management or an auditor to go to the remote worker’s location and personally examine the work area to ensure that it complies with all policies, standards and procedures.

With the paperwork out of the way, let us now discuss the technical challenges related to remote workers.  The goal here is to minimize the PCI scope of the remote worker’s configuration.

The easiest way to do this is using a point-to-point encryption (P2PE) validated solution or an end-to-end encryption (E2EE) solution for the keying of SAD/CHD.  Of course, this means that you will have to ensure that your application will work properly with a P2PE/E2EE solution which further means not allowing SAD/CHD to be keyed through anything other than a P2PE/E2EE validated terminal also referred to as the point of interaction (POI).  This can also mean pairing the P2PE/E2EE solution with tokenization if your application is expecting CHD back at the end of the transaction.

But P2PE/E2EE only addresses the transaction, not the conversation that results in the transaction.  To reduce costs of remote workers, organizations typically implement a softphone.  Softphones are great.  However, they result in a PCI scoping problem.  As a reminder, when a telephone system is used for having conversations involving SAD/CHD, it puts that system and networks in the cardholder data environment (CDE) also known as a Category 1 system.  As a result, any other system that connects to the telephone system is now also part of the CDE.  Since a soft phone cannot be readily logically or physically segmented from the workstation it connects, it drags the workstation into PCI scope regardless of whether or not SAD/CHD is discussed.

The solution to the softphone issue is to use a physical VoIP phone with a headset.  But it is not as simple as just swapping in a physical phone for the softphone.  That physical phone needs to be on a logically or physically segmented network that does not include any devices that you desire to be out of PCI scope.  It is that segmentation that drives up the cost of the remote worker configuration because you now need to have a managed network device to allow for separate VLANs or physically separate network connections.  Not impossible, just costlier than delivering a cable/DSL modem with four Ethernet ports to the remote worker’s location and being done.

As a result of all of this, it is not unusual for organizations that allow for remote workers that need to be PCI compliant to supply those remote workers with a US Department of Defense compliant document shredder, computer or workstation, router, network switch, display(s), keyboard(s), secure POI(s), telephone(s) and any other equipment necessary to ensure compliance with the PCI standards.

In addition to this, there may be other requirements due to the European Union’s General Data Protection Requirement (GDPR), Health Insurance Portability and Accountability Act (HIPAA) or other security or privacy regulations or requirements.

07
Dec
18

Requirement 12.9

I discussed requirement 12.8.2 in a prior post which applies to all organizations being PCI assessed.  Let us now turn our attention to requirement 12.9 which only applies to organizations that are service providers.  If you are unsure if you are a service provider, see this post and this post.

As a refresher, requirement 12.9 states:

“Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits 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 for 12.9 states:

“In conjunction with Requirement 12.8.2, this requirement is intended to promote a consistent level of understanding between service providers and their customers about their applicable PCI DSS responsibilities. The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients.

The service provider’s internal policies and procedures related to their customer engagement process and any templates used for written agreements should include provision of an applicable PCI DSS acknowledgement to their customers. The method by which the service provider provides written acknowledgment should be agreed between the provider and their customers.”

As with 12.8.2, we are told in the requirement’s Note that “exact wording” is not required.  So those of you looking for “exact wording” need to move beyond that fact.

The key though to 12.9 is that the service provider’s contract, master service agreement or whatever other legal documents used need to ensure that they acknowledge their requirements to protect the payment card data they process, store, transmit or could affect the security of the payment card data.

It is that last statement that catches a lot of service providers.  Like it or not, even if a service provider does not directly come into contact with sensitive authentication data (SAD) or cardholder data (CHD), if they can affect the security of that data, they need to be PCI compliant.  This usually catches managed service providers (MSP) such as those that manage/monitor firewalls, network devices, servers and security incident and event management (SIEM) solutions and they will argue incessantly that they do not need to be PCI compliant.  Unfortunately for them, the Council, the card brands and QSAs will tell them otherwise.

In the end requirement 12.9 is all about service providers providing the necessary information and documentation such that the organizations they provide those services can comply with requirement 12.8.2.  To that end, there are two tests for 12.9 in the ROC Reporting Template and those tests state:

“Identify the service provider’s policies and procedures reviewed to verify that the service provider acknowledges in writing to customers that the service provider will maintain all applicable PCI DSS requirements to the extent the service provider possesses or otherwise stores, processes, or transmits cardholder data on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.” and

“Describe how the templates used for written agreement verified that the service provider acknowledges in writing to customers that the service provider will maintain all applicable PCI DSS requirements to the extent the service provider possesses or otherwise stores, processes, or transmits cardholder data on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.”

The first test is all about having some sort of legal agreement in place that the service provider acknowledges that they need to comply with all relevant PCI standards.  Where this test broke new ground is the addition of the statement:

“… or to the extent that they could impact the security of the customer’s cardholder data environment.”

This statement came in as part of v3.2 of the PCI DSS.  It was added to the test to clarify to QSAs/ISAs that service providers are also those that can influence the security of payment information (e.g., managed service providers with access to PCI in scope devices).

The second test is to ensure that service providers that rely on boilerplate agreements ensure that those boilerplates contain the necessary language that requires the service provider to maintain their PCI compliance.  The idea being that if it is in the boilerplate, it is less likely to be removed.

I am sure a lot of you are questioning who ensures that the boilerplate language does not get removed or modified?  That is one of the purposes of 12.8.2 on the customer’s side of the equation.  This is why the testing meshes with each other.  The service provider’s QSA/ISA makes sure that the language is in the standard agreements.  The customers’ QSA/ISA makes sure that the language still remains in the agreements.  Each are a check on the other.

I cannot stress enough the importance of QSAs/ISAs filling out the service provider’s AOC correctly let alone using the correct form and instructing their service provider clients to give the AOC to any customer that requests the AOC.  There is nothing more frustrating than service providers who refuse to provide their service provider AOC.  It is not a secret as many apparently believe.  And please, do not refer your customers to either the Visa or MasterCard service provider lists.  That is also not what your customer or their QSA/ISA needs for their assessment.  Yes, it does confirm that your organization is PCI compliant, but tells the customer nothing about their PCI compliance responsibilities when using your services.  That is the whole point of why customers need your AOC.  Get over it and put your service provider AOC in your customer portal like you do your SOC1 and SOC2 reports.

There you have it about requirements 12.8.2 and 12.9.

30
Nov
18

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.

26
Nov
18

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.

21
Nov
18

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.

16
Nov
18

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.




Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

February 2019
M T W T F S S
« Jan    
 123
45678910
11121314151617
18192021222324
25262728  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 2,054 other followers

Advertisements