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.

A Business Intelligence Demo with Real-World Data

The Gartner Group attributes much of the 10.3 percent growth of the total relational database market from 2003 to 2004 to new business intelligence features—data analysis, warehousing and reporting—as well as the weakening US dollar. Gartner's May 2005 "No Clear Winner in Overall RDBMS Market Share Race" report gave IBM 34.1%, Oracle 33.7%, and Microsoft 20% of the total market. Teradata, Sybase, and others claimed 2.9%, 2.3% and 6.6%, respectively. Microsoft's market share increase from 18.7% in 2003 is surprising when you consider that prospective licensees were then anticipating Yukon to release to manufacturing in mid-2004, not November 2005. eWeek magazine's Lisa Vass quotes Microsoft director of SQL Server product management, Tom Rizzo: "BI is a tremendous growth driver for us, especially Reporting Services, which we've seen a ton of customers buying and deploying. That's why we invested so heavily in BI technologies across SQL Server. ... We put a down payment many years ago, and now it's paying off in terms of revenue growth." Unlike its major database competitors, Microsoft includes business intelligence integration, development, reporting and management features in the basic license fee for all editions of SQL Server 2000 (except MSDE) and SQL Server 2005 (except Express and Workgroup editions, which do include Reporting Services.) SQL Server 2005 has a raft of new and improved business intelligence (BI) features. But the standard sample online transaction processing (OLTP) and data warehouse (DW) databases are based on the relational AdventureWorks sample database. Demonstrating the performance of Integration Services (SSIS, formerly Data Transformation Services. DTS) extract, transformation, and loading (ETL) features isn't practical with tables that contain only a few hundred or thousand rows. You need partitions containing multimillion-row dimension and fact tables to emulate the BI systems of, for example, nationwide or multi-national retailers. The table-size issue with performance testing is similar to that I describe in my FTP Online articles about SQL Server 2005's xml data type and data encryption features. Microsoft's Project REAL is "a reference implementation of a business intelligence (BI) system using real large-scale data from a real customer." Phase 1 of the project used source data from a large electronics retailer. Phase 2's "real customer" is Barnes & Noble, the largest U.S. bookseller, who contributed the masked source data and BI scenario. Barnes & Noble have about 40,000 employees and 800 stores in the U.S.

According to the Technical Overview for Phase 2, Project REAL's goal "is to discover the best practices for creating BI systems with SQL Server 2005 and to build a system that exhibits as many of those best practices as we can. This project is not just a demo—we are creating this system for ongoing operation. It is a complete system, including daily incremental updates of the data, large multiuser workloads, and system monitoring."

The Technical Overview is the first in a promised series of articles that will be based on the B&N source data and analytical model. Hopefully, the Project REAL team will provide dynamic, online demonstrations of simulated ad hoc and preprogrammed BI reports. Making Project REAL's warehoused data and Reporting Services accessible to developers by Web service methods similar to those for TerraServer or MapPoint maps would be a major SQL Server 2005 marketing coup.

Hey, Tom Rizzo—are you listening?

--rj

Microsoft Promises RSS 2.0 Support in Longhorn

Steve Ballmer reportedly considers RSS "a little too simple," but damnation by faint praise by Microsoft's CEO hasn't prevented the Longhorn team from climbing on the RSS bandwagon. Dean Hachamovitch, general manager for Longhorn browsing and RSS announced in a June 24, 2005 keynote speech at the Gnomedex 5.0 conference that Longhorn will include support for RSS with a Common RSS Feed List and Data Store, plus an RSS Platform Feed Engine. Hachamovitch also proposed a specification for an RSS extension to support ordered lists. Despite its release under a Creative Commons Share-Alike license, the "Simple List Extensions Specification" generated an extraordinary amount of third-party blogging and comment activity, much of which was uninformed. The next day, a Longhorn RSS Team Blog opened with a post from Sean Lyndersay, senior program manager on Microsoft's RSS team and majordomo of the MSDN IEBlog. Developer feedback is handled by Channel9 Longhorn RSS and SimpleListExtensions WIKIs. Unfortunately, the RSS in Longhorn announcement occurred about three weeks after the publication date of my "Longhorn Redux" FTPOnline article, which concentrated on consumer features and IIS 7.0. It's good to see a feature added to—instead of removed or borrowed from—Longhorn for a change. --rj