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.
What You Don't Know Just Might Hurt You.
"As we know, there are known knowns. There are things we know we know. We also know there are known unknowns. That is to say we know there are some things we do not know. But there are also unknown unknowns, the ones we don't know we don't know."
--Donald Rumsfeld, Feb. 12, 2002
Regardless of what one thinks of Donald Rumsfeld's tenure as Secretary of Defense, these words hold a pearl of wisdom that applies to organizations struggling to comply with privacy and security laws. One of the major difficulties for modern organizations working with private personal information is simply knowing what privacy and security laws apply to their operations. This problem is exacerbated by the fact that, even for smaller- and medium-sized organizations, modern commerce often involves transacting with consumers in multiple legal jurisdictions (e.g. local, State, Federal and international). In short, since privacy and security laws from several jurisdictions may apply, it is highly likely that a lot of "unknown unknowns" exist, which can cause adverse impacts. This month's newsletter explores an instance where unknown unknowns may have come into play in the privacy context, and how organizations can begin to address the problem.
Too Much Information?
FACTA Credit Card Receipt Class Action Suits a Cause for Serious Concern.
In what appears to be a classic case of "unknown unknowns," a rash of over 100 class action lawsuits have been filed in California alleging violation of the Fair and Accurate Transaction Act of 2003 ("FACTA"). Section 15 U.S.C. § 1681c(g) of FACTA limits the information that can be printed on an electronically printed credit card receipt to the last five digits of the credit card number, and specifically prohibits printing a credit card's expiration date on the receipt. Organizations were provided with a three-year grace period to comply with this Federal law (December 4, 2006 was the first date that compliance was required).
A single willful violation of FACTA (which is incorporated into and part of the Fair Credit Reporting Act ["FCRA"]) could result in damages ranging from $100 to $1,000. Plaintiffs are also entitled to actual damages if they can prove a negligent violation of the FACTA. With companies processing millions of credit card transactions each year the damage potential for these lawsuits is staggering.
These class action suits have been filed against companies such as: Urban Outfitters; IKEA; Chanel Inc.; Toys-R-Us Delaware Inc.; Oakley, Inc.; Rite Aid Corp.; Costco Wholesale Inc.; The Walt Disney Parks and Resorts; California Pizza Kitchen Inc.; El Pollo Loco; Levy Restaurants; United Artists Theatre Circuit Inc.; FedEx Kinkos Office and Print Services Inc.; Valero Energy Corp.; and Avis Rent-A-Car Systems Inc. Lawsuits are also spreading outside of California - two lawsuits were filed on March 14, 2007 in the Western District of Pennsylvania.
Thus far, many of the cases have survived motions to dismiss. Defendants have argued that dismissal is warranted because, while section 1681c(g) of FACTA applies to "cardholders," private rights of action are only available to "consumers" under section 1681n of FCRA. This argument was rejected by California courts when raised by Oakley, Inc. and IKEA.
The success of these cases could ultimately hinge on the meaning of "willfully fails to comply" under section 1681n of FCRA. Two 9th Circuit cases (the Federal Appellate Court for California and other western States) have ruled on the meaning of "willfully." In Geico v. Edo, the court alluded to a "recklessness" standard:
In sum, if a company knowingly and intentionally performs an act that violates FCRA, either knowing that the action violates the rights of consumers or in reckless disregard of those rights, the company will be liable under 15 U.S.C. § 1681n for willfully violating consumers' rights. A company will not have acted in reckless disregard of a consumers' rights if it has diligently and in good faith attempted to fulfill its statutory obligations and to determine the correct legal meaning of the statute and has thereby come to a tenable, albeit erroneous, interpretation of the statute. In contrast, neither a deliberate failure to determine the extent of its obligations nor reliance on creative lawyering that provides indefensible answers will ordinarily be sufficient to avoid a conclusion that a company acted with willful disregard of FCRA's requirement. Reliance on such implausible interpretations may constitute reckless disregard for the law and therefore amount to a willful violation of the law (emphasis added).
This interpretation differs from interpretations in other Federal Appellate Districts, and this issue has now been argued before the U.S. Supreme Court (additional Supreme Court briefs and other information can be found here). If the Supreme Court disagrees with the 9th Circuit's (and the 3rd Circuit's) interpretation of "willfully," then these class actions may be difficult for plaintiffs to win (it is doubtful that plaintiffs will be able to establish actual damages to recover for "negligent" failure to comply with FCRA).
Many corporate defendants reported that they were "surprised" by the FACTA credit card receipt requirements despite the three-year grace period to achieve compliance. That seems like a plausible explanation considering that most rational companies, had they known of this requirement, would most likely have chosen to limit the information on their credit card receipts rather than face a potential fine of up to $1000 per violation and expensive attorney fees to defend class action lawsuits. Nonetheless, these companies are now experiencing the risks and expense associated with unknown privacy laws.
What should companies do to address "unknown unknowns" when it comes to privacy laws?
Organizations are not omnipotent - they cannot possibly know all things at all times at all places. However, they can take action to minimize their risk of unknown privacy and security laws, including: (1) designing their privacy programs consistent with Fair Information Practice Principles; (2) acquiring resources to stay on top of privacy and security regulations and case law; and (3) insuring against the unknown.
Fair Information Practice Principles. While the legal requirement to limit credit card receipt data may not be intuitive to all companies, there are certain general activities that rational actors know could get them into trouble when it comes to handling customer information. For example, selling or collecting personal information without notice or consent can obviously be problematic, and as a result there are laws that address those general categories of privacy violations. Addressing general privacy activities and principles can decrease risk even if specific regulatory requirements are unknown.
In fact many, if not most, privacy and security-related laws reflect the principles and framework set forth in the Fair Information Practice Principles ("FIPP"). FIPP includes: notice/awareness, choice/consent, access/participation, security/integrity and enforcement/redress. If FIPP is the goal and the organization strives to meet that goal with due diligence, that organization will likely have reduced its regulatory privacy risks (relative to organizations that do not consider FIPP).
The problem, of course, is that FIPP does not address every single detail of every privacy law. Some organizations that follow FIPP may have missed the specific requirements of FACTA or may not be aware of the specific notices (and fines) required under the CAN-SPAM Act, HIPAA, GLB and other more obscure laws. These class action lawsuits demonstrate how compliance to FIPP can help. Those companies diligently concerned about the security/integrity prong of FIPP, even without knowledge of FACTA's specific legal requirement, may have made an independent determination that truncating credit card numbers on receipts is a good practice to secure credit card information from identity theft. In fact, some organizations likely adopted this practice prior to the FACTA law as the result of due diligence with general privacy principles.
Due Diligence Investigation. Legal violations arising out of privacy or security incidents increasingly threaten organizations in terms of reputation damage, legal fees and damage awards. In fact, more and more companies are dedicating specific resources toward addressing privacy and security legal compliance. The first step is establishing accountability within the organization by creating a manager solely responsible for privacy compliance (a C-level executive with direct reporting to the CEO is a best case), and providing he or she with a budget. The lead privacy compliance officer should hire or work with attorneys to develop a formal process for inventorying the personal information the company handles, tracking the flow of that information across jurisdictions from collection to storage/disposal and determining the laws that apply to the organization.
Companies should attempt to address the lowest hanging fruit first. In certain industries, such as finance and healthcare, comprehensive privacy laws exist such as GLB and HIPAA. If the personal information of European or Canadian companies is at issue, the national privacy law of those countries should be considered.
Determining the applicability of privacy and security laws requires a continuous effort that considers changes in both the organization's internal privacy practices and the law. Those responsible for privacy compliance should engage in frequent and comprehensive communications with business managers whose units collect and handle personal information. Companies should track laws and legislation, and subscribe to privacy and security reporters and websites (feel free to contact me for a list of sources). A person who can make the link between organizational practices and changes in privacy laws, and how those practices laws might impact the organization, should be dedicated to tracking internal practices and privacy laws.
Privacy and Security Liability Insurance - Risk Transfer. Insurance is a very important tool for managing the "unknown unknowns." For companies that operate across multiple jurisdictions, it is virtually impossible to know every law and how every part of an organization is reacting or failing to react to that law. This means that residual risk exists that must either be tolerated by the organization or transferred to a third party.
Privacy and security liability insurance is an excellent tool for decreasing a company's risk load under these circumstances. While the uncertainty inherent in complying with every security or privacy law still exists for insurers, insurers can spread their risk across thousands of organizations. Moreover, even if aggregated events occur, as long as the insurer has a good financial rating, they should be able to absorb the loss. Even insurance companies without the highest financial ratings are typically reinsured by large reinsurers who are able to weather adverse situations.
The ability of insurers to underwrite privacy and security liability risks in a world where such risks are sometimes "unknown" addresses the main problem of modern organizations. Instead of expending huge amounts of resources to achieve an unattainable level of "perfect security," or researching, discovering and analyzing every possible privacy law that applies to them, insurers can take the risk and help their insureds avoids those expenses.
That is not to say that insurers will insure companies with bad privacy practices or poor information security. To be insurable, at a minimum, "reasonable" security and privacy practices must be present (and what is reasonable can vary from insurer to insurer). Nonetheless, most companies that can establish "due diligence," and have practices and policies adhering to FIPP and generally accepted security standards such as ISO 17799, will likely be insurable.
There are two key challenges for companies that want to use insurance as a risk management tool in this context. First is implementing security and privacy practices that meet a level of reasonableness at the lowest price. As long as insurance is available, spending more to achieve "more than reasonable" privacy/security may not be cost-effective. Moreover, large security and privacy overhauls can be disruptive to business. The risk avoided by implementing costly controls can be transferred for the price of an insurance policy which typically costs less than the controls.
Second, and perhaps most important for an organization that wants to manage risk through insurance, is ensuring that the privacy and security insurance policy it chooses actually covers the risks the organization desires to transfer. If it does not, the organization will be left handling the costs of that risk on its own. It takes a concerted effort by risk managers and key business stakeholders to understand not only the potential risks, but also how they might impact the organization if the risk is realized.
On the other side of the equation, since the current crop of security and privacy policies vary in their approach and coverage scope, it is not always easy to get a clear picture of what is covered. Organizations should make sure they have good brokers or insurance consultants who understand the specific risks of their company and the insurance products available to cover such risks. In all, if some time and effort is taken to understand the range of security and privacy insurance options, insurance can be a very cost-effective and efficient tool for dealing with "unknown unknowns."<
Conclusion
While the risks and problems associated with unknown privacy or security regulations may never be fully solved, the awareness of organizations and the skill and talent available to address the problem are probably at their highest. Companies simply need to acknowledge the fact that unknown unknowns exist in the privacy world, and dedicate time and resources toward at least converting them into "known unknowns." Even unaddressed privacy laws are better than unknown laws because at least the organization is aware of some risk and presumably has factored it into their overall risk management scheme. Organizations that are serious about understanding the full scope of their risk need to engage in a due diligence investigation, and need to at least try to adhere to common industry privacy practices and security standards. Companies should also seriously consider transferring their residual risk rather than engaging in potentially never-ending and expensive attempts to "eliminate" their risk. When these steps are taken, organizations can decrease the risk and loss associated with unknown security and privacy laws.
