Archive for January, 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.




January 2016
M T W T F S S
 123
45678910
11121314151617
18192021222324
25262728293031

Months