Author Archive for PCI Guru



07
Apr
16

Just Because You Can Wait, Does Not Mean You Will Be Judged “Compliant”

Based on some of the questions I have received since my post on v3.2, apparently a lot of people missed this little point in my last post about the Council’s Webinar.

“The final key point on this topic that the Council could not stress enough was, just because the deadline has been pushed out was no justification for an organization to wait until the last minute before addressing these critical vulnerabilities.  If an organization can meet the June 30, 2016 deadline, then they should meet that deadline.  If they need until December 31, 2016 to convert, then they need to mitigate the risk until December 31, 2016 when they can drop SSL and early TLS.  But waiting for the sake of waiting because the deadline is in 2018 is unacceptable and needs to be called out as ‘Not In Place’ by QSAs.”

For all of you in denial out there, make sure you truly read that last sentence.

Yes folks.  Your QSA can mark you as non-compliant if your organization does not have a very, very, very good and legitimate documented business reason for not meeting the June 30, 2016 deadline for getting rid of SSL and early TLS.

Want to argue that point?  Fine.  Then you can expect your QSA to put you in arbitration with your acquiring bank on this subject.  If your acquiring bank is willing to sign off on your lame delay, then so be it.  But if your bank denies your request, then expect to be put into remediation by your bank and possibly even be fined for your arrogance.

And one more thing we have since clarified.  If you can meet the June 30, 2016 deadline, then you only need mitigation and migration plans for your QSA.  If you are not going to meet the 2016 deadline, then in addition to the plans your organization will also need to provide a compensating control worksheet (CCW) for 4.1.  Even if you are filing your Report On Compliance (ROC) before June 30, 2016, you still need to provide your QSA with the plans and the CCW if you will miss the 2016 deadline.

So for all of you out there that thought you had dodged a bullet, there is another bullet with your name on it.  You have been warned.

01
Apr
16

The Council Speaks About v3.2

If you missed it, do not feel bad.  I too had to be told by friends and colleagues that the PCI SSC was having a Webinar on Thursday, March 31, to discuss the upcoming changes to the PCI DSS and PA-DSS as well as changes to other areas as a result.  Apparently the Webinar was announced in the March issue of the QSA newsletter.

To begin their presentation, the Council made a big deal out of explaining why they are dumping the three year update cycle.  The bottom line about this is that they feel the PCI DSS and PA-DSS are mature and therefore any future updates will be evolutionary not revolutionary as they have been in the past.  As a result, we can expect more minor changes more often.  Much like when the PCI DSS started out and we quickly got v1.1 followed by v1.2.

PCI DSS v3.2

The real piece of news here was that two-factor authentication (TFA) is going to be required for all administrative access to the cardholder data environment (CDE) regardless of whether that access is from the internal network or a remote network.  I am sure this is in response to the number of breaches that involved administrators being spear phished.

Speaking of TFA, the Council indicated that they are going to switch terminology from “two-factor” authentication to “multi-factor” authentication (MFA).  However, they were very clear when they discussed this change in terminology that they still mean the three factor model of something you know, something you have, and something you are.  Their rationale on this change is to align the DSS with industry terminology.  In the Q&A they got a lot of questions on this change as most security professionals said that clients would view MFA as including two sets of credentials versus TFA which has truly different factors.  So we will see if the MFA decision stands when the new standard is released.

In addition, the Council outlined some other key changes we can expect to see in the latest version of the DSS.  These are:

  • Two new Appendices are being added to the PCI DSS. The first of which discusses the SSL/early TLS issues.  The second is the incorporation of the Designated Entities Supplemental Validation (DESV) requirements into the DSS.
  • Allowing the display of the PAN to be more than just the first six digits and the last four digits to align the PCI DSS with the coming changes to ISO 7812 which will increase the issuer identification number (IIN) from six digits to eight digits.
  • Adding a number of additional requirements for service providers including: documentation of cryptographic architecture, detection/reporting on critical security control systems, penetration testing to confirm segmentation every six months, establishment of a formal PCI compliance program, and quarterly confirmation that personnel are following all security policies, standards and procedures.
  • Periodic testing that all change control policies, standards and procedures are in place and operating as designed. This is the first of many business as usual (BAU) requirements that will be added to the PCI DSS.

More On SSL/Early TLS

The Council gave a bit more information regarding why they extended the deadline on SSL and early TLS out to June 30, 2018.  As no surprise, the reason for the extension was push back from a variety of sources that found the 2016 deadline too short to convert.

I know from my own experience, I have a few clients that have contracts that do not allow them to make such changes without consultation with every customer impacted.  In one case, it was going to take almost nine months just to consult with all of their impacted customers and then another seven months to implement the changes into production.  In the perfect scenario, they would have cut over around September 2016, but they said past experience indicated a more likely date would have been July 2017 at the earliest.

The presenter reiterated that service providers must meet the June 30, 2016 deadline.

Also discussed was how ASVs are supposed to deal with SSL and early TLS issues.  Until June 30, 2016, if an ASV encounters SSL or early TLS vulnerabilities, the ASV must obtain the mitigation plan or a letter from their customer attesting that a mitigation plan has been developed and the date when the customer will have addressed the vulnerabilities related to SSL and/or early TLS.  The ASV does not need to assess the mitigation plan as the assessment of the mitigation plan is something the organization’s QSA must perform as part of the assessment process.

The final key point on this topic that the Council could not stress enough was, just because the deadline has been pushed out was no justification for an organization to wait until the last minute before addressing these critical vulnerabilities.  If an organization can meet the June 30, 2016 deadline, then they should meet that deadline.  If they need until December 31, 2016 to convert, then they need to mitigate the risk until December 31, 2016 when they can drop SSL and early TLS.  But waiting for the sake of waiting because the deadline is in 2018 is unacceptable and needs to be called out as ‘Not In Place’ by QSAs.

Related to this discussion was the fact that vulnerability management still needed to be addressed through the mitigation.  So if new vulnerabilities to SSL and/or early TLS are discovered while the organization is remediating their implementations of SSL/early TLS, the organization must still comply with requirements 6.2 and 11.2.

PA-DSS v3.2

No news is good news here.  There will be little change to the PA-DSS standard other than to align it with PCI DSS v3.2.

However two significant changes are coming to an application’s Implementation Guide (IG).

The IG will now be required to address debugging logs that contain PAN data.  Those debugging logs will be required to be protected, debugging will need to be immediately disabled once it is no longer needed and the debugging log data must be securely deleted as soon as it is no longer needed.

The IG will also be required to discuss the secure implementation of patches and updates to the application.

PA-DSS v3.1 dealt with the SSL/early TLS issue, so the Council felt that there would be no changes regarding that topic.  That said, they did address the question as to whether or not TLS v1.1 is considered secure and laid out how TLS v1.1 needed to be configured to be secure.  That configuration included:

  • Disable weak ciphers and cipher suites such as MD5, SHA-1 and RC4.
  • Use sufficient key sizes.
  • Prevent fallback to SSL or TLS v1.0.

AQM Update

The Council indicated that the PCI DSS v3.2 and the Report On Compliance (ROC) reporting templates will be released simultaneously for the first time.  Timing for these documents will be late April 2016.  No specific date was provided.

On the PA-DSS side, the Council stated that the v3.2 Report On Validation (ROV) reporting template and the standard will be released in May 2016.  Again, no specific date was provided.

Cutover to v3.2 for both standards was discussed with the PCI DSS cutover being the more specific.  PCI DSS v3.2 will go active upon release with sun setting of v3.1 occurring in October 2016 on whatever day matches the release date.  Cutover and sun setting on PA-DSS will be announced with the release of the v3.2 standard.  Use of both standards and reporting templates can occur immediately but we were reminded that everyone must cutover by the relevant sunset dates.

The Council also indicated that any relevant v3 FAQs will also be updated when the new standards are released.

ROC/ROV Personalization

The final point discussed under the AQM banner was the personalization of the ROC and ROV reporting templates by QSACs and PA-QSACs.  According to the presenter, the Council is hearing complaints from banks and the brands about the “over personalization” of ROC and ROV reports.

The Council stated that they understood the desire of QSACs and PA-QSACs to put their logos on the reports as well as making other “minor” changes to make the reports reflective of their organization.  However, banks and the card brands have been complaining that some of the personalization done had made the reports different enough from the original templates as to make them difficult to quickly review and process.

As a result, the Council has felt it necessary to issue guidelines on what personalization of the ROC and ROV templates is allowed.  Under these new guidelines:

  • Adding a title page to the report templates is allowed.
  • Adding a company’s logo to the report header is allowed.
  • No changes are allowed to any of the reports footers.

If you did miss this Webinar, the Council stated they were recording the session and it will be available on their PCI Portal sometime in the next few days.

31
Mar
16

Council Releases PCI v3.2 Dates

The dates given are not hard and fast such as Tuesday, April 26, more like general points in time such as “late April”.  But at least they are providing a form of schedule for the release of the new PCI DSS and PA-DSS standards an the retirement of v3.1 standards.

See their blog post for all the details.

28
Mar
16

Is The FTC Investigation A Witch Hunt?

With the FTC’s announcement of their PCI fact finding effort a few weeks back, the questions being asked in the PCI assessor community these days are:

“Is this a ‘witch hunt’ by the FTC?” and

“Are they coming after QSACs?”

First, a bit of an update since my last posting on this subject.  I have been able to determine from my sources that the nine qualified security assessor companies (QSAC) that were selected by the FTC were randomly selected from a list of QSACs provided by the PCI Security Standards Council to the FTC.  Based on that information, I have to assume that the nine QSACs selected were just the unlucky winners of this FTC fact finding effort.

Another tidbit I was able to glean from some friends in the nine QSACs is that the FTC had yet to send them the official orders for complying with the study, so the 45 day clock has not necessarily started.  That information is at least a couple of weeks old, so I would assume that they have received official notice from the FTC.

Witch Hunt?

If you review the questions being asked it would seem to be the start of a witch hunt.  Those of us in the PCI industry know how the QSACs will like respond to these questions and how those responses will be interpreted.

However, in further reviewing the questions, the FTC is allowing QSACs to explain their answers, so hopefully those explanations will satisfy the FTC about some of the answers they will receive.  Some of the questions that could create problems/concerns are:

  • For each year of the Applicable Time Period, state the number and percentage of clients for which You completed a Compliance Assessment and for which You declined to provide: (1) a “Compliant” designation on the Attestation of Compliance (“AOC”); or (2) an “In place” designation on the final Report on Compliance (“ROC”).
  • For each year of the Applicable Time Period, state the number and percentage of clients for which You completed a Compliance Assessment and for which You provided: (1) a “Non-compliant” designation on the AOC; or (2) a “Not in place” designation on the ROC.
  • the method by which the scope of Compliance Assessments is determined, including but not limited to, the extent to which a client or any third party, such as the PCI Security Standards Council (“PCI SSC”), a Payment Card Network, Acquiring Bank, or Issuing Bank, is permitted to provide input into the scoping of Compliance Assessments
  • the process by which the Company determines whether to use sampling as part of a Compliance Assessment, including, but not limited to, a description of the methodology used to determine that any sample is sufficiently large to assure that controls are implemented as expected. As part of Your response, provide copies of all policies and procedure related to sampling, as well as all documents related to a representative Compliance Assessment that included sampling, including all communications between the Company and the client or any third party, such as PCI SSC, a Payment Card Network, an Acquiring Bank, or an Issuing Bank;
  • the methodology and tools the Company uses to perform Compliance Assessments;
  • the guidelines and policies for interviewing a client’s employees as part of a Compliance Assessment. As part of Your response, identify any PCI DSS requirement for which client employee interviews alone could establish whether a client had satisfied the requirement;
  • the extent to which the Company communicates with clients in determining the adequacy of any compensating control. As part of Your response, provide all documents related to a representative Compliance Assessment that considered a compensating control, including all communications between the Company and the client or any third party such as PCI SSC, a Payment Card Network, an Issuing Bank or an Acquiring Bank;
  • Provide: a copy of the Compliance Assessment with the completion date closest to January 31, 2015; and a copy of a Compliance Assessment completed in 2015 that is representative of the Compliance Assessment that the Company performs. For each Compliance Assessment provided in response to this specification, the Company shall also include a copy of any contract with the client for which the Compliance Assessment was performed, all notes, test results, bidding materials, communications with the client and any other third parties, such as the PCI SSC, a Payment Card Network, an Issuing Bank or an Acquiring Bank, draft reports, the final ROC, and the AOC.

The biggest problem I see at the moment is with this last bullet.  All QSACs have non-disclosure agreements (NDA) in place between them and their clients that only allow the PCI SSC access to reports for the purposes of quality assurance assessments (AQM).  This sort of NDA has been mandated by the Council since the release of v2 of the PCI DSS.  There are no provisions for federal government agencies to have access to a client’s ROC or AOC.

As a result, I am sure there will be a lot of legal wrangling over turning over unredacted ROCs and AOCs to the FTC.  If the FTC does allow redaction of “sensitive information”, then the legal wrangling will be over what is “sensitive” information.  ROCs and AOCs contain a lot of sensitive information that will eventually become part of the public record.  If the FTC does not take appropriate measures to control access to that information, an attacker that accesses that archive of ROCs and AOCs will have a gorgeous road map as to how to hack the merchants and service providers that the ROCs and AOCs cover.

Another area that will be highly contentious will be the QSACs providing information on the tools they use for their assessments.  This sort of information is highly proprietary and guarded by QSACs.  If it is released by the FTC it could remove some of the competitive advantages of QSACs.

It will be interesting to see the responses to scoping.  The Council has been struggling to give guidance in this area for years.  It is so bad that an offshoot of the PCI scoping special interest group (SIG) issued their own Open PCI Scoping Toolkit a number of years back to provide guidance to the PCI community.

Finally, the question regarding discussions with the Council, banks, card brands and the like will also be interesting to see documented.  I know that QSAs from my firm discuss a lot of PCI compliance issues amongst ourselves as well as with banks and the brands.  We also have questions submitted to the Council from time to time when we do not have clear guidance.  However, in talking with other QSAs from other firms, this seems to be more an exception and not the rule.

The bottom line on the witch hunt question is that I do not see the QSACs as the primary entities in the crosshairs of the FTC.  If anyone is in the crosshairs, it is the card brands and acquiring banks.  The Council is driven predominately by the card brands and their Participating Organizations (PO).  The banks are driven by regulatory requirements and recommendations from the brands.

Are QSACs In The Crosshairs?

As I just alluded to above, I do not thing that QSACs are directly in the crosshairs.  But they could be depending on the answers and explanations the FTC receives as well as what happens with this study going forward.

The unfortunate thing about the nine QSACs selected is that there are a number of notable QSACs missing from the list.  QSACs that those of us in the PCI community know would have extreme difficulty being put under the scrutiny of this FTC fact finding mission.  Yes, they would have nice responses to the questionnaire, but they would have difficulty supporting those great responses with their work papers and other evidence being requested.

Even with the nine selected I am sure there will be some embarrassing disclosures from the QSACs that have been asked to respond.  But for most of those embarrassments the QSACs can ultimately point to the Council and say they were told by the Council to do what they did.  That is not a good answer from a public disclosure perspective, but it is the truth.

Likely Results

If I had to look down the road and see where this is headed, I likely see a mess.  The FTC is coming to this party a day late and a dollar short.  That is because the days of the large merchant data breaches are likely coming to an end.  Why?

Most Level 1 and 2 merchants have implemented or are in the process of implementing either a point-to-point encryption (P2PE) or an end-to-end encryption (E2EE) solution paired with tokenization.  These solutions encrypt at the swipe/dip of a card at the terminal or point of interaction (POI) and return a token back to the merchants’ applications at the transaction’s completion.  These implementations are either complete or will be completed by the end of 2016.  As such, the days of getting data from large merchants’ databases and POS systems have for the most part come to an end.  For merchants that have implemented these solutions, the only device they will have that is in scope is the POI.

The result of these projects are that any attack would have to compromise the POI which is typically controlled by the transaction processor, not the merchant.  Not that such an attack cannot be done, just that its rate of success at the moment is very low given the complexity of compromising a processor as well as creating an acceptable rogue POI payload.

I will not go into detail, but I know a lot of you are asking why replacing the POI is not an option?  The reason that attack is not viable is that the P2PE/E2EE solutions all provide some form of tracking the POI for a variety of reasons.  As a result, merely replacing the POI with a rogue POI is not an easy task and would also require compromising the processor.

The bottom line is that any results that the FTC comes up with will likely be impacting Level 3 and 4 merchants.  Not that such merchants are necessarily small by any sense of the word.  I know of retailers that generate hundreds of millions of dollars in revenue but do less than a million card transactions in a year.

I could easily see that FTC saying that all merchants must periodically submit to an independent evaluation of their security controls where that is evaluated against the PCI DSS or some other security standard.  I would assume that truly small merchants will push back on such a requirement pretty hard, so I would also assume that the FTC will set some sort of transaction limit so that those truly small merchants do not have to incur that expense.

I could also see the FTC or some other government agency taking over the PCI compliance program.  While I think that would bring an unnecessarily level of bureaucracy to the PCI game, it would seem to be a likely outcome.  Whether or not QSACs would be forced to turn over their compliance function to such a government operation will be interesting to see play out.  One could envision something similar to the compliance operations within the FDIC, OCC and other financial institution regulatory bodies used as a model.

The net is that the FTC is again, coming to this situation late.  Most of the problem will resolve itself in a year or two making the headlines go away.  However, the FTC will use its “study” as a way to justify cleaning up a questionable or bad process.  A process that will have to radically change as merchants essentially get out of the card data business.

My advice to the FTC is to let nature take its course.  The breaches of the past have lead the industry to change itself and significantly reduce the risk.  A better effort would be for the FTC to get the processors and card brands to push for adoption of P2PE/E2EE and tokenization across the board.  That would minimize the risk to merchants and only leave processors and banks at risk.

But my advice is rational and that is not typically how government institutions operate because they need to show the public that they are doing something.  As a result, they tend to over react and do things that are no longer required all in the name of proving that they deserve to remain in business.

It will definitely be interesting to see how this all plays out.

09
Mar
16

The FTC Enters The Fray

On Monday, March 7, the United States Federal Trade Commission (FTC) issued a news release that I am sure got a lot of notice by practice leaders of the PCI qualified security assessor companies (QSAC). On Friday, March 4, the FTC commissioners decided in a 4-0 vote to compel the following QSACs to respond to a 6(b) Special Report order.

  • Foresite MSP, LLC;
  • Freed Maxick CPAs, P.C.;
  • GuidePoint Security, LLC;
  • Mandiant;
  • NDB LLP;
  • PricewaterhouseCoopers LLP;
  • SecurityMetrics;
  • Sword and Shield Enterprise Security, Inc.; and
  • Verizon Enterprise Solutions (also known as CyberTrust)

The first thing that is notable in my mind is that some of the big players in the PCI assessment business are absent from this QSAC list. I am not sure how the FTC arrived at this QSAC list, but it would be interesting to know their methodology.

But even more interesting and concerning is the information the FTC is requesting. From their request, here is a sample of some of the questions they are asking and the information they are seeking.

  • For each year of the Applicable Time Period, state the number and percentage of clients for which You completed a Compliance Assessment and for which You declined to provide: a “Compliant” designation on the Attestation of Compliance (“AOC”); or an “In place” designation on the final Report on Compliance (“ROC”).
  • For each year of the Applicable Time Period, state the number and percentage of clients for which You completed a Compliance Assessment and for which You provided: a “Non-compliant” designation on the AOC; or a “Not in place” designation on the ROC.
  • The extent to which the Company communicates with clients in determining the adequacy of any compensating control. As part of Your response, provide all documents related to a representative Compliance Assessment that considered a compensating control, including all communications between the Company and the client or any third party such as PCI SSC, a Payment Card Network, an Issuing Bank or an Acquiring Bank.
  • The policies and procedures for completing a Report on Compliance (“ROC”), including, but not limited to a discussion of whether a draft report is created, whether that draft is shared with the client or any third party such as PCI SSC, a Payment Card Network, an Issuing Bank or an Acquiring Bank, whether the Company accepts input on the draft from the client or any third party, and whether the Company ever makes changes to the draft report based upon the client or other third parties’ input. As part of Your response, provide all documents relating to a representative Compliance Assessment in which You provided a draft of the report to the client and/or any third parties, including a copy of the draft report, any communications with the client or third parties about the draft report, and the final ROC.
  • Provide: a copy of the Compliance Assessment with the completion date closest to January 31, 2015; and a copy of a Compliance Assessment completed in 2015 that is representative of the Compliance Assessment that the Company performs. For each Compliance Assessment provided in response to this specification, the Company shall also include a copy of any contract with the client for which the Compliance Assessment was performed, all notes, test results, bidding materials, communications with the client and any other third parties, such as the PCI SSC, a Payment Card Network, an Issuing Bank or an Acquiring Bank, draft reports, the final ROC, and the AOC.
  • State whether the Company ever identifies deficiencies in a client’s network during a Compliance Assessment and gives the client the opportunity to remediate the deficiency before the Company completes its final ROC. If so, provide all documents relating to a representative Assessment where the Company gave the client an opportunity to remediate before completing the ROC, including any communications between the Company and the client or any third parties such as PCI SSC, a Payment Card Network, an Issuing Bank or an Acquiring Bank, and the final ROC and AOC.
  • State whether the Company ever identifies deficiencies in a client’s network during a Compliance Assessment and issues a final ROC before the deficiencies are remedied based on assurances that the client will remedy the deficiencies in the future. As part of Your response, provide copies of all policies and procedure related to remedying deficiencies.
  • State whether the Company has any policies or procedures relating to potential conflicts of interest, including, but not limited to, any policies that prevent the Company from providing Compliance Assessments to clients to which it has also provided another type of service, or that concern the marketing or provision of other services to clients for which You have provided a Compliance Assessment. As part of Your response, provide copies of all relevant policies and procedures.
  • State the annual number of the Company’s Compliance Assessment clients that have suffered a Breach in the year following the Company’s completion of the Assessment for each year of the Applicable Time Period. For each such client, state whether it was subsequently determined not to be PCI compliant and provide the date of the initial Compliance Assessment and any communications between the Company and client or any third parties such as PCI SSC, a Payment Card Network, an Issuing Bank or an Acquiring Bank related to the Breach.

All of these questions lead one to believe that the FTC is looking to confirm that the PCI assessment process is a sham.

It will be very interesting to see how the FTC interprets the results of this effort. However, based on these questions and how I know they will end up being answered, I would venture to say that the result will be the government getting into the data security game with regulations.

18
Feb
16

The Council Surprises

So I posted my thoughts on where I thought the PCI SSC was headed with v4 of the PCI DSS and today the Council announced there apparently will be no v4. Instead we will get v3.2 of the PCI DSS and PA-DSS. And those new standards will be out sometime in the next month or two.

Read all about it on their blog post.

Not sure what to say or think as they have apparently decide the three year model for standards updates no longer needs to be followed after beating into our heads for the last seven years.

13
Feb
16

Crystal Ball Time

I was recently reminded that we are in year three of the current PCI DSS version. According to the PCI SSC’s standard lifecycle, that means the Council is starting to work on version 4 of the PCI DSS and PA-DSS.

So what is coming in version 4 of the PCI DSS? The Guru and his fellow PCI Wizards have some thoughts.

Business As Usual

I have written about this before. Everyone is betting that business as usual (BAU) will make its official appearance in the next version of the PCI DSS. If the past is any indication, BAU will most likely be a “best practice” until June 30, 2018 and then required thereafter.

For those that have forgotten, BAU was introduced as a concept with v3 of the PCI DSS. Pages 13 and 14 of the PCI DSS discuss the concept of BAU. The idea being to get organizations to integrate certain requirements of the PCI DSS into their organizational procedures to better ensure the security of cardholder data (CHD).

When BAU was first discussed back in 2013, I was able to identify at least 213 requirements that could be considered as BAU requirements (277 if you include Appendix A). Samples of BAU requirements include:

  • 1.2.a Examine diagram(s) and observe network configurations to verify that a current network diagram exists and that it documents all connections to the cardholder data environment, including any wireless networks,
  • 2.2.b Identify any enabled insecure services, daemons, or protocols and interview personnel to verify they are justified per documented configuration standards,
  • 1.a Examine the data-retention and disposal policies, procedures and processes,
  • 1 For a sample of system components including all operating system types commonly affected by malicious software, verify that anti-virus software is deployed if applicable anti-virus technology exists,
  • 6.3.b Observe processes and interview personnel to verify that follow-up to exceptions and anomalies is performed,
  • 2.1.a Review the scan reports and verify that four quarterly internal scans occurred in the most recent 12-month period, and
  • 8.1 Verify that a list of service providers is maintained.

Essentially, all the prospective BAU requirements are those that have some sort of timing involved for evaluating them.

Not only will adding in BAU be at issue, but I am guessing that the Council will probably reduce their use of the words “periodic” and “periodically” in the next version of the DSS. That is because with BAU they will likely begin to recommend actual minimum time frames for conducting these procedures. Known timings in v3 include annually, quarterly, daily, whenever changes occur and my personal favorite, whenever “significant” changes occur. Which means it will be all the more important for organizations to define what a “significant” change means in their environment.

But the introduction of BAU will likely not totally wipe out the use of “periodic” in the DSS. As a result, organizations will still have to define for those requirements that use “periodic” or “periodically” what the period is based on their risk assessment.

The bottom line is that if you have not been thinking ahead you need to get thinking ahead as to how BAU is going to impact your organization.

Requirement 9.9

New with v3 was the addition of requirement 9.9 which focuses on managing the risks to the card terminal or point of interaction (POI). Originally dismissed by most organizations as an annoyance, recent events with Safeway, other merchants and ATMs, security of the POI has come into laser-like focus. And with more and more merchants implementing point-to-point encryption (P2PE) or end-to-end encryption (E2EE), the security of the POI becomes all the more important as it is the only device that remains in-scope for the merchant. It is believed that with all of the issues with POI that have occurred, the Council will focus on beefing up 9.9 to address these higher risks by defining review schedules.

The first requirement that merchants need to deal with much better than they have is 9.9.1 which addresses maintaining an accurate inventory of POI. If a merchant has not implemented P2PE/E2EE, then the risk that a POI is swapped out for one that has been tampered with is extremely high. Tampering of POI is typically done such that the POI does not appear to have been tampered with such as installing a USB drive to collect data or installing revised software in the POI.

The quickest and easiest way to identify swapped out POI is to periodically review your POI inventory and make sure that all the serial numbers of those POI in use are the same as the numbers on your inventory. If they are not, then you should take that POI out of service and get a trustworthy one from your transaction processor.

Another control that you should use is tamper proof tape over the seams of the POI. If someone opens the POI, the tape will be torn and it should be obvious that the POI has been tampered with.

Earlier I distinguished merchant that have implemented P2PE/E2EE from those that have not implemented it. So what, if anything, should merchants with P2PE/E2EE implemented be doing? P2PE/E2EE solutions require the injection of an initial key into the terminal as well as recording a device number. If any of that information changes, the POI will not work. So if the terminal is swapped out, it will not work without the processor properly configuring the POI. This does not mean that the merchant does not have to manage their POI inventory, it just means that reviewing that inventory does not need to occur as often.

So how often should POI be reviewed against inventory? For merchants that have not implemented P2PE/E2EE, I would recommend no less than weekly. However, I do have clients that review their POI at every manager shift change. These are clients that have had POI swapped out and/or tampered with. Merchants that have implemented P2PE/E2EE should review their POI inventory at least semi-annually if not quarterly.

The next area that will likely be enhanced is requirement 9.9.2 which addresses the inspection of devices. I would anticipate that merchants will now be required to develop detailed procedures for the examination of POI by their retail management and cashiers.

But unlike with 9.9.1, this will not be broken down by those merchants that have and have not implemented P2PE/E2EE. Why? Because of terminal overlays that can be placed on top of certain POI and go unnoticed. These overlays can collect CHD regardless of whether P2PE/E2EE is implemented. As a result, examination of POI will likely be required to be done daily if not more often based on the assessed risk.

For merchants that have implemented E2EE, they may need to have to do an additional check depending on where E2EE is implemented. If the E2EE solution does not encrypt at the POI, then these merchants will also have to examine their point of sale (POS) in addition to their POI in order to comply with 9.9.2. One of the big reasons for this is because of Target style breaches where a memory scraper was used to obtain CHD because encryption was done at the POS, not the POI, and the connection between POI and POS was in clear text.

For merchants that use integrated keyboard card readers or USB card readers, there are other schemes such as keyboard loggers, USB adapters and other attacks that focus on the POS for obtaining CHD. For those merchants, they will also need to be doing daily inspections of their POS systems to ensure that equipment that does not belong is quickly identified.

The final requirement that will likely see changes is with 9.9.3 which is all about training retail personnel in the procedures of protecting the POI. With all of the changes to 9.9.1 and 9.9.2, you had to know that training would also have to change.

The biggest change will be the mandatory training. Yes, it was mandatory before, but with the focus on tampering with POI, training of retail staff will be very important. Why? Because they are the people on the front line and would be the ones most likely to notice something not right with their work area.

In order for these people to notice things out of order, they need to be trained, trained often and trained repeatedly. This is why security awareness training is so frustrating for security professionals is that it takes more than just one session every year to be effective. That and the fact that not everyone catches on at the same time with the same amount of training and there will be some people that never catch on.

The bottom line here is that your retail personnel will need to be drilled regularly on POI and POS security. How you choose to accomplish that training effort is up to your organization. But doing little or no training will not be an option.

SSL/Early TLS

The obvious change here will be the integration of the new deadlines for SSL and early TLS.

That said, the Council may actually provide some additional changes in section 4 regarding secure communication over TLS. In addition, by the time v4 of the PCI DSS is released, TLS v1.3 will likely be an official standard so changes in that regard may also be included.

Miscellaneous

Finally, I am sure there will be the usual wording and clarification changes that have come with every prior release.

Depending on any breaches that occur in the next few months, there may be some additional surprises in v4 to address the vulnerabilities identified by those breaches.

So there you have it. Start getting ready for the new PCI DSS v4 that will show up around November 2016.




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

May 2016
M T W T F S S
« Apr    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

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

Join 1,565 other followers


Follow

Get every new post delivered to your Inbox.

Join 1,565 other followers