Archive Page 2

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.

27
Jan
16

Do Consumers Really Bail On Breached Merchants?

Conventional wisdom is that when a retailer suffers a breach their customers leave and do not come back. As a result, this threat is what a lot of retail CISOs point to as one of the primary reasons for beefing up information security.

But is that threat real? Do consumers really leave retailers that have been breached?

That is what the Merchant Acquirer’s Committee (MAC) and Dr. Brandon Williams decided they needed to find out. On Tuesday, January 26, 2016, they released the results of their survey they conducted of consumers and their attitude toward retailers that had been breached. I got to speak with Dr. Williams just before the release of the report to discuss what the survey found regarding the issues of retailer breaches.

The good news for retailers that get breached is that while customers tend to avoid a retailer immediately after the announcement of a data breach, those customers eventually return. I was particularly surprised that even with the multiple Michael’s breaches within two years of one another, most customers came back to them.

In discussing this behavior with Dr. Williams, we both came to the conclusion that this behavior was most likely driven by the fact that, unless a consumer suffers identity theft or a loss of money, a breach did not create an incentive for customers to leave a retailer permanently. Yes, a customer most likely received a new credit/debit card because of a breach. Yes, that new card likely created some hassles due to any recurring payments tied to that card. But in the end for most customers, if there was no harm to them therefore there was no foul to the retailer.

My only concern with the results of this study are that it will give some merchants the idea that since a breach does not impact their business they can therefore avoid truly complying with the PCI standards. However, I would remind everyone that their Merchant Agreement contractually obligates them to comply with all relevant PCI standards. So while a breach might temporarily affect business revenue, a breach definitely puts the business on the hook for any fines and penalties levied by the card brands or transaction processors and the costs of any resulting lawsuits. As a result, there should be significant justification for complying with all of the relevant PCI standards.

The full report can be obtained from the MAC web site here.

05
Jan
16

Unsupported Operating Systems And Applications

One of our QSAs accidentally had their QSA certification lapse and had to go back through in-person QSA training. As a result, all of us in the PCI practice got an opportunity to get caught up on the latest and greatest guidance that the PCI SSC is passing along in their current QSA training. Even though QSAs and ISAs have to go through re-certification training and testing annually, having people go through the in-person training is the only way in some cases to get insight into the latest thinking of the Council.

One of the areas we specifically asked the person to ask their PCI trainer about was unsupported operating systems (OSes) and applications. In the past, such unsupported environments were considered automatically non-PCI compliant because of the ASV automatic failure rules documented in the ASV Program Guide v2.0. As a result, most QSAs constantly get push back from some clients when we encounter unsupported OSes and/or applications. However, we were shocked to find out from our colleague that the Council is no longer advising QSAs and ISAs to automatically mark as non-PCI compliant unsupported OSes and application software unless they are externally facing.

Now before you go off telling management that expensive upgrades are no longer necessary for internal systems and yelling “Alleluia” to the PCI Gods, there are, as you should expect, some caveats to all of this.

First, this is not the Council condoning the use of unsupported OSes and application software. The Council will still tell you that organizations should be using current and supported OSes and application software. This is merely a recognition that upgrades to a supported environment are not always an option in all cases. As a result, organizations might only be able to use unsupported operating systems and applications given hardware and/or customization constraints.

And just so we are all on the same page. Externally facing unsupported OSes and/or application software is still an automatic PCI compliance failure per the latest version of the ASV Program Guide.

Second, in order to continue to use unsupported OSes and applications, your organization will have to create compensating control worksheets for relevant PCI DSS requirements. The first problem with compensating controls is that the controls must go “above and beyond” the controls required by the PCI DSS. So any controls you use to compensate for your unsupported environment must either be not required by the PCI DSS or must go beyond the stated PCI DSS requirements. For example, white listing of installed applications is not a PCI DSS requirement, so that can be used as an effective control. An example of going above and beyond is doing near real-time monitoring of log data because log data is only required to be reviewed daily. For more on writing compensating controls, see my post on the subject.

Which brings up an interesting dilemma depending on the unsupported environment. As a prime example, developing a compensating control for Windows 2000 or Windows ME is probably not going to be possible no matter how many compensating controls you can document in the worksheet. The primary issue that will make this impossible is because of what those older operating systems do to a domain in order to be joined in the domain. The resulting downgrades in security create a litany of issues that no amount of compensating controls will be able to address.

Which points out that just because you make an attempt at compensating controls does not mean that effort will result in something effective or even acceptable to your QSA/ISA. All of those compensating controls for all of the requirements must be in place, operating as designed and assessed as part of your PCI assessment. This is not something you can just toss together at the last minute and hope it will pass muster. As a result, you need to be prepared to admit that there will be instances where the older OSes and/or applications just cannot be compensated for no matter how many other controls you think can implement.

Third, if your organization is going to use unsupported OSes and/or application software, then your organization is going to have to mitigate the risks of this practice. So what mitigations would a QSA/ISA expect to see? Here are a few thoughts.

  • Severely locking down the OS. This is typically done by a utility that white lists the OS and applications on the system. If anything tries to install on the system, it is stopped and an alert is generated.
  • Enabling the generation of all possible log data by the unsupported OS and/or application. Essentially logging all activity from the unsupported OS and/or application. All of this log data feeds the next bullet.
  • Conducting near real time analysis of all log data produced by the unsupported OS and/or application. This will require the use of a system incident and event monitoring (SIEM) solution configured with rules looking for anomalies related to threats to the unsupported OS and/or application. And I can hear people asking now, what are the anomalies I should be looking? See the next bullet.
  • Identification of new threats to the unsupported OSes and/or applications. Threat identification can come from vendors of the unsupported OSes and/or applications as well as from sources such as US CERT, anti-virus vendors and other recognized threat sources. And this is not going to just be some monthly, quarterly or other “periodic” exercise, this is going to have to be an active daily exercise and you will need to prove that it is conducted as such.

And finally do not bother to go through some sort of Rube Goldberg process of bizarre, twisted and convoluted logic you think will get you can pass. There is nothing worse than sending your QSA/ISA through some sort of circular logic that in the end never gets your unsupported OSes and/or applications any closer to being protected than when you started. I have encountered too many instances of a lot of words, pages and diagrams that have no meaning for PCI compliance other than being a lot of words, pages and diagrams all in the hope of baffling the QSA/ISA with a lot of words, pages and diagrams.

All we as QSAs and ISAs ask is that you be intelligent and judicial in what you choose not to upgrade or update.




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,544 other followers


Follow

Get every new post delivered to your Inbox.

Join 1,544 other followers