2021 Government IT Symposium

I am honored to have been granted the privilege to speak at the 2021 Government IT Symposium this coming November.

I will be speaking (virtually) on Tuesday, November 16, at 145PM CT/1945 UTC.  My presentation is titled ‘PCI Compliance – Yes, That Includes Governments’.  The reason for my session is that while the PCI DSS has been around for over 15 years, government entities still question how it applies to them and why.  In my years doing assessments for government entities, I have found there are a number of unique situations that complicate their assessments.  In my session I will cover the basics of the PCI DSS and provide a walk through of the potential traps that tend to trip up government entities.

If you want to register for this symposium, go here to register.

I look forward to seeing you there.

Advertisement

PCI Dream Team LIVE! Is Coming In October

The PCI Dream Team will be appearing LIVE at the (ISC)² Security Congress in Orlando this Fall, Monday, October 18 through Wednesday, October 20, 2021.   Our session is scheduled for Tuesday, October 19, at 11:45 AM ET/ 1545 UTC.

While we will be live at the conference, you can also attend the conference and our session virtually.  So other than training budget limitations, there is no other good reason you cannot join us.

As usual, we will be taking questions live and via email at pcidreamteam AT gmail DOT com.  We also monitor Twitter if you use #pcidreamteam.

We are expecting our usual lively discussion of all topics PCI and other security standards if time allows.

We really are looking forward to physically seeing people at the conference.

An Inadvertent Service Provider

A discussion came up on the last PCI Dream Team session regarding situations at universities that have bookstores and cafeterias operated by third parties on their networks and those vendors processing payment card transactions.  QSAs encounter this situation not only at universities and colleges, but also with hospitals, health clinics and large corporations.

The Situation

As organizations focus on customer and employee perks, QSAs encounter third parties operating business outlets within a variety of organizations.  These businesses include coffee shops, convenience stores, dry cleaners, bookstores, restaurants, cafeterias, parking ramps, travel agencies, pharmacies, health clubs and a whole host of other businesses.  Of course, all of these third parties accept payment cards for their services and need a way to process those cards.  Organizations offering these perks have existing wired and wireless infrastructure that get leveraged to connect these third parties to the internet and their payment processors.  Thus, bringing that network and everything attached to that network into scope for PCI compliance.

As a result, this situation creates a PCI compliance problem because the organization is now a service provider as well as a merchant.  The organization thought by outsourcing these businesses it was reducing PCI scope not increasing scope.  But scope increases because since they are now considered a service provider, they must provide each of these third parties with a Service Provider Attestation Of Compliance (AOC) for that network connectivity.

But it can and does get worse.  I have encountered situations where the outsourcing organization provides help desk, firewalls and other support services for these third parties, further complicating their PCI compliance responsibilities.

What Do You Do? Option 1 – Get Out Of Scope

There are some ways to get out of scope, but these can be complex and/or expensive.

The first way to get out of scope is to force all of your third parties to get their own network connectivity from their own internet service provider (ISP).  The problem with this is that an ISP will likely have to run wire into your facilities to make those connections.  That can be disruptive as well as expensive and complicated due to locations within existing buildings.  And what if each business wants their own ISP because of a contract relationship?  That will mean multiple ISPs tearing up your facilities.  Not necessarily the best situation.

The most extreme solution to get out of scope is for the outsourcing organization to implement carrier equipment and become a “carrier” to these third parties.  I have had a few clients go down this road, but it is not cheap and can also be more trouble than it is worth.  However, for a university or large hospital/clinic complex with lots of third parties, this solution can actually be a cheaper route to implement and operate.

But the beauty of these solutions is that your organization is totally out of scope so there are no service provider PCI assessment requirements.

What Do You Do? Option 2 – Reduce Scope

There are also a couple of ways to reduce scope.  But reducing scope requires at a minimum the creation of a Service Provider SAQ D and AOC.

The quickest and easiest way to reduce scope is that the outsourcing organization can implement end-to-end encryption between the third party’s connection and the internet.  However, this adds the requirements in section 4 to the assessment as well as keeps the endpoints in scope for PCI compliance.

Another option to reduce scope is to require these third parties to implement encryption from their operation to anyone outside of the outsourcing organization.  While this seems simple, it usually never is simple.  Never mind the fact that if that encryption is ever stopped (most times without your knowledge), the outsourcing organization’s network is back in scope.  Typically, when this gets brought up as a solution, a lot of the third parties balk or say they do not know how to encrypt their connections.  Never mind the fact of the complexity of proving that the outsourcing organization does not have encryption keys and that every third party connection is encrypted becomes problematic.  It ends up more trouble than it is worth.

The only good news about reduced scope is that you only need to fill out a Service Provider SAQ D and AOC because you have no idea the transaction volumes being processed by any of these third parties.  That said though, it is additional paperwork that needs to be filled out annually and given to all your third parties.

Heaven help you though if you offer firewall, help desk and other support services in addition to connectivity.  Those just complicate your compliance and reporting efforts.  All I can say is, if you can stop offering those services, stop.  If you cannot stop those services, then be prepared to document and report on the PCI compliance of each of those services.  That can be done in a single assessment, but the AOC must cover each of those services provided individually in a separate section 2g.

Never mind the fact that if some of those services offered give your organization insight into the number of transactions processed by your third parties such as you provide payment processing under one or more of your merchant identifiers, you may end up having to conduct a Service Provider Report On Compliance (ROC) because the transaction volume exceeds one of the card brands’ annual service provider transaction volumes.

There you have it on third parties and their payments on your network.

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.

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.

Can I Use SSAE 18 SOC 2 Reports? Part 2

In the last post I discussed what the SOC reports are and what, in general, to look for in a SOC 2/3 report.  Now I want to take you through the more detailed analysis of the SOC reporting so that you can understand why it might not give you the result you desire and how to address that fact.

How Do I Analyze The SOC Report?

Based on the testing in the ‘Information Provided by Independent Service Auditor’ section, you are going to need to map that testing into the PCI ROC tests, if they even fit.  I typically use the Prioritized Approach spreadsheet to do this as it provides a way of documenting the requirements covered and a quick dashboard regarding what is covered.

As you reviewed the domains listed under the SOC 3 report, I am sure you thought; “What is not to like?  It looks like most of what I need for PCI is covered.”  But you would be wrong.  You will find after you map the controls from any SOC 2 report that covers all the TSP domains into the Prioritized Approach that the report will likely only cover around 20% to 25% of the PCI DSS requirements.  That is because the level of detail in the SOC tests are just not as detailed as they are in the PCI DSS.  As a result, SOC 2 reporting does not provide the kind of reliance you need to respond to all of the relevant PCI DSS requirements.

For example, while SOC will likely test that password controls are in place, you will be unable to ascertain if the organization enforces seven character or greater password lengths, password complexity, nor if they require passwords to be changed every 90 days or less.  Let alone if the special requirements for vendor password management are enforced.  It is these missing details that create the coverage problems with using the SOC reporting results.

The same can be said for change management.  When tested, the SOC report will likely call out a lot about change management, but not at the level of detail required in the PCI DSS for requirements under 6.4.  You will also find that coverage in requirements 1 and 2 regarding network and server configurations will be lacking in specificity to meet the PCI DSS testing.

Now as a QSA, you have a decision to make.  Can you accept only 20% to 25% of coverage of PCI DSS requirements as being PCI compliant?  I know I cannot.  I need much more to work with before I can get comfortable that a SOC report provides the necessary coverage for PCI compliance.

Now What?

You and your client have expended all this effort and are no closer to the result desired than when this process started.

So, what to do next?

Work with your service providers that provide you SOC reports to include testing that adds the PCI DSS details that are missing.  There will likely be a bit of push back from these service providers because adding testing to their SOC reports will cause the cost of their SOC reports to increase, sometimes significantly.  So be prepared for it.

What you need to do is to have their auditors add the necessary testing details to the description of controls and then have them test that they are in place.  Examples include:

• Password length, complexity, change frequency and the procedures followed to perform a password reset.
• Details surrounding privileged and general user management including provisioning, management approvals, users are implemented with least privilege and users are disabled or removed when terminated.
• Changes tested for segregation of duties between developers and operations, segregation of test, QA and production environments, production data not used for testing, developers do not have unrestricted access to production, test data and accounts removed before applications are promoted to production, changes document impact, they are appropriately authorized, they have been tested, they have been vulnerability assessed and they document backout procedures.
• If encryption is used to protect data, document the algorithms used, are key custodian agreements in place, are split key processes in place if performing manual key management, indicate if a hardware security module (HSM) is used and are keys changed when their crypto-periods expire or they are believed to be compromised.
• Document the configuration standards that are followed by device classes such as firewalls, switches, servers and test that they have been implemented.
• Document that anti-virus is implemented on systems commonly affected by viruses and malware, what the anti-virus solution is that is implemented, the anti-virus solution cannot be disabled and that the anti-virus solution is actively running on all systems it is installed.
• Document that vulnerability scanning is performed, how often scanning is performed and that vulnerabilities are remediated.
• Document that penetration testing is performed, how often penetration testing is performed and that findings are remediated.
• Document that log data is collected from all devices, it is reviewed at least daily and that it contains a date/time stamp, device name, type of log entry and other relevant information.

There are a lot of other areas that could be added to the SOC report, but these are, in my opinion, the bare minimum that need to be added to make the SOC report more relevant for PCI.  I am trying to balance the amount of additional information needed versus the cost of providing it in the SOC report.

By adding all of this will it cover all of the gaps between SOC and PCI?  No.  But it should give your QSA significantly more comfort that the controls in place to meet PCI than what is currently being provided by CPAs.

When A Client Refuses To Provide Evidence

As a QSA there are occasions when a client tells you that you cannot be allowed to have copies of evidence.  The most common occurrence is with firewall and intrusion detection/prevention configurations.  But there are odd instances as well for things like software development lifecycle documentation and information security policies where it makes no sense.

As a “recovering” penetration tester, I get some of these requests.  I once got into a financial institution because their network engineer wanted advice on their firewall configuration and posted the configuration on a forum for people to provide advice.  So, people are right to be concerned.  That said, qualified security assessor companies (QSAC) are required to provide a secured storage area for storing client evidence, so it’s not like evidence is stored just anywhere.

To be clear, a QSA is required to obtain evidence that supports their assessment of the PCI DSS requirements.  The reason is for the PCI SSC’s assessor quality management (AQM) process.  The Council has the right to review not only the redacted Report On Compliance (ROC) and Attestation Of Compliance (AOC), but also the evidence that supports the ROC.  This has always been the case under the AQM process, but it has only been recently that the Council has started exercising that right and reviewing samples of evidence.

Regardless of all of these precautions and requirements, there are still those times when a client refuses to provide copies of the evidence.  What is a QSA to do?

The Council has provided QSAs with an option when this situation happens, it sounds simple, but is not always as simple as it appears.

When a client refuses the QSA to leave with the necessary evidence, the QSA must then require the client to securely store the evidence reviewed for a maximum of three years and agree to make that evidence available if the Council pulls their ROC for review under the QSAC’s AQM.

The key to this solution is that they client must store exactly what the QSA reviewed for a period of three years.  In the case of a firewall configuration, the client needs to create a human readable file (i.e., text, PDF, screen shots, etc.) and then store that file securely either on their network, a CD/DVD or even a USB thumb drive.  A lot of clients create an encrypted archive for storing this information which is a very good idea.  I have heard of a few situations where the client misplaced the archive resulting in a finding against the QSAC for not being able to provide the evidence to the PCI SSC for review.

This evidence solution is likely outside of the original contract with the QSA.  As a result, the QSA will have to make an addendum to their original agreement to cover this situation.  Expect a bit of legal work to come up with getting such an agreement and getting the client to agree with it.

But suppose the client refuses the conditions of the addendum.  What then?

This is where the client’s acquiring bank comes into the picture.  A client’s acquiring bank is required to arbitrate such disputes between QSAs and their client.  Whatever the acquiring bank decides, the QSA needs to make sure that they get the decision in writing (e.g., email, letter, etc.) and put that decision in with the rest of their evidence.  A QSA should also write up a brief memo to provide the background of the situation so that anyone going back and reviewing the evidence understands what happened and therefore has some context as to why the bank issued their decision.

There you have it.  Another situation addressed.

PCI Compliance And Financial Institutions

I remember being at one of the early PCI Community Meetings and someone from the PCI SSC promised that the PCI DSS would be periodically updated to reflect changing business conditions as well as changing threats.  Here we are more than a decade later, and we have version 3.2 of the DSS, but it has been changed more for changes in threats and very little for business.

Their rationale was that they wanted to minimize the number of compensating control worksheets (CCW) that would be needed for the majority of organizations.  This was in response to v1 of the PCI DSS that required that data encryption keys change annually.  Most large merchants who were participating organizations (PO) complained that it was taking six months to a year or more to encrypt their transaction databases and files.  Requiring annual key changes would leave those databases and files at risk because they would always be in a state of perpetual decryption/encryption.  As a result, almost everyone had a CCW for that requirement.  So, the Council changed the requirement to require the changing of encryption keys when they were believed to be compromised or if one or more persons who know the keys leave the company or change roles.

The reason I bring this up is that I have been dealing with financial institutions and their PCI compliance issues for the last few years.  If there is anything more frustrating, it is trying to apply a standard written for merchants to organizations that are not merchants.  It seems like every time I turn around; a requirement needs a CCW, particularly when concerning requirement 3.4.

I am sure the Council will point to requirement 3.2 as their token change that took into account issuers.  But that does nothing for the other requirements that financial institutions struggle.  The biggest reason a lot of the PCI requirements are a struggle is that financial institutions are in the business of; surprise, surprise; processing, storing and transmitting cardholder data.  That IS their business.  3.2 was a great change for issuers, but a lot of the rest of the PCI DSS is a huge pain for a financial institution without a lot of CCWs and the blessings of the requisite card brand(s).

Let us look at a few requirements where CCWs are needed when assessing an FI.

3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) – this can be very problematic for financial institutions.  The reason is that while they can encrypt or tokenize the data, they also need to decrypt/detokenize it as well.  In a lot of cases, they need to do those operations quickly and very often.  It is not that the FIs do not want to protect the information, it is just that they have some unique issues in meeting PCI requirements.

The best example of this situation is debit cards.  Debit cards must be tied to a demand deposit account (DDA) such as a checking or savings account.  That means somewhere there must be a mapping of the debit card into the core application system.  But to process transactions from the card networks when customers use their cards, the PAN must be decrypted/de-tokenized so that the payment can be approved or declined.  This decryption/de-tokenization process needs to meet a timing standard, so adding to the processing time is usually not an option.  As a result, it is not unusual to find that the PAN to DDA mapping file is not encrypted or tokenized.

6.4.3 Production data (live PANs) are not used for testing or development – when part of your business is all about processing, storing and transmitting sensitive authentication data (SAD) and/or cardholder data (CHD), using a few card brand test accounts like a merchant would use for testing is not going to work.  Particularly when you are testing with one of the card brands to certify your application.  In those instances, the FI and brands are going to demand the use of a large and varied set of PANs to ensure that systems are functioning properly.  The only way to do that is with live data from production.

3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization

3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card used to verify card-not-present transactions) after authorization

3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block after authorization.  – requirement 3.2 addresses that issuers that have a business reason to retain sensitive authentication data (SAD) can retain it.  However, 3.2.1, 3.2.2 and 3.2.3 say that all of this data cannot be stored right after authorization. These requirements then go on to say the QSA must inspect incoming transaction data, log data, databases, etc.  Well, guess what?  The incoming transaction data always has SAD in it of some form because the FI has to authorize the transaction.  As I said earlier, databases can have it because of the speed required to authorize.  This is the FIs’ business, yet the standard does not recognize this fact.

The bottom line is that the PCI DSS does not reflect the realities of financial institutions.  As a result, FIs require numerous CCWs to meet the PCI DSS requirements.  As I stated at the beginning, the Council promised that they would address such issues to make CCWs the exception not the rule.  Well, here we are, and in the FI world CCWs are commonplace.  And as we move forward, it will be FIs that will be the focus of the standard, not merchants.  Merchants will very soon be out of the payment card data business altogether with the exception of their POI.  So, it only makes sense to adapt the PCI DSS to securing FIs.

We have separate PCI DSS and AOC documents for service providers.  Maybe we need separate such documents in addition to revised requirements for financial institutions?

Seems like a good discussion topic to bring up at the upcoming Community Meeting.

Service Provider AOCs and Section 2g

It is becoming obvious that there are a lot of QSAs out there did not get the message when v3 of the PCI DSS came out and the new AOC for service providers was introduced.  This has been a big topic at the last few community meetings as well and recently became a big topic with a number of my clients as I continue to see service provider AOCs that are not correct.  I have even mentioned this problem already in a post about service providers, but the problem continues.

As a result, I have decided this is a great time to discuss the problem and get everyone to ensure it is fixed so that we stop the arguments over something that is clearly documented in the service provider AOC form and needs to be done correctly.  Because there is no excuse for messing this up.

Section 2a

Before we get to the actual problem, we need to talk about section 2a in the service provider AOC as it drives the problem.

In section 2a of the service provider AOC, a QSA is call out in the ‘Name of service(s) assessed’ and to check every box in the ‘Type of Service(s) assessed’ for every service named as part of the service provider’s PCI assessment.

QSAs seem to be doing very well in checking the appropriate boxes for ‘Type of Service(s) assessed’ on the AOCs that I encounter.  However for the ‘Name of service(s) not assessed’, QSAs seem to not necessarily doing quite as well.  The reason will become obvious when I discuss section 2g.

One important note though.  When checking the ‘Others’ box (or any of the ‘Other’ boxes), please make sure to list ALL the other services that were assessed and NEVER, EVER use “etc” in that explanation.  All the services in the ‘Others’ category MUST BE listed individually and specifically.  Again, this will become obvious as to why when we get to section 2g.

And before we move on, I get questions about cloud services, i.e., SaaS, PaaS and IaaS.  Those are services and should be listed as such in the ‘Name of service(s) assessed’.

Section 2g

Notice that shaded ‘Note’ that is in bold and italics that states:

“One table to be completed for each service covered by this AOC. Additional copies of this section are available on the PCI SSC website.”

What this note means is you need to have the same number of section 2g’s as you have named services in section 2a.  And this is where a lot of QSAs and their QA reviewers are going wrong with their service provider AOCs

For example, if you have named five services in 2a, there had better be five pages of 2g filled out.  One for each of those five named services.  By the same token, if you are relying on check boxes under the ‘Type of Service(s) assessed’ section to define the services covered, then you should call those out separately in 2g.

The bottom line though is that, however a QSA breaks things out, there must be multiple 2g sections for each individual service provided.

In some very rare instances there can be some services that might have the same coverages/responsibilities for the requirements in the matrix and those may be combined into one table.  The Council has even said as much in clarifying this form.  However the Council has also been very clear that when combining those services into one 2g section, those services MUST have EXACTLY the same responsibilities and that is where a lot of QSAs get into trouble.  So the recommendation I would make is just do one 2g for every service and stop trying to combine things.

Now the QSAs that I have had discussions (arguments) with over their flawed service provider AOCs always bring up the fact that the AOC Word document is locked and they cannot make changes.  I always point them back to that ‘Note’ in 2g which states:

“Additional copies of this section are available on the PCI SSC website.”

According to the guidance provided by the Council at the Community Meetings, QSAs are to append those additional 2g sections to the end of the AOC.

That said, some of us in the QSA community have unlocked the Word document (NOT approved by the Council) and just copy section 2g and insert it inline in the AOC for the number of services we need sections for and fill them out.

One final note about section 2g.  Please follow the instructions to the letter when filling out the table/matrix for the service.  I cannot tell you the number of those that I encounter where ‘Partial’ or ‘None’ are checked and then there is nothing documented in the ‘Justification’ column.  The instructions are very clear in how you are supposed to fill the ‘Justification’ column out so there is no excuse for leaving it blank.

And for the merchants that have to deal with these service provider AOCs.  It is up to you to police these documents.  If you receive an AOC and it is not properly filled out, it is up to you to point out your concerns to the service provider.  If the service provider does not address your concerns, you have a couple of options at your disposal.

• Contact the PCI SSC with your concerns at qsa@pcisecuritystandards.org. Document your concern(s) in your email as well as including the AOC in question.
• If the service provider is listed on either the Visa or MasterCard service provider lists on their respective Web site, you should notify them as well. This is because both of those card brands should have caught this error before listing the service provider on their Web site.  For Visa, go to http://www.visa.com/splisting/learnmore.html and use the appropriate email address for your region under the PCI DSS Validated Service Providers row.  For MasterCard, use the pcireports@mastercard.com email address and as with the Council document your concern(s) in an email as well as including the AOC in question.

By contacting the Council, you will provide the Council feedback that a QSAC is not conducting their assessments for service providers appropriately and that the Council may need to conduct an assessor quality management (AQM) process for that QSAC.

Notifying the card brands will do two things.  It will point out a potential flaw in their service provider listing process that needs to be addressed.  But it could also potentially put the service provider in a different status on the card brands’ lists.

The Council Speaks On A Number Of Topics

The Council had a Webinar session for QSAs and ISAs on Thursday, December 15. It was a great session, but at only an hour, there were a lot of questions that went unanswered.  The following were the more notable discussion topics.

Not Tested

The Council got the message and they are working on new wording for the AOCs as well as some guidance for “Not Tested” and how it can be used and not impact PCI compliance.  They expect to have something issued in the first quarter of 2017.

Network Segmentation and Scoping

This was a very hot topic and drew a lot of questions and some useful answers as well as generating a slew of new questions.

We got a definition of “purpose-built controls”.  There really is not any change here in what the Council has told QSAs and ISAs in the past regarding segmentation.  The bottom line is that “purpose-built controls” are those controls that segment one network from another network.  That can be firewall rules, access control lists (ACL) or any other controls that control or limit the communications from one network to another network.  I posed a question regarding encryption such as TLS and IPSec as still being a valid segmentation control, but it did not get answered.  I am assuming that it still is a valid control given the Council’s statement that nothing has changed, but until we have explicit confirmation, that still is an assumption, not a fact.

The Council answered a number of questions regarding whether or not in-scope devices can be on the same network segment as out of scope devices can co-exist.  As usual, we go the “it depends” discussion.  The bottom line is that it depends on the threat presented by the out of scope devices to those in-scope.  If an organization has lax security controls over all of their networks and devices, then I would be hesitant to allow out of scope devices to be on the same network segment as in-scope devices.

One of the most amazing discussions on this topic was an answer given regarding whether or not a device that has only an outbound connection from the cardholder data environment (CDE) can be considered out of scope.  Under the Open PCI Scoping Toolkit, this would be categorized as a 2C system.  The Council started out with their stock answer of “it depends” and then clarified that answer.  The answer given was that while the system would be in scope because it is connected to the CDE, what requirements it would need to comply with would depend on the risk presented by the system to the CDE.  This seemed to give organizations an opportunity to argue a minimization of requirements.  I am sure this will result in a lot of arguments between QSAs, ISAs and their assessees in the future.

As a funny aside, the Council mentioned the “three hop rule” and then feigned ignorance as to where it came from.  As I pointed out in my post, it was from the 2014 Community Meeting in Orlando.

Not-Listed Encryption Solutions

This guidance is a train wreck and just seems to keep getting worse.  The Council gave a lot of answers to questions, but it just seemed like they were digging an ever deeper hole, not filling it in.

The biggest news is that the Non-Listed Encrypted Solution Assessment (NESA) document should be available for review in the first quarter of 2017.

The next biggest news was the Council reconfirming that this is only guidance/recommendations and not some new process that is mandatory.  They even made sure to tell everyone attending that QSAs are NOT to hold up an organization’s ROC/SAQ over not having a NESA for their E2EE solution.  So if an E2EE solution does not have a NESA, then the fallback based on a lack of guidance from the Council is to preform whatever procedures that the merchant’s acquiring bank recommends.

The purpose of this Information Supplement the Council stated was to provide QSAs, merchants, service providers and banks with the Council’s acceptable way to deal with assessing E2EE solutions.  While on its face this statement and rationale makes sense, it does not make sense from the standpoint that the organizations driving the E2EE solutions are the banks and processors that have partnered with the E2EE solution providers.  Given that the banks and processors are the same organizations driving PCI compliance of the merchants that consume those E2EE solutions it seems rather odd that they would be questioning what is acceptable for PCI compliance of their approved E2EE solutions.

At the end of the day, it just seems that this NESA process is a solution looking for a problem and that the only problem the process really solves is getting more E2EE solutions to just finish the NESA and validate as a P2PE solution.

Until the banks and processors get behind the NESA process, I see this effort as dead on arrival.

So it sounds like it will be a busy first quarter for the Council.

The Council stated that the slide deck for this session will be posted to the Portal sometime after the first of the year.