New Incentives Loom for Data(base) Encryption [Updated]

SQL Server 2005's native data encryption features gain new importance as U.S. congressmen and state lawmakers curry favor with constituents alarmed by Internet identity theft. Another 40 million compromised credit card numbers and "security codes" add fuel to calls for protection of consumers' private financial information.

[Update 1/26/2006] The U.S. Federal Trade Commission (FTC) has levied a US$10 million fine on ChoicePoint for violations of the Fair Credit Reporting Act (FCRA). The FTC also expects ChoicePoint to establish a US$5 million "trust fund for individuals who might have become victims of identity theft as a result of the breach." Senators Charles E. Schumer (D-NY) and Bill Nelson (D-FL) introduced S. 768, the "Comprehensive Identity Theft Prevention Act," on April 12, 2005. Subsequently, S. 768 gained Sen. Mark Dayton (D-MN) and Sen. Edward M. Kennedy (D-MA) as cosponsors. According to the Commercial Law League of America (CLLA), the Act would establish an Office of Identity Theft within the Federal Trade Commission and would provide the FTC with broad authority to prevent identity theft and establish limitations on businesses that collect, maintain, sell or transfer sensitive personal information of individuals. The FTC would have civil jurisdiction over all commercial organizations that collect, maintain, sell or transfer sensitive personal information. Sensitive personal information includes an individual's:

• Social security number
• Driver's license number or state identification number
• Bank or investment account number
• Credit or debit card number
• Certain medical information
• Payment history
• Other information specified by the FTC

Unauthorized disclosure of sensitive personal information could result in civil penalties up to $1,000 per violation, depending on the nature of the violation, such as failure to meet "reasonable standards" for data protection.

A recent New York Times article, "The scramble to protect personal data," mentioned the newly-proposed act in conjunction with CitiGroup's loss of a box of unencrypted backup tapes of CitiFinancial records that contained sensitive personal information (names, addresses, Social Security numbers, and account numbers) for about four million customers. If the act were in effect before the loss, CitiGroup's liability could be as much as $4 billion. A June 10, 2005 InfoWorld editorial, "Another week, another few million confidential records lost," provides more details on CitiGroup's lost backup tapes and the 3.9 million notices being sent. The tapes were lost in transit from a New Jersey datacenter to a credit bureau in Texas. According to the article, "Citibank made it clear in its statement that the company had plans to begin encrypting their credit bureau information." Computer security expert Bruce Schneier weighed in with a different take on the CitiGroup loss. Schneier is concerned that the California Information Practices Act (S.B. 1386), which requires entities to notify persons whose unencrypted Social Security, state identification, driver's license, bank account, or credit card numbers have been subject to unauthorized access, will lead to reduced press coverage of personal information theft and loss incidents. A compromise of 100,000 customer records doesn't give rise to a major news story after earlier (and repeated) reports that millions of personal records have been lost or stolen. Update: June 18, 2005: In a record-breaking security breach, MasterCard International reported on June 17, 2005 that about 40 million credit and debit card account numbers and security codes might have been stolen from CardSystems Solutions, a MasterCard processor. About 20 million were Visa cards and 13.9 were MasterCharge; the remainder were American Express and Discover cards. A New York Times article quoted a MasterCard spokesperson: "[A]n infiltrator had managed to place a computer code or script on the CardSystems network that made it possible to extract information." The Times article explained that "MasterCard said its investigation found that CardSystems, in violation of MasterCard's rules, was storing cardholders' account numbers and security codes on its computer systems. That information, MasterCard said, was supposed to be transferred to the bank handling the merchants' transactions but not retained by CardSystems." It's not clear from the article, but the term "security codes" might be the three-digit card validation code that's printed on the back of MasterCharge, Visa, Discover, JCB, or Diner's Club cards or four-digit code for American Express cards. The card validation code usually is required for on-line transactions. A San Francisco Chronicle article states: "Neither MasterCard nor Visa would say what was lacking in the firm's security, except to say it was out of compliance with their minimum security standards. But experts say that in order for a hacker to steal and use the information, it could not have been encrypted, a basic step that is required by the card companies' standards." The article goes on to quote Gartner analyst Avivah Litan: "They [MasterCard] weren't actively monitoring compliance. It wouldn't take that much to send an auditor to see if that data is encrypted or not." Neither Visa nor MasterCard require encrypting stored credit-card data. For example, here's a link to the Payment Card Industry (PCI) Security Standard on the Visa site, and a link to a simplified version on the MasterCharge site. MasterCard paraphrases PCI requirement 3 as "Protect stored transaction data. Keep transaction storage to a minimum and never store sensitive authentication data after authorization. Take precautions to make stored transaction data unreadable through encryption or some other secure and robust approach." [Emphasis added.] Following is the text of the Visa U.S.A. Cardholder Information Security Program (CISP) Frequently-Asked Questions #7: "7. Are there alternatives to encrypting stored data? Stored cardholder data should be rendered unreadable according to requirement 3 of the PCI Security Audit Procedures document. If encryption, truncation, or another comparable approach cannot be used, encryption options should continue to be investigated as the technology is rapidly evolving. In the interim, while encryption solutions are being investigated, stored data must be strongly protected by compensating controls. These compensating controls should be considered as part of the compliance validation process. [Emphasis added.] An example of compensating controls for encryption of stored data is complex network segmentation that may include the following: • Internal firewalls that specifically protect the database • TCP wrappers or firewall on the database to specifically limit who can connect to the database • Separation of the corporate internal network on a different network segment from production, fire- walled away from database servers." MasterCard's Electronic Commerce Best Practices for Acquirers classifies encryption of stored data as a "best practice," not a requirement. (The original title of this document was "Electronic Commerce Requirements and Best Practices for Acquirers.") MasterCard processors (a.k.a. "acquirers") "themselves do not need to go through the SDP compliance process but they must manage the SDP process for their merchants and service providers." [SDP is an abbreviation for MasterCard's Site Data Protection process for merchants.] A TransactionWorld page compares Visa's CISP and MasterCharge's SDP as of February 2004. [Note that an issuer whose account data was exposed to possible compromise as a result of this event has a right to claim reimbursement for costs related to reissuance of cards and monitoring of potentially compromised accounts that remain open. For any given account, the issuer may request reimbursement of up to US$25.00 for each reissued card, or up to US$5.00 for each monitored account without reissuance. In theory, CardSystems could be liable for as much as US$1 billion in issuer charges if all 40 million cards were reissued.] End of June 18, 2005 Update.

Update, July 1, 2005: Infoworld's Ephraim Schwarz concludes that Visa and MasterCard weren't enforcing their own security requirements. "Frank Smith, vice president of the technology strategy group at Capgemini, said, 'They don’t supply due diligence to the whole system.' Gartner’s [Avivah] Litan said, 'They have everything in place; they just don’t enforce it.' Paul Stamp, security analyst at Forrester Research, said 'The processes were not properly enforced.' [John] Pescatore [a Gartner security analyst] said that the standards 'have been pure eyewash. No enforcement.' End of July 1, 2005 Update:

June 20, 2005 Update: CardSystems' CEO John Perry admitted to the New York Times (free registration required) that his company should not have stored the data that was compromised. CardSystems was using the stored transaction data for "research purposes." The Times article states: "Under rules established by Visa and MasterCard, processors are not allowed to retain cardholder information including names, account numbers, expiration dates and security codes after a transaction is handled." The article confirms that "security codes" refers to the three-digit or four-digit codes printed on the back of the credit card, which are specifically embargoed from storage by merchants or processors. End of June 20, 2005 Update.

Update July 22, 2005: Visa USA announced on July 18, 2005 that it will no longer allow CardSystems to process Visa transactions. Visa will allow banks that use CardSystems to handle merchant transactions until the end of October 2005. The New York Times also reported on July 19, 2005 that American Express will terminate its relationship with CardSystems at the end of October 2005. In congressional testimony on July 21, 2005, CardSystems' CEO John Perry said the firm faces "immediate extinction" and blamed former Cable & Wireless auditors for practices that led to the Visa termination. End of July 22, 2005 update.

H.R.1653 (a.k.a. "Safeguarding Americans From Exporting Identification Data Act" or the "SAFE-ID Act") is entitled "To prohibit the transfer of personal information to any person outside the United States, without notice and consent, and for other purposes." H.R.1653 expands S.768's list of sensitive personal information to include the following:

• Name
• Postal address
• Financial information
• Medical records
• Date of birth
• Phone number
• E-mail address
• Social Security number
• Mother's maiden name
• Password
• State identification information
• Driver's license number
• Personal tax information
• Any consumer transactional or experiential information relating to the person

Consumers must take explicit action ("opt-out") to prevent U.S. firms possessing the personal information from transmitting it to "any foreign affiliate or subcontractor located in a country that is a country with adequate privacy protection." Opt-in is required for countries that don't have "adequate privacy protection." Most privacy advocates would place the U.S. in the latter category. After the CardSystems debacle, ordinary U.S. citizens undboubtedly would do the same. However, it's not so clear that any U.S. government agency would have the courage to so categorize this country. Violation of the Act would be treated as a violation of a rule defining an unfair or deceptive act or practice prescribed under section 18(a)(1)(B) of the Federal Trade Commission Act (15 U.S.C. 57a(a)(1)(B)). Persons could bring a state court action "to recover for actual monetary loss from such a violation, or to receive $10,000 in damages for each such violation, whichever is greater." Related—but more restricted—proposed acts would "regulate information brokers and protect individual rights with respect to personally identifiable information" (H.R.1080 and S.500) and "strengthen the authority of the Federal Government to protect individuals from certain acts and practices in the sale and purchase of Social Security numbers" (H.R.1078). H.R. 1080 would permit persons to bring a state court action "to recover for actual monetary loss from such a violation, or to receive $1,000 in damages for each such violation, whichever is greater." H.R. 1080 doesn't designate a default damage amount. The probability of enactment of any of these proposals in the current congress is low, at best. Few proposed consumer privacy acts have significant bi-partisan support (read "Republican cosponsors"). Heavy-handed and well-funded lobbyists will attempt to kill the proposals in committee. But grass-roots concern with identity theft is growing, so there's hope for some future form of federal protection for "personally identifiable information" beyond that currently provided by HIPAA. Update: June 18, 2005: The Gramm-Leach-Bliley act of 1999 (15 U. S.C. § 6801 et seq., GLBA) includes provisions that are purported to protect consumers' non-public personally identifiable financial information (NPI) by restricting its transfer from financial institutions to non-affiliated third parties. Currently, GLBA applies only to financial institutions that provide services to consumers, such as Visa and MasterCard—but not processors/acquirers like CardSystems. What's worse, consumers must proactively (affirmatively) opt-out of the third-party information-sharing process. Adoption of the "opt-out" method (versus the more commonly accepted "opt-in" approach that applies to health-related information) was the subject of an intense lobbying campaign by the financial industry in general and credit-card issuers in particular. It's not known how many, if any, of the holders of the 40 million compromised credit cards had exercised their "opt-out" rights. A relatively simple (but very unlikely) method of minimizing exposure of NPI to third parties is amendment of GLBA to change "opt-out" to "opt-in" and include credit-card processors and any other organizations in the processing chain as "financial institutions." End of June 18, 2005 Update. --rj P.S. Bruce Schneier points out in his recent "U.S. Medical Privacy Law Gutted" post that a new ruling by the U.S. Justice Department "sharply limits the government's ability to prosecute people for criminal violations" of the HIPAA privacy regulations. Criminal penalties, the department said, apply to insurers, doctors, hospitals and other providers—but not necessarily their employees or outsiders who steal personal health data.