A Closer Look at the PCI Compliance and Encryption Requirements of Nevada's Security of Personal Information Law
Since approximately 2005, the state of Nevada has had a fairly comprehensive data privacy law on its books: the Nevada Security of Personal Information Law (the “Law”). Prior to 2009, the Law imposed various requirements concerning the protection of personal information of Nevada residents, including requirements concerning security breach notice, the implementation of reasonable security measures and the destruction of records containing personal information. In 2009, the Nevada legislature materially amended the law by passing Nevada Senate Bill 227 (“SB 227” or “SB 227 Amendment”). The SB 227 Amendment added two significant (but mutually exclusive) data security obligations: (1) a requirement to comply with the Payment Card Industry Data Security Standard (“PCI”); and (2) requirements to encrypt personal information in certain contexts. The SB 227 Amendment became effective on January 1, 2010. This article summarizes the requirements of the SB 227 Amendment, addresses various compliance issues posed by it, and discusses its “safe harbor.”
The Interplay Between the Law’s PCI Compliance and Encryption Obligations
To understand the requirements of SB 227, it is important to first understand the interplay between the PCI obligations set forth in subsection 1. and the encryption requirements of subsection 2. Significantly, it appears that a data collector that complies with PCI (as required under subsection 1. of SB 227) need not comply with the personal information encryption requirements of subsection 2. This “either/or” dynamic creates a strange compliance situation.
Subsection 1. of SB 227 provides:
1. If a data collector doing business in this State accepts a payment card in connection with a sale of goods or services, the data collector shall comply with the current version of the Payment Card Industry (PCI) Data Security Standard, as adopted by the PCI Security Standards Council or its successor organization, with respect to those transactions, not later than the date for compliance set forth in the Payment Card Industry (PCI) Data Security Standard or by the PCI Security Standards Council or its successor organization.
Subsection 2. of SB 227 provides:
2. A data collector doing business in this State to whom subsection 1 does not apply shall not:
(a) Transfer any personal information through an electronic, nonvoice transmission other than a facsimile to a person outside of the secure system of the data collector unless the data collector uses encryption to ensure the security of electronic transmission; or
(b) Move any data storage device containing personal information beyond the logical or physical controls of the data collector or its data storage contractor unless the data collector uses encryption to ensure the security of the information.
(emphasis supplied).
The current version of PCI (v 1.2.1 – July 2009 ) references encryption with respect to certain cardholder related data while stored and in transit. Section 3.4. of PCI requires companies to render a payment card’s PAN’(“Primary Account Number’”) unreadable, including through the use of strong encryption. Compliance under section 3.4 is also possible through other measures, including truncation, index tokens and pads, and “compensating controls.” Section 4.1. of PCI mandates the use of strong encryption of “cardholder data” during transmission over open or public networks. Cardholder data as defined under PCI includes PAN, Cardholder Name, Service Code, and Expiration Date as defined with respect to PCI.
However, the definition of “personal information” under the Law is much broader than “PAN” or “cardholder data” under PCI. Personal information includes information that is wholly unrelated to credit cards, including social security numbers, driver’s license numbers, identification card numbers and bank account numbers. PCI does not require encryption of these elements while transmitted electronically. Moreover, PCI does not require any personal information to be encrypted while stored. Rather, it only requires that the PAN be encrypted in storage (and even here encryption is not an absolute requirement -- PCI allows for other methods to render PANs unreadable and allows for "compensating controls"). Finally, since the encryption that happens around PCI relates to payment processing only, it does not appear that PCI-compliant companies would have to address encryption in other contexts, including for example e-mails containing personal information.
In short, PCI compliance allows an entity to avoid the obligation to encrypt personal information (except for "Cardholder Data") on data storage devices or while in transit, as required under subsection 2. of SB 227, and would appear to undermine the broader purposes of the Law. Stated differently, companies that are already PCI compliant would appear to have diminished obligations when it comes to encrypting Personal Information than those companies that are not subject to PCI.
Issues Surrounding the Law’s PCI Compliance Obligations
Nevada is the first state to incorporate the entire PCI Standard into law. The PCI Standard is an industry standard contractually imposed by the payment card networks on merchants and service providers that store, process or transmit cardholder data. In essence, the Nevada legislature has ceded its legislative authority to a group of private companies whose interests and concerns in creating and updating the standard may not be aligned with the goals of the Law. It has given PCI the weight of law, backed by attorney general enforcement and potential statutory liability, despite the fact that PCI is typically imposed in a negotiated contractual setting. As such, tying PCI to the Law raises several interesting issues and poses additional challenges:
- PCI is always changing. One of the biggest problems with the PCI compliance requirement under SB 227 is that PCI is constantly being changed and updated. PCI is currently on version 1.2.1 (the fourth version in four years) and is currently soliciting comments concerning potential modifications in 2010. This makes the Law a moving target. On a certain level this makes sense – the PCI standard and good security evolves as the risks and technology changes. However, from a compliance standpoint constant vigilance is required to ensure compliance. Under the Nevada law this is especially true since non-compliance can result in an attorney general action.
- PCI is ambiguous. Unfortunately the PCI standard is ambiguous as written in many sections and as applied in many circumstances. This is due in part to the one-size-fits-all nature of the standard. The problem is exacerbated, however, because there are multiple sources of interpretation, including the PCI Council, merchant banks, the card brands and qualified security assessors. Even within the PCI Council itself multiple methods of interpretation exist, including guidelines, FAQs, prioritized approaches, and email answers provided by the PCI Council provided on an ad hoc basis. Moreover there is no set interpretative hierarchy between potentially competing interpretations. For example it is not clear whether PCI Council guidance document would trump an FAQ, or the interpretation of a merchant bank.
- PCI is contractual in nature. Typically a merchant will enter into a “merchant agreement” with a merchant bank or processor so it can accept credit cards. That merchant agreement will mandate that the merchant comply with PCI. If there is an ambiguity, since the merchant’s obligations are derived by contract, naturally the “best” source to resolve those ambiguities is with the merchant bank that is party to the agreement. If the merchant bank “gets it wrong” or agrees to a PCI interpretation that is not compliant, while it may have sufficed for the contractual relationship, under the Law it could result in a legal violation.
- PCI is one-size-fits-all. PCI is made up of over 200 individual requirements/sub-requirements. For small businesses it may be difficult, if not impossible, to comply with (from a resource standpoint). Yet the Law does not make any exception or allowance for this. As a result, on day one many businesses (especially smaller and medium companies) are likely to be non-compliant with the Nevada law.
- New independent and direct duty for service providers to comply with PCI? Typically, under the PCI regulatory scheme, service providers that store, handle or transmit cardholder only have a direct obligation to comply with PCI if they are contractually required to do so. They have no independent legal duty to comply with PCI under normal circumstances. SB 227, however, may provide a direct duty for service providers to comply with PCI. Service providers appear to fall into the definition of “data collectors” because they typically “handle, collects, disseminates or otherwise deals with nonpublic personal information.” The issue becomes whether, under subsection 1. of SB 227, a service provider storing, processing or transmitting cardholder data for another “accepts a payment card in connection with a sale of goods or services.” If the language in subsection 1. read “accepts a payment card for a sale of its goods or services,” then it would appear to be limited to merchants. However, the “in connection” language arguably extends the duty to service providers. For example, some might argue that payment gateways directly “accept” payment card numbers from customers online on behalf of merchants in connection with the merchant’s sale of goods and services.
Issues Surrounding the Law’s Encryption Obligations
The Encryption Obligations: Electronic Transmission and Data Storage Devices.
If a data collector doing business in Nevada does not have an obligation under subsection 1., then it must comply with the encryption requirements of subsection 2. SB 227 requires encryption in two areas: personal information transmitted electronically (subsection 2.(a) of SB 227) and encryption of personal information stored on certain data storage devices (subsection 2.(b) of SB 227).
A data collector doing business in Nevada, subject to exceptions discussed below, may not transfer personal information outside of its secure systems through an electronic transmission, unless encrypted. Again, a drafting quirk may pose some interesting interpretations of this obligation. By using the term “secure system” (undefined), it appears that this encryption requirement does not apply to personal information transmitted from an “insecure system.” Note that the probable intent of the “secure system” language was to eliminate the need to encrypt personal information while in transit within the internal networks of an organization (or at least that is one interpretation).
Drafting mistakes aside, SB 227 sets forth some significant exceptions to this encryption requirement. The electronic transmission encryption requirement does not apply to:
- electronic voice transmissions or facsimile transmissions;
- telecommunication providers conveying communications of other people; or
- data transmissions over secure private communications channel for: (1) approval or processing of negotiable instruments, EFT transfers or similar payment methods; (2) issuance of reports regarding account closures due to fraud, substantial overdrafts; or (3) abuse of ATM machines or related information regarding a customer.
Data collectors must also encrypt data stored on a data storage device if the device goes beyond the logical or physical controls of the data collector or its data storage contractor. The concept of going beyond the physical controls (e.g. facilities of the data collector) is fairly clear. However, it is uncertain exactly what the intent is behind the “logical controls” reference. It could mean that if the data storage device is protected by the same “logical controls” as data storage devices that are part of the data collector’s internal networks, then encryption is not required. Or it could be tying back into the concept of secure internal environments. However, more research is necessary to ascertain how the “logical control” reference should be interpreted.
The Encryption Standard.
To comply with the Law, data collectors must use an encryption technology that renders such personal information indecipherable in the absence of associated cryptographic keys necessary to enable decryption of such data, which has been adopted by an established standards setting body, including for example, the Federal Information Process Standards published by the National Institute of Standards and Technology.
Encryption under the law also requires sound key management processes and safeguards. Specifically, data collectors must utilize appropriate management and safeguards with respect to cryptographic keys in order to protect the integrity of its encryption process. The data collector’s key management procedures and safeguards must be consistent with guidelines set forth by an established standards setting body, including for example, the National Institute of Standards and Technology.
While one might quibble with the requirement that the encryption technology render personal information indecipherable (all encryption is theoretically capable of being broken), the reference to FIPS and NIST standards provides solid guidance. However, the Law does not indicate what constitutes an “established standards setting bodies” in the event a data collector would like to use an encryption standard that is not based on FIPS or NIST.
The SB 227 Amendment’s “Safe Harbor”
While SB 227 arguably imposes significant encryption obligations on certain data collectors (at least those that are not already PCI-compliant), it also provides a “reward” for companies that meet its mandates. Subsection 3. of SB 227 provides a “safe harbor”:
3. A data collector shall not be liable for damages for a breach of the security of the system data if:
(a) The data collector is in compliance with this section; and
(b) The breach is not caused by the gross negligence or intentional misconduct of the data collector, its officers, employees or agents.
This “safe harbor” may provide significant protection to compliant companies that suffer a personal information breach, even beyond the Law itself. Some may argue that the safe harbor protects the organization from all damages no matter what context or theory of liability (e.g. common law negligence, contract, negligent misrepresentation, etc.). Support for this theory can be found where SB 227 references a very limited list of liabilities theories (“gross negligence and intentional misconduct”), which arguably implies that other theories of liability can be barred by the safe harbor. Moreover, since the Law itself does not explicitly provide any damage remedy against a data collector that suffers a security breach, it would appear to be referring to liability outside of the Law.
For example, assume the case of a merchant that suffered a payment card breach. It would typically have a contract in place whereby it agreed to indemnify its merchant bank in the event of a payment card breach. Under SB 227, as long as the merchant was PCI compliant at the time of the breach (and therefore compliant with subsection 1. of SB 227), it could argue that it should be immune from contractual liability. This is significant because there is no legal mechanism currently in place under PCI that provides this legal protection. Please note that this argument is far from settled and additional research and analysis is necessary in order to validate the intent of Nevada’s legislature.
Beyond its potential broad scope, the safe harbor language in SB 227 arguably creates some incongruities between SB 227 and the Law. For example, the Law requires data collectors to implement certain “reasonable” security measures around personal information, which typically include measures beyond encryption (e.g. background checks, firewalls, virus protection, security policies, etc.). However, the safe harbor applies to all security breaches as long as the data collector complied with SB 227, even if it implemented “unreasonable” (but not “grossly negligent”) security.
An illustration may assist here. Assume a data collector made a mistake in configuring its firewall, which allowed a hacker to steal one million unencrypted personal information records while in transit on the data collector’s internal systems. One might argue that this data collector violated the section of the Law requiring “reasonable security measures” by providing such access. Nonetheless, as long as the data collector complied with SB 227 by encrypting data in transit externally or in data storage devices taken off premises, and it was not grossly negligent, it appears it would not be liable for the security breach under the Law (and otherwise). In other words, with the safe harbor, the requirements of SB 227 could be argued to override more stringent requirements of the Law around security.
Conclusion
Nevada’s Security of Personal Information Law, including the SB 227 Amendment, may pose some challenges for organizations. Its scope is arguably wider than Nevada companies because it appears to apply to any business that stores or processes personal information of Nevada residents, even those without a physical presence in Nevada. It employs a one-size-fits all approach that requires either PCI compliance or encryption of data in transit or on data storage devices, regardless of feasibility, or the resources or sophistication of the company. Moreover, by incorporating the payment card industry’s data security standard directly into the law, it gives PCI “the force of law.” This may be problematic for several reasons, the least of which is that PCI is frequently amended and presents a “moving target,” and is often ambiguous as written and as applied.
However, in addition to the new obligations posed by SB 227, it may offer some benefits and protection to organizations. First, companies that are already PCI compliant do not need to go the extra step under SB 227 and encrypt personal information in transit or on data storage devices. This is true despite the fact that the encryption requirements of PCI are limited in scope. Second, SB 227 provides a safe harbor that arguably bars liability arising out personal information security breaches that were not intentional or grossly negligent. In all, it will be interesting how companies react to the Law, how it is enforced by regulators, used by litigants involved in security breach litigation, and interpreted by courts.
Issuing Banks File Class Action Suit Against Acquiring Banks in Heartland Breach Matter
In an interesting development, a handful of issuing banks impacted by the Heartland breach have filed a class action lawsuit against two acquiring banks related to Heartland Payment Systems. According to this article, the issuing banks are unhappy with Heartland's proposed settlement with Visa. This appears and to be an attempted end-run around the proposed $60 million settlement with Visa. It also may demonstrate that issuing banks are not satisfied with the dispute resolution mechanisms under the Visa Operating Regulations (the Account Data Compromise Recovery process estimated the loss at $140 million, yet the settlement was for only $60 million), and their ability to be made whole under those mechanisms. We will have more analysis of the complaint at a later day. In light of the relative lack of success issuing banks have had in these types of cases, it will be very interesting to analyze the legal theories employed by the issuing banks and track the progress of this matter.
Quickhits: Heartland Settles With Visa for $60 Million
Read all about it here. Note, analyst Avivah Litan of Gartner indicated the "this seems like a very fair settlement, and it seems like Heartland escaped the tremendous costs that TJX incurred - $139 million plus - despite the fact that Heartland's breach was more extensive." In reality TJX settled with Visa for $41 million, and the $139 million figure (wherever she got it from -- this article from June 2009 claims TJX expended $320 million) likely includes both the Visa and Mastercard settlement amounts PLUS the costs and expenses to defend the numerous actions filed against TJX. At this point I doubt that Ms. Litan (or anybody else except Heartland) knows how much Heartland has incurred in expenses to defend the numerous lawsuits and regulatory actions it is facing.
Massachusetts's Highest Court Delivers BJ Wholesalers (and other Retailers) a Data Breach Liability Gift
While the proverbial jury is still out concerning retailers’ sales success this 2009 holiday season, Massachusetts’s highest court (the Supreme Judicial Court or “Supreme Court” as referenced herein) delivered retailers a significant holiday gift in the form of an opinion slamming the door on some financial institutions seeking to recover reissuance costs arising out a retailer’s payment card data breach. The Cumis Insurance Society, Inc. v. B.J. Wholesale Club, Inc. decision (“Supreme Court Decision”) analyzed and ruled upon most of the mainstream legal theories issuing banks have used to attempt to recover card reissuance costs, including breach of contract under a third party beneficiary theory, fraud, negligence, negligent misrepresentation and breach of unfair/deceptive practices laws (in this case M.G.L. Chapter . 93A, section 11). We have previously commented on multiple decisions involving retailer payment card breaches similar to the BJ Wholesale breach and PCI liability in general, including a 3rd Circuit federal appellate decision that allowed issuing banks to proceed forward with a third party beneficiary breach of contract theory. This blog post dives into and analyzes the Supreme Court Decision, and looks at it in context against similar decisions. Overall, in terms of issuing banks recovering for payment card breaches, the game does not appear to be litigation in the courts, but rather in the backroom contracts and recovery processes contained in the card brand operating regulations that most retailers agree to comply with.
Relevant Facts
The Supreme Court Decision arises out of a payment card breach of BJ’s Wholesale Club, Inc. (“BJs”) involving approximately 9.2 million payment cards and millions of dollars in fraud. The plaintiffs in this case are credit unions and their insurer who incurred costs to reissue the payment cards that were impacted by the breach (as well as costs for fraudulent charges that arose out of the breach). The plaintiffs allege that thieves were able to compromise BJ Wholesale Club’ s systems because BJs and their acquiring bank (Fifth Third Bank) breached two sets of contractual obligations. With respect to BJs, the plaintiffs alleged that BJs breached their contract with Fifth Third bank, which prohibited the storage of the magnetic stripe data after authorization of card transactions. In turn, the plaintiffs alleged that Fifth Third breached its Membership Agreement with Visa and Mastercard requiring Fifth Third to ensure that merchants like BJs did not store magnetic strip data post-authorization.
Alleged Claims and the Supreme Court’s Decision
The plaintiffs alleged several causes of action against BJs and Fifth Third, including breach of contract under a third party beneficiary theory, fraud, negligence, negligent misrepresentation and breach of unfair/deceptive practices laws (in this case M.G.L. Chapter . 93A, section 11). The lower court had granted the defendants a motion to dismiss all of the plaintiff’s causes of action, and the Supreme Court was asked to review the lower court’s decision. Ultimately, as described below, the Supreme Court agreed with the lower court’s decision and upheld it.
Breach of Contract – 3rd Party Beneficiary Theory
The plaintiff’s alleged that they were the intended third party beneficiary of two separate contracts. First, the Merchant Agreement between BJs and Fifth Third prohibited the storage of magnetic card data, and the plaintiffs alleged they were the beneficiaries of, and should be able to enforce, the agreement against BJs. Second, the plaintiffs also alleged that they were the intended third party beneficiaries of the Membership Agreement between Fifth Third and Visa/Mastercard. Pursuant to the Membership Agreement, Fifth Third agreed to ensure that its merchants did not store magnetic stripe data.
Unfortunately for the plaintiffs, the Merchant Agreement contained the following language:
This Agreement is for the benefit of, and may be enforced only by [Fifth Third] and [BJ’s] and their respective successors and permitted transferees and assignees, and is not for the benefit of, and may not be enforced by, and third party.
Despite this language, the plaintiffs maintained that the prohibition against storing magnetic stripe data was intended to benefit them. Citing a lower court judge who had indicated that any benefits to the plaintiffs in the Merchant Agreement were incidental, and relying on the specific intent referenced in the disclaimer, the Supreme Court upheld the dismissal of the breach of contract claim based on BJs Merchant Agreement.
With respect to the Membership Agreements between Fifth Third and the card brands, the Supreme Court held that the plaintiffs’ third party beneficiaries allegations were conculsory in nature and not supported by any facts establishing Visa or Mastercard’s intent to have them as beneficiaries able to enforce the Membership Agreemwent. While Visa and Mastercard’s operating regulations did not have a specific third party beneficiary disclaimer, both Visa and Mastercard, reserved the right to interpret and enforce such regulations. The Supreme Court viewed this as indicating an intent to prohibit enforcement of the Membership Agreement by others like the plaintiff (the Supreme Court viewed that as consistent with the TJX decision). Interestingly, this case involved the same facts as another BJ Wholesale Club in federal court that allowed the plaintiff-banks to proceed with a third party beneficiary claim. In the Federal case, Visa and Mastercard representatives actually testified at deposition that operating regulations around magnetic stripe data were intended to protect the participants in the system, including issuers. However, the Supreme Court found that the plaintiffs failed to submit that deposition testimony into the court record so that testimony apparently was not considered by the Supreme Court.
Negligence – Economic Loss Doctrine
The Supreme Court did not address whether BJs or Fifth Third, for purposes of a negligence theory, had a duty to employ reasonable security with respect to cardholder data. Rather, the Supreme Court relied on the economic loss doctrine to dismiss the plaintiff’s negligence claim. Under the economic loss doctrine, plaintiffs cannot recover using a theory of negligence unless physical harm or harm to property exists (as opposed to pure “economic loss”). The plaintiffs argued that tangible harm did exist because the physical credit cards had to be reissued after the BJs breach. On this issue, the Supreme Court again followed the BJ Wholesaler’s decision rendered in Federal district court (see the 3rd Circuit Appellate Decision upholding that rationale), which held that reissuance costs are economic in nature even if related to a physical card. In this case the cards themselves were not harmed since consumers could still use them after the breach. Rather, the Supreme Court found that the plaintiffs chose to cancel the cards for the purpose of avoiding future economic loss.
Fraud and Negligent Misrepresentation
The Supreme Court also rejected the plaintiff’s fraud and negligent misrepresentation claims. The basis for these claims was again tied to the defendant’s contractual promises to comply with the card brands’ operating regulations. In disposing of the fraud claim, the Supreme Court noted that the plaintiffs admitted neither BJs nor Fifth Third made any direct representations to the plaintiffs indicating that they were storing magnetic stripe data. Moreover, despite alleging that they would have changed their behavior had they known about the risk of magnetic stripe exposure, the reality was that the plaintiffs continued to participate in the Visa and Mastercard system. There was no evidence that the plaintiffs would have acted any differently had they been aware that BJs was storing magnetic stripe data.
With respect to the negligent misrepresentation claim, the Supreme Court cited case law indicating that failure to perform a contract does not equate to a negligent misrepresentation claim. Moreover, false statements of opinion or conditions to exist in the future cannot support a negligent misrepresentation claim. In this case, dismissal was warranted because there was no evidence that BJs never intended to comply with its Merchant Agreement at the time it entered into it.
In addition, the Supreme Court held that even if entering into an agreement constituted a representation of compliance with the magnetic stripe disposal requirements, there was no evidence that plaintiffs’ alleged reliance on that representation was justifiable. The Supreme Court essentially held that no reasonable person would rely on the regulations prohibiting the storage of magnetic stripe data. The court pointed to evidence indicating that the participants in the payment card system expected that the operating regulations would be breached because Visa and Mastercard instituted a system of fines and penalties for non-compliance. In addition, the plaintiffs’ purchase of insurance to cover credit card fraud was listed as evidence that plaintiffs anticipated this type of fraudulent activity. Finally, the plaintiffs had received numerous alerts from Visa and Mastercard concerning payment card breaches and fraud involving compromised magnetic stripe data (I find this reasoning very convoluted, at best. The existence of rules to deter certain behavior seems to create some certainty that such behavior should not be happening).
M.G.L. Chapter . 93A, section 11
Since the plaintiffs’ M.G.L. Chapter . 93A, section 11, equitable indemnification and subrogation claims were all based on the dismissed fraud and negligent misrepresentation claims, they were also dismissed. Interestingly, unlike the First Circuit Appellate court’s decision in the TJX matter, the Supreme Court did not consider whether the plaintiffs had a viable cause of action based on the “unfairness” prong of the Massachusetts’ law (e.g. whether BJs information security was so poor that it constituted an “unfair practices).
Conclusion
This case is yet another in the increasingly long series of cases that allow retailer plaintiffs to escape liability arising out of data breach litigation at the motion to dismiss phase. What lessons does it hold for the various payment card stakeholders?
On the merchant side, for any agreement where the merchant is making promises about data security or PCI compliance, make sure there is a strong disclaimer of third party beneficiaries. This will cut issuing banks off on that theory fairly early. Also on the merchant side, be careful of what you say about security and compliance with card brand rules and operating regulations. To the extent a merchant makes representations concerning security (especially direct representations), they may be opening themselves up to misrepresentation claims. The consequences could be serious since negligent misrepresentation and fraud claims are not barred by the economic loss doctrine (and at least one court has provided those theories some legs).
From the issuing banks’ point of view, the question becomes whether litigation is worth it in this context. This is especially true now that both VISA and Mastercard (*I believe, their regulations are not all public) have explicit recovery mechanisms within their systems that can allow an issuing bank to recover without going to court. VISA and Mastercard have both tightened up their contracts and operating regulations to disclaim third party beneficiary theories (although if an issuing bank is to pursue such a theory make sure to get the deposition testimony from the Visa and Mastercard officials referenced in the 3rd Circuit’s BJs Wholesale case). One area for issuing banks to take a harder look at is State unfair/deceptive trade practice acts. As mentioned above at least one high court has indicated that inherently poor security may amount to an unfair practice. This line of thinking also happens to be consistent with several high profile FTC actions , including of course one involving BJ Wholesale Club.
Quickhits: AMEX settles with Heartland Payment Systems for $3.6 Million
Read all about it: HERE.
The Merchants Strike Back?
With the recent news of several restaurants teaming up to sue point-of-sale system provider Radiant Systems (a copy of the complaint can be found here) for failing to comply with the PCI Standard, it appears that some merchants may be in a mood to strike back in the aftermath of a payment card security breach. This lawsuit comes in the wake of a couple lawsuits against payment card security assessor Savvis for allegedly failing to properly validate a processors' Visa CISP compliance (admittedly in this case it is the merchant bank suing the assessor, but a similar cause of action could exist for a merchant if its assessor makes a mistake in verifying PCI compliance). While two instances certainly don’t indicate a trend, they do indicate a potential route that merchants may consider to deflect liability arsing out of a payment card security breach.
It is possible that we will see more lawsuits by merchants against service providers, payment processors, and application/point-of-sale system providers in the coming months and years. Part of the reason is that the PCI regulatory system imposes a form of “strict liability” on merchants that suffer a security breach. Fines, penalties and the availability of recovery processes are contingent (in part) on whether or not a merchant was PCI-compliant at the time of the breach (see e.g. Visa’s ADCR). Thus, when a Qualified Incident Response Assessor ("QIRA") comes in after a credit card breach to do an audit one of its main tasks (if not its primary goal) is to ascertain whether the merchant was PCI-compliant.
Lost in the shuffle sometimes, however, is the issue of “causation.” The question that is not being asked is whether or not PCI compliance would have prevented the breach, or whether the lack of PCI-compliance was the cause of the breach. In other words would PCI-compliance have made a difference. In some cases the answer is obvious. For example, if a merchant is holding onto sensitive authentication information, clearly PCI compliance (which requires the deletion of such data after a transaction) would have precluded a payment card breach. In other situations, however, the answer might not be as clear cut.
Moreover, even where a merchant is found not PCI compliant, the question still remains whether any other party was fully or partially responsible for the breach itself. Was the merchant’s payment application the source of the breach? Was the merchant working with a service provider, gateway or processor that could have been the source of a virus or attack by a hacker? Unfortunately, with their focus on PCI compliance, a QIRA may not have cause to investigate further into these possibilities (and a separate forensic assessment by an independent forensic firm may be necessary). In fact, I have seen an audit report where the auditor literally indicated that it could not determine how malware got onto a merchant’s system or whether cardholder data ever left (and in the report decided to speculate that it may have been porn or file sharing sites).
Beyond the entities involved in storing, processing or transmitting payment cards, merchants may also begin to target companies assisting their efforts to achieve and validate compliance with PCI. Consultants that help merchants become PCI compliant or remediate PCI violations may be targets if they make a mistake. Moreover, as Savvis shows, qualified security assessors that make mistakes in their validation of PCI compliance are also potential defendants.
Despite sometimes having a variety potential targets to recover from, merchants still face obstacles to actual recovery post-security breach. The biggest obstacles are the contracts that merchants enter into with the entities mentioned above. In most cases these contracts contain terms that effectively limit the liability of these entities and make it very difficult to recover under any theory of recovery.
So is there an answer for merchants to these contract clauses? Thinking ahead might make all the difference in this case. When entering into a contract with any of the various entities described above, at the Request for Proposal phase, merchants should make indemnification and other favorable contract terms (e.g. no limit of liability/disclaimer of consequential damages for security breaches) part of the bidding process. Merchants' propsective service providers, assessors and application providers should be forced to compete on the issue of taking responsibility when they are fully or partially at fault for a security breach or inaccurate/improper PCI validation. Proper levels of cyber insurance should be in place to allow merchants to recover if there is a breach. If merchants don’t take these steps early on and in a disciplined fashion they may find themselves holding the bag even in situations where others may have contributed to their security breach.
Code or Clear? Encryption Requirements (Part 2)
In the last post, I talked about the role of encryption in fashioning a “reasonable” security plan for sensitive personal information and other protected data routinely collected, stored, and used by an enterprise. But lawmakers and regulators are getting more specific about using encryption and managing data that is risky from an ID-theft perspective. Here are some leading examples of this trend.
State Security and Breach Notification Laws
Since California adopted SB 1386, which went into effect in 2003, nearly all US states have enacted security breach notice laws that require notice to affected individuals, and in some cases to public authorities, when a party has reason to believe that the security of protected categories of personal data has been compromised. The protected categories are typically SSN (Social Security Number), driver’s license, financial account or payment card details (usually only if the password or access code is also compromised), and, increasingly, medical data not covered by federal HIPAA privacy protections.
All of these laws make an exemption from the notice obligation if the data were encrypted (some add that this is true only if there is no reason to believe that the decryption key was also compromised). The laws, and regulations adopted under the laws, typically do not specify the level or kind of encryption. For example, California’s Office of Privacy Protection published guidance specifically on the subject of “Recommended Practices on Protecting the Confidentiality of Social Security Numbers” in April 2007, which has only this to say about encryption, on page 11:
“Protect records containing SSNs, including back-ups, during storage by encrypting the numbers in electronic records or storing records in other media in locked cabinets.”
Partly as a consequence of these security and breach notice laws, organizations should limit their use and storage of these categories of personal data to the extent they are really necessary for business operations. Storage on servers or on archived media, and transmission over internal networks and VPN connections, may or may not be sufficiently secure without encryption, depending on the company’s risk assessment and IT security practices. Organizations should encrypt such data when it is resident on laptops or other portable devices and when it is in transit over the public Internet.
Massachusetts and Nevada have recently adopted stricter and more specific rules, however, that may become a model for other states. These increase the regulatory pressure for encrypting protected categories of personal data.
Massachusetts
The Massachusetts Personal Information Security Regulation (201 CMR 17.00) is now scheduled to take effect on March 1, 2010. The Regulation was promulgated by the Office of Consumer Affairs and Business Regulation (OCABR) under the authority of the Massachusetts personal information security law.
The Regulation will require all parties that “own or license” any of the protected categories of personal data concerning Massachusetts residents to encrypt the data in laptops or other portable devices, as well as in wireless transmissions and in transmission over public networks.
Note that the Regulation does not limit its coverage of financial account data to cases where the access code or PIN is compromised, as do most security and breach notice laws. The Regulation extends to any nonpublic financial account or payment card data, as well as to SSNs and driver’s license numbers. The Regulation does not cover medical information, however.
The Regulation mandates a number of “Computer System Security Requirements” (201 CMR sec. 17.04) for businesses that handle the protected categories of personal data. These expressly include the following:
“(3) Encryption of all transmitted records and files containing personal information that will travel across public networks, and encryption of all data containing personal information to be transmitted wirelessly . . .
(5) Encryption of all personal information stored on laptops or other portable devices . . .”
The level and type of encryption are not specified.
Nevada
Nevada recently amended its personal information security law, which already required “reasonable” security measures as well as breach notice (Nevada Rev. Stats. secs. 603A.010 et seq.). The amendments take effect on January 1, 2010.
The law covers SSNs, driver’s license numbers, and payment card or financial account data in combination with an access code or PIN. Medical information is not covered.
Under the amended law, businesses that accept payment cards (credit cards and debit cards) must comply with the Payment Card Industry Digital Security Standard (PCI DSS). In addition, a party handling any of the protected categories of information must encrypt the data if it transfers the data electronically “outside of the secure system of the data collector” or if the data is stored on a device (laptop, USB drive, etc.) that is moved “beyond the logical or physical controls of the data collector or its data storage contractor.”
“Encryption” is defined in the amendments with reference to “established standards,” specifically including FIPS and mentioning the need for standards-based key management as well as encryption protocols:
‘Encryption’ means the protection of data in electronic or optical form, in storage or in transit, using:
(1) An encryption technology that has been adopted by an established standards setting body, including, but not limited to, the Federal Information Processing Standards issued by the National Institute of Standards and Technology, which renders such data indecipherable in the absence of associated cryptographic keys necessary to enable decryption of such data; and
(2) Appropriate management and safeguards of cryptographic keys to protect the integrity of the encryption using guidelines promulgated by an established standards setting body, including, but not limited to, the National Institute of Standards and Technology.”
Thus, while the law itself does not specify the form of encryption, it puts the burden on the user to choose an appropriate and standards-based method.
HITECH
Title XIII of ARRA, the federal economic recovery legislation adopted early in 2009, is labeled the Health Information Technology for Economic and Clinical Health Act (HITECH). It amends the HIPAA medical privacy provisions by adding a federal security breach notice requirement for nonpublic, personally identifiable health information. While HIPAA applies only to certain covered entities (healthcare providers and insurance companies and clearinghouses), HITECH also applies to “business associates” that provide services to those entities. HITECH reaches as well any employers that are covered by HIPAA because, for example, they operate company clinics or manage their own health plans.
HITECH requires notice to affected individuals when there has been a security breach exposing personally identifiable health data. HIPAA already lists 18 identifiers (names, addresses, SSNs, health plan ID numbers, etc.) that must be removed to establish that health records have been “de-identified.” Where compromised records have not been fully de-identified by removing these data fields, HITECH sec. 132400 also recognizes that the information may not be personally identifiable if it is effectively encrypted:
“(b) Implementation specifications: Requirements for de-identification of protected health information. A covered entity may determine that health information is not individually identifiable health information only if:
(1) A person with appropriate knowledge of and experience with generally accepted statistical and scientific principles and methods for rendering information not individually identifiable:
(i) Applying such principles and methods, determines that the risk is very small that the information could be used, alone or in combination with other reasonably available information, by an anticipated recipient to identify an individual who is a subject of the information; and (ii) Documents the methods and results of the analysis that justify such determination; . . . .”
Thus, HITECH does not specify a particular form of encryption but leaves it to IT security experts to decide whether the data are effectively unidentifiable in the hands of an unauthorized user. Note that the statute requires covered entities to maintain documentation of this professional analysis, and that the analysis must be based on “generally accepted” principles and methods – which means that professional opinions are likely to refer to published specifications and industry standards.
Red Flags
The 2007 Identity Theft Red Flags Rule (promulgated under the 2003 FACTA amendments to the federal Fair Credit Reporting Act) went into effect in November 2008, although the FTC suspended enforcement until November 1, 2009. (Similar rules were issued by the federal financial regulatory agencies, for the institutions they supervise.) The Rule requires covered entities to develop and implement written policies to prevent identity theft, including recognition of warning signs or “red flags” of suspected ID theft.
The Rule applies not only to traditional financial institutions but to “creditors,” defined as companies that “regularly defer payment for goods or services,” whether or not charging interest or finance charges, and therefore store personal information about individual debtors. Some employers, for example, sell goods or services to employees on deferred payment terms and may be treated as covered entities for that reason. (However, the Red Flag FAQs written by FTC staff take the view that an employer is not a covered entity simply because it sponsors a 401k or other qualified retirement plan that allows participants to borrow from their retirement funds.)
For covered entities, the mandatory policy to prevent ID theft must identify signs of possible security breaches involving certain data, as well as appropriate responses to those alerts. The covered data are SSNs and tax identification numbers, healthcare IDs, financial account and credit/debit card details, personally identifiable medical information, and identifying data from consumer reports (which are often used for employee background checks as well as for credit applications).
The Rule itself does not mandate encryption measures. However, most covered entities will necessarily address encryption in their written anti-ID theft policies. Their “red flags” should also include an alert if there is evidence that encryption keys have been misused, stolen, or hacked.
