How to Record Debt Collector Web or Social Network Page

Coping with Bill Collection

Suppose you want to record your online interaction with an adversary . . . such as a collection agency.  Your goal is to capture reliable legal evidence of what you encountered when trying to access or provide information to the adversary’s web site or online app.

In effect, the video you create will record your eyewitness testimony of what you see online at a particular point in time.

You might want to do this, for example, to show that you tried to access a debt collector’s web site, but it was not available, did not work right or gave you misinformation.

Ten Steps

For making your record, here are 10 steps:

1.  Write out a step-by-step script of what you going to do and say as you make the recording.

2.  Launch your webcam so you can see yourself live on your monitor.

3.  Launch your browser or app so you can see that on your monitor at the same time you see the webcam image.

4.  Start a screencast recording program, such as screencast-o-matic (free, open-source service), to record what appears on your monitor.

5.  As the recording starts, identify yourself and explain the reason for your recording.  Explain the technical methods you are using to make the recording.  Don’t be afraid to read directly from your script.  Your purpose is to record legal evidence, not to make a television news cast.

6.  Use your browser or app and carefully explain each step you take.

7.  Describe what you see and what it means.

8.  Conclude the recording by signing and dating it with your voice.  Say words like, “I Ben Wright hereby sign and affirm this screencast as an accurate reflection of my work.”

9.  Review the video to ensure it is accurate.

10.  Soon after you create the video, store it in an online service such as Microsoft’s Skydrive, which records the date a file like the video was uploaded and last modified.

Example

Here is a hypothetical example.

This demonstration is not the only way to make records of online events.  And it does not cover all of the legal and technical issues that might apply to your particular situation.

If you need legal advice for your particular situation, you need to consult a lawyer rather than to rely on this educational blog and video.

This blog post and video intend to spark public discussion about ways to record online activities.  What do you think?

–Benjamin Wright

Attorney Wright teaches the law of data security and investigations at the SANS Institute.

Related articles:

*  Bill Collectors on Facebook
*  How to Make a Gotcha! Video
* How to video record online chat with legal adversary
* Recording Social Media Legal Evidence

Google+

TJX Breach Now Put into Perspective

Law of Payment Card Industry Data Security Standard

Excessive Cancelation of Compromised Credit Cards

The ring of criminals at the heart of the TJX credit card break-in has been indicted. The indictments help us evaluate the civil legal system's (especially the Federal Trade Commission's) response to the TJX heist. Read more at the new site for Wright's Legal Beagle, the thought-leadership blog for Messaging Architects.

More On TJX, Data Breach and Federal Trade Commission

Credit Card Security Law

Data Security Compromise Regulation

I argue FTC concluded its investigation of TJX wrongly. Which provoked this comment:

You state "Both TJX and Hannaford were informed, aware, thinking and making good-faith judgment calls using the technology of the day." What evidence do you have to back that statement? Everything that I have seen in the press implies that TJX was taking the calculated risk of saving the security expenditures, and lost that gamble. In that light, the actions of the FTC seem more reasonable.

Ben's reply: I agree TJX "took a calculated risk of saving the security expenditures, and lost that gamble". In order to take a calculated risk, you have to be informed about the risk.

Thus, point number 1: TJX was not ignorant of the issues.

Click Here

Point number 2: TJX acted in good faith.

What does "good faith" mean? It means (a) you hire qualified professionals to honestly look at your security issues, (b) you deliberate about your issues, and (c) you make and implement decisions – without (d) the desire or intent for credit cards to be stolen. TJX did exactly that. It did have qualified IT professionals. They debated in e-mail topics like whether WEP encryption is enough. TJX’s e-mail traffic about WEP is evidence of deliberation. And, I'll bet TJX (a large publicly-owned company) did not desire or intend for the criminals to break in. I have seen nothing in the press that TJX wanted or encouraged a break-in.

Point 3: TJX had a considerable amount of security; the security just was not enough to defeat the high-powered organized crime machine that hit. TJX's security was much greater than zero.

How Much Security is Enough?

To which, my commenter says:

I have not seen or heard of any evidence that TJX did or did not have either a considerable amount of security or any security at all. Is there any evidence in the public domain to support your assertion?

Ben’s reply: if TJX had no security at all, then thousands of unskilled, disorganized criminals of all descriptions would have descended on the company (by thousands of different channels) and stolen the company's data over and over and over again. That is not what happened. TJX had many elements and layers of security.

For example, it used WEP encryption to protect wireless in stores. I realize WEP is not perfect; perfect security does not exist. But WEP is more than zero.

Further, TJX implemented a process to upgrade from WEP to the stronger WPA encryption throughout its system, starting October 2005. The fact that the merchant even knew it needed to upgrade, and then it started implementing the upgrade, is evidence that TJX had a security program.

The FTC criticized TJX for having weak passwords. Implication: TJX did use passwords. Passwords are a security measure. FTC just believes the password practices were not strong enough. (Note: some security experts will argue that even the password practices the FTC advocates are woefully inadequate security. Which raises a question for the FTC to ponder: Would a merchant would violate FTC law if the merchant implemented the password security practices advocated by the FTC, given that some respected experts will say those practices are inadequate?)

According to the Wall Street Journal, TJX’s criminal assailants had to work very hard and systematically over an extended period of time. The assailants were obviously more talented and capable than a couple teenagers working over a weekend. Implication: TJX's layers of security were not easy to defeat.

Further, the assailants had to train some kind of telescope antenna on a store from a distance in order break into the wireless. (Joseph Pereira, “How Credit-Card Data Went Out the Wireless Door,” Wall Street Journal, May 4, 2007, A1). The implication: TJX had physical security. It would not let just any bum walk into a store and start physically messing around with computers.

I am confident a complete report on TJX would show it had many security measures. March 28, 2007, TJX filed a 10-K with the SEC saying or implying it had (during time of the break-in) many security layers (including liberal use of encryption), many of which the patient criminals eventually defeated.

Punishing Honest, Good Faith Mistakes

Did TJX make mistakes? Probably so. But they were honest mistakes. Legally speaking, an honest mistake should not be “unfair” as the FTC claims.

If the FTC is serious about punishing honest mistakes, then to be consistent, it must get much more deeply involved in the topic of credit card security. The whole credit card system is rife with honest mistakes. Why doesn’t the FTC investigate credit card systems as whole systems? Where is it written that credit cards, as presently designed, could not be improved from a security perspective? Criminals defeat the credit card systems every day. Why, therefore, are the systems not "unfair" by the FTC's standard?

The National Retail Federation advocates that the credit card system be changed so that transactions require PINs. PINs would reduce credit card abuse. Why, therefore, doesn't the FTC open an investigation into whether the failure to require PINS constitutes "unfairness" to consumers?

What purpose does the FTC serve by singling out TJX when other components in the credit card system are equally if not more weak?

FTC implies that if TJX will just implement a bunch of PCI-style controls (and submit a bunch of paperwork to the government), then TJX’s unfairness will be remedied. But the fundamental problem will remain at TJX and other retailers. A serious school of thought says PCI is not enough to defeat professional criminals.

(Update: Joel F. Brenner, the top US counterintelligence officer say, "Pretty small but intelligent criminal organizations all pulling off transnational, multicontinent heists that only a foreign intelligence service would have been able to do a few years ago." Gorman, "Credit Card Fraud Found in Europe," Wall St. Journal, Oct. 11-12, 2008. Criminals are embedding snooping devices into point of sale card readers.)

FTC's action is out of touch with the genuine security problems facing credit cards.

Perfect security cannot be achieved in a merchant's IT system at an economically acceptable cost. For a business as complex as TJX, it will always be true that even after you implement a lot of security, it might not be enough. The only way for a big retailer to eliminate credit card security risk is to either shut down or spend an insane amount of money on security. All retailers, therefore, must take calculated risks.

Point number 4: To take a calculated risk is good, not bad! The FTC is wrong to punish merchants that take calculated risks.

FTC is attempting to serve the public’s best interest. But the agency made an honest mistake. It needs to rethink the legal concept of “unfairness” with respect to credit cards, and it needs to rescind its TJX settlement.

For more on this, see my earlier article on FTC and TJX.

Update: I explain how August 2008 indictments of TJX hackers put FTC's treatment of TJX into perspective.

Update March 2009: National Retail Association argues that the PCI is ploy to shift risk from banks and card companies and onto the shoulders of others such as retailers.

--Benjamin Wright
Mr. Wright teaches the law of data security and investigations at the SANS Institute.

FTC treats TJX Unfairly . . . Compare Hannaford & Okemo

Is PCI Non-Compliance Legally Wrong?

What is Reasonable Computer Security for Credit Card Data?

The Federal Trade Commission should rethink the law of credit card data security applicable to merchants like TJX. As a consequence of the data security breach TJX disclosed in 2007, TJX and the FTC entered a settlement requiring TJX for the next 20 years to engage in an expensive, government-supervised data security program. The program entails the maintenance of controls and extensive paperwork reporting about those controls to the FTC.

According to FTC, the grounds for its action against the retailer were that TJX had engaged in "unfair practices" in violation of Section 5(a) of the Federal Trade Commission Act, 15 U.S.C § 45(a).

The "unfairness," according to the FTC, was that TJX collected private credit card information from consumers, but failed to use adequate security procedures to protect it. This resulted in compromise of tens of millions of credit card accounts. By declaring that TJX was "unfair," FTC

Payment Card Insecurity

implied TJX had been bad. In other words, FTC found the TJX incident was worse than just unfortunate or embarrassing. It was the result of punishable culpability by TJX.

TJX Was Not Deceptive or Utterly Inattentive to Security

Note what the FTC did not allege about TJX. The FTC did not allege TJX engaged in a "deceptive trade practice" in violation of Section 5(a) of the FTC Act. An example of deception is for an enterprise (like ChoicePoint) to tell individuals it will secure their data, and then fail to do so.

Further, the FTC did not allege TJX was utterly inattentive to security. The FTC essentially said TJX was unfair because it was not secure enough . . . not secure enough to defeat the sophisticated criminal organization that broke into it. And the FTC said the remedy for this unfairness is that TJX should implement security controls, more or less like the PCI-DSS (Payment Card Industry Data Security Standard). The implication: if a merchant follows the PCI, then it has achieved "fairness."

FTC's Remedy Does Not Achieve Its Goal

Compare what FTC just said to TJX, with what happened at retailer Hannaford. Hannaford announced that 4.2 million credit card numbers were stolen from it, but Hannaford says it was PCI compliant during the time in question! Apparently the hackers tapped fiber-optic cable that "security experts had believed was secure."

Further, Okemo Mountain Resort, a Vermont merchant, says it complied with PCI, but was still broken into. Pereira, "Credit Card Security Falters," WSJ, Apr 29, 08.

The Hannaford and Okemo experiences suggest PCI compliance is not enough to defeat the talented criminal gangs assaulting the credit card system today. In other words, compliance with controls like those FTC imposed on TJX is not enough to protect credit card data.

The reality may be that it is impractical for merchants to protect credit card data from the criminals who broke into TJX and Hannaford and Okemo. If that is true, then TJX did not engage in unfairness. It was a victim of criminals who are swiftly becoming more powerful.

Why Does the FTC Ignore the Heart of the Credit Card Security Problem?

In essence FTC said TJX was an unfair bad guy because it could not keep up with the hackers. But by that standard, is not the entire credit card system "unfair?" Instead of picking on particular players like TJX, why doesn't FTC investigate the credit card systems as a whole (Visa, Mastercard, American Express et al.) and probe whether credit cards are inherently "unfair" to consumers because criminals can defeat the systems? Why doesn't FTC require each of the systems to devise better designs and controls so consumers are no longer subjected to the "unfairness" of the systems as presently designed? (See this post on alternative ways to authenticate credit card users and transactions.)

My point is that TJX was not "unfair." It was unlucky. Its defenses were similar to that of many (most) of its peers at the time. They too would have fallen had they been subjected to the same criminal blitzkrieg. And during the time in question, the PCI was vague, reltively new and subject to wide interpretation and debate. (It still is.) The same is true for the controls FTC just imposed on TJX.

FTC Is Confused

FTC is well-meaning here, but it is misdirected. By singling out TJX and chastising it with the "unfairness" "bad guy" rhetoric, FTC distracts the necessary public conversation. It implies that if we can just punish these lazy merchants enough (and force them to comply with PCI and similar controls), then credit cards will be safe. That's wrong.

The criminal warfare directed at the credit card system is more powerful than the theory behind PCI. The whole credit card system needs to change. As a society we need to focus on beating the criminals, and stop flogging victims like TJX as unfair privacy infringers.

--Benjamin Wright

(I have posted more remarks on TJX and FTC.)

Update: I explain how August 2008 indictments of TJX hackers put FTC's treatment of TJX into perspective.

Update: Many of TJX's peers did, apparently, fall victim to the same blitzkrieg as TJX. Prosecutors say the gang that broke into TJX also broke into 8 other large retailers, though some of those retailers cannot confirm their defenses were breached. Pereira et al., "Some Stores Quiet Over Card Breach," WSJ, Aug 11, 08, B1.

Further Update: September 2008 prosecutors say the TJX hackers broke into "numerous other businesses" in addition to the 8 previously disclosed. Ross Kerber, "Hacker pleads guilty in breach," Boston Globe, Sept. 12, 2008. Therefore, TJX was not unusual; TJX was no weaker at the time in question than was standard and common in the retail industry. Query whether FTC will open investigations of all these other retailers and claim they were "unfair" also.

Update March 2009: Heartland Payment Systems maintains that an auditor confirmed it was PCI compliant a mere month before hackers broke into the company and stole credit card data. Visa investigated after-the-fact, and Visa has tried to say that Heatland was not PCI compliant. But PCI expert David Taylor observes that if the goal of an investigation is to determine that an organization is not in compliance, then the goal is easy to achieve. Perfect data security never exists in practice.

Assembly Bill (AB) 779 Suffers from Sloppy Draftsmanship

[Update: The California Governor vetoed AB 779.  See more current information on merchants and the protection of credit card data.]

I am no fan of the part of California’s pending AB 779 that absolutely forbids merchants from retaining certain payment data. It smacks of a legislature precisely (an incompetently) dictating technology. When a legislature dictates technology, it risks misunderstanding. It stifles innovation, and raises problems as technology evolves.

Let’s dig into the details. AB 779 proposes to add Section 1724.4(b)(2) to the Civil Code. The section flatly forbids a merchant from storing:

"sensitive authentication data subsequent to authorization . . . . Sensitive authentication data includes, but is not limited to, all of the following: . . .
(B) The card verification code or any value used to verify transactions when the payment device is not present."

Notice that the quoted language does not definitively tell us what "sensitive authentication data" is. It says the term includes – but is not limited to – certain things. That’s unsettling. Apparently the legislature expects a merchant to make a guess about what does and does not constitute "sensitive authentication data".

In the 1990s a pioneering Internet payment company (one of PayPal's many early competitors) named First Virtual Holdings invented a commercially-viable payment system that involved the payer giving the merchant a semi-secret code to kick-off a transaction. But that code was not really intended to be a hard-core secret. One of the key ways the payer could give the semi-secret code to the merchant was via unencrypted, Internet e-mail. See Benjamin Wright, The Law of Electronic Commerce, page ET1:19, Second Edition, published by Little, Brown & Company, 1995. Clearly the First Virtual system contemplated that merchants would store the semi-secret code, such as in their usual e-mail archives. Furthermore, First Virtual obviously considered the semi-secret code sensitive enough that merchants were not expected to publish it on a bulletin board or in a public directory.

If someone tried to use the innovative First Virtual system under AB 779, new Section 1724.4(b)(2) would prevent the system from working as intended. It would prohibit the merchant from storing sensitive authentication data, which according to the language of 1724.4(b)(2) includes the semi-secret code. The semi-secret code certainly appears to fit AB 779's definition of "sensitive authentication data", which includes but is not limited to things like a "value used to verify transactions when the payment device is not present." Without the semi-secret code, a First Virtual transaction could not be verified.

[At this point we have to take a pit-stop and examine whether Section 1724.4(b) is intended to cover a payment system like First Virtual. Section 1724.4(b) purports to cover any merchant that "accepts as payment a credit card, debit card, or other payment device." Maybe the First Virtual system did not involve a payment "device" because it did not involve a plastic card. However, if that is the case, then Section 1724.4(b) does not cover virtual credit card numbers. With virtual credit card numbers, payers use Internet-only card numbers that are not tied to physical plastic cards. Virtual credit card numbers work on the Internet the same way that numbers associated with plastic cards work on the Internet. They involve all the same data elements. It would seem, therefore, that the legislature intends merchants to protect data related to virtual credit card numbers the same as data related to plastic cards. And if the legislature intends to cover virtual credit card numbers, then it intends to cover First Virtual’s system too. Like virtual credit card numbers, the First Virtual system simply involves the exchange of codes. . . . Now, hang in here with me a moment. Suppose an apologist for AB 779 says that that Section 1724.4(b) is not intended to cover virtual payment methods like First Virtual or virtual credit card numbers because they do not involve physical "devices". Okay. If that is the case, then logically Section 1724.4(b) does not cover any Internet or mail-order payments. The reason is that Internet and mail-order credit card transactions do not literally involve acceptance of physical cards or devices. As I said above, 1724.4(b) covers merchants that accept "cards" or "devices". But if "cards" or "devices" mean only physical stuff, then Internet and mail-order merchants are not accepting those things. Internet/mail-order merchants have no knowledge of or contact with physical cards or devices. When a payer gives credit card data to an Internet or mail-order merchant, the merchant does not know whether the data connects to a plastic card or a virtual card. . . . But surely the legislature intends Section 1724.4(b) to cover typical Internet and mail-order credit card transactions. Thus, it seems certain that the legislature likewise intends to cover things like First Virtual and virtual credit card numbers. {Footnote: As you can see from the analysis in this pit-stop, Section 1724.4(b) is ambiguous on whether it covers Internet and mail-order credit card transactions. Such ambiguity bespeaks poorly-crafted legislation.}]

Let’s go back to the language from Section 1724.4(b)(2) quoted at the beginning of this note. It says data that may not be stored includes "any value used to verify transactions when the payment device is not present." Sometimes, to use my credit card at a physical point of sale device, I have to enter my zip code. My zip code is in fact a value used to verify the transaction. Does this mean merchants cannot story my zip code? If they cannot store my zip code, then how can an Internet or mail-order merchant work out shipping and returns with me? All Internet and mail-order merchants store zip codes.

Now, I acknowledge that when I'm using my card at a physical point-of-sale device, the zip code is not a "value used to verify transactions when the payment device is not present." My card is present.

But think about this . . . Merchants always depend on disclosure of my zip code when they accept my credit card by mail-order or over the Internet. If I don't give them a good zip code, the transaction cannot be verified. So in point of fact, in an Internet or mail-order scenario, my zip code is a value used to "verify transactions when the payment device is not present." When requested in either the mail-order scenario, the Internet scenario or the point-of-sale scenario, the zip code does in fact verify the transaction. Therefore, Section 1724.4(b)(2) -- if understood literally -- forbids the storage of zip codes by mail-order and Internet merchants. {Footnote to people who are skeptical of my argument here: Remember the style the legislature used when it defined "sensitive authentication data". 1724.4(b) tells us what the term means by saying it includes but is not limited to certain itemized things. The legislature left the definition open-ended. That implies the term should be interpreted broadly, not narrowly. Essentially, the legislature said, when in doubt about whether a data element constitutes "sensitive authentication data", you should assume it does. Therefore, a rational person can conclude that a zip code constitutes "sensitive authentication data" that may not be stored.}

Now, hang in here with me. I acknowledge that the legislature probably does not intend to forbid the storage of zip codes by mail-order or Internet merchants. However – and this is my point – the literal legislative language is confusing here. The legislature has not been crystal clear in defining "sensitive authentication data". The words themselves seem to suggest that "sensitive authentication data" includes zip codes, and that suggestion would cause fits for Internet and old-fashioned mail-order merchants.

Confusing language like this threatens to be unduly constricting as time passes and people like First Virtual try to innovate. Section 1724.4(b) is poor legislation.

Storing security codes under HF 1758 and AB 779

I just participated in a SANS webcast on payment data security law. I made at least one mistake in describing Minnesota's HF 1758 and California's pending AB 779 (new legislation forbidding merchants from storing certain payment data). One or two people asked questions about the storage of sensitive data such as a credit card security code before a merchant recieves bank authorization to process a transaction. I believe I said that such storage is not permitted under HF 1758 and AB 779. I was wrong. I have re-read those bills. They only forbid the storage of certain sensitive data such as credit card security codes after authorization is recieved.

Thus, it appears that under HF 1758 and AB 779 a merchant could store credit card security codes for a time before seeking authorization.

[As I emphasized in the webcast, I never give legal advice in public statements and presentations. If you need legal advice, you should talk to a lawyer and not rely on my public statements.]

These are new laws, and my interpretations of them could be wrong. If anyone sees I have made a mistake in this blog, in the webcast or in another venue, please let me know. I am eagar to learn.

Comparing AB 779 and HF 1758 (New Payment Card Data Laws)

California is ready to adopt new legislation regulating the management of credit card data by retail merchants. The legislature has passed Assembly Bill (AB) 779, the so-called Consumer Data Protection Act, and submitted it to the governor for signature. Proponents believe Governor Schwarzenegger will sign the legislation. [Update: He vetoed the bill. But this discussion is still relevant to those thinking about how data security law should and should not be written.]

Similar to Minnesota's HF 1758, AB 779 contemplates that a merchant will reimburse credit card issuers for costs they incur replacing cards after the merchant suffers a data security breach.

Under Minnesota's HF 1758, the reimbursement requirement only applies if the merchant commits the "transgression" of storing card security data or full magnetic stripe data longer than 48 hours after transactions are authorized.

Compare California’s AB 779. Under 779, the merchant can be excused from the reimbursement requirement if the merchant avoids certain "transgressions" such as storing full track data, storing payment verification codes, transmitting unencrypted payment data over the Internet and storing payment information without a proper data retention policy.

Hence, HF 1758 and AB 779 are similar in the way they impose liability. Both laws effectively say a merchant that suffers a data breach must reimburse card issuer costs if the merchant has committed any of the identified transgressions. Further, both laws require reimbursement even if the breach is unrelated to the transgressions.

In other words, this is what the literal words of the Minnesota and California legislatures seem to mean: If a merchant commits even one tiny transgression -- even one unconnected with any actual break-in -- then that merchant is ineligible to avoid liability for card replacement costs when a break-in does occur.

Analysis: This scheme for imposing liability does not seem fair or rational. It requires perfection. Few organizations can be perfect in avoiding the data security transgressions identified by the legislatures. But many organizations might do a reasonably good job of avoiding those transagressions. Yet the legislatures offer no reward for being reasonably good. They only reward perfection.

Definition of Data Security Breach

When Has Privacy of Credit Card or Social Security Numbers been Compromised?

Security Incident Response and Information Protection Law

Many states now have data breach notification laws modeled on or inspired by California's SB 1386.  Usually, under 1386, an enterprise holding private information (name plus social security number, driver’s license number or financial account number + password) in electronic form about a California resident must promptly notify the resident if the enterprise suspects a breach in security.

In all these data notification laws, a key issue is the definition of what constitutes a breach of data security. Just because a hacker accesses data related to a credit card account does not mean that the account has in fact been compromised (or, in the alternative, that the data has been compromised in any meaningful way). The credit card system features many layers of security beyond simply the purported confidentiality of a person's name + credit card number + card security code.

Thus a corporation holding data might detect that a hacker accessed card data, but still conclude (based on other controls in the industry) that none of the card data in question had in fact been "compromised". The other controls I speak of can include monitoring of card activity, telephoning cardholders to confirm transactions and much more.

Confusing and Unnecessary Notices

To send unnecessary breach
notice is unethical.

If a data owner is too quick to conclude that a minor slip in security constitutes a "data security breach", then the owner will senselessly waste money and confuse constituents by sending them unnecessary notices and providing them unwarranted credit protection services. Further, excessive conclusions that a breach has occurred can lead to credit cards being replaced so often that cardholders don't know which of the cards in their wallet is valid and which is not.

Crying WOLF

When the public hears too many announcements that data has been "BREACHED," it becomes like the villagers who grew insensitive to the boy's cries of "WOLF". For that reason, I argue enterprises are legally and ethically justified to expect that a reasonably high threshold be crossed before they send out notices of a "data security breach."

2013 Reform

I published most of the foregoing in 2007 and 2008.  Fortunately, in 2013 a leading authority has reviewed this issue carefully and instituted reform.  The U.S. Department of Health and Human Services now says that a breach notice is required only after a sophisticated risk assessment has determined a notice is justified.  See my analysis of HHS's new regulation on data security breach notice.

--Benjamin Wright

Attorney Wright teaches the law of data security and investigations at the SANS Institute.

Update July 2008: Anton Chuvakin makes an interesting observation. If dataholders maintain good system logs, then in the event of a security breach they can examine the logs carefull to determine with precision which particular data files (if any) were compromised. That would allow them to notify only the people affected, rather then everyone on whom they hold data.

For more on this topic, see my other article on data security breach.

Update Summer 2008: See my analysis of a breach notification where data on stolen laptop are encrypted, and my examination of the definition of "private" data.

(Reminder: Nothing I publish is legal advice to anyone and not a substitute for advice from a lawyer.)

Unfairness in Minnesota's Credit Card Security Legislation

Retailer Liability to Banks for Credit Card Data Breach

Minnesota's pioneering PCI legislation, HF 1758 (Plastic Card Security Act) requires payment card merchants to reimburse the costs of financial institutions when they replace compromised cards.  A colleague of mine at the SANS Institute,  Joshua Wright (wireless security instructor), sent me a question.  Here's Joshua's question, and my reply:

[begin quote from Joshua]
[Concerning an essay published by SANS]: in the section "Altering the Ecosystem", you stated:

"H.F. 1758 bluntly states that a merchant may not retain certain card data, such as a card,s security code and the full data from the card's magnetic stripe. It further provides that if a merchant does retain such credit card data, and that leads to a breach of a card's security, then the merchant must reimburse the financial institution that issued the card for the reasonable costs incurred to avoid damage."

My question is surrounding the wording "... and that leads to a breach of a card's security". Is it stated in H.F. 1758 that the storage of the data has to be a contributing factor that leads to the breach of the security of the system? I read this as stating that vulnerabilities in the organization's security are directly caused by the storage of this data, and that furthermore, it implies that the motive of the attacker compromising the resource was to retrieve this stored information.

IANAL, but I think this would give a defense attorney an easy-out for their customer, simply by showing that the attack was opportunistic, or that the attacker could not have known that the protected data was stored in the organization's network.

Consider the case of the Lowe's attack with Timmins and Botbyl.  They used a weak wireless configuration to access the Lowe's network, and eventually planted packet sniffers to collect CC information. This could be argued as being an opportunistic attack, and that Lowe's is not responsible for any bank charges since the storage of the credit card information did not directly lead to the breach in security.

I may be bending words here, but I'm hoping you can clarify your perspective. Note that I am not asking for legal advice, just your interpretation of the bill so I can communicate this to my students.
[end quote from Joshua]

[Ben's reply:]
Joshua:

Thanks for your good question. HF 1758 is poorly written, and my summary of it does not precisely reflect the ill-chosen words of the legislation.

Subdivision 2 of HF 1758 basically says a merchant is forbidden from retaining a credit card security code or credit card mag stripe data. Next, subdivision 3 says that if a merchant does retain the forbidden data, then, in essence, the merchant is in the class of what I'll call dis-favored merchants under the legislation. Further, subdivision 3 says that if a merchant in the dis-favored class suffers a breach of security that compromises personal info, then that merchant must reimburse the costs incurred by a bank to protect the information of its cardholders.

Notice that the legislation does not say the breach of security has to compromise the forbidden data (card security code or mag stripe data) in order to trigger the special obligation to reimburse banks. One might reasonably interpret the legislation as requiring the breach to affect the forbidden data, but the legislation does not explicitly so require.

Hence, the direct answer to your question is no, the storage of the forbidden data does not have to be a contributing factor to the breach in order for the bank to achieve extra-ordinary rights of reimbursement.

Here is why I think HF 1758 is poorly written. Suppose Wal-Mart has a single malfunctioning point of sale device in a store in Mexico that mistakenly stores the forbidden data from a single card. The implication is that, due to this single faux pas, Wal-Mart as an entire entity is a dis-favored merchant under HF 1758. Then, suppose Wal-Mart suffers a breach of security in a regional data center servicing the upper Mid-West (including Minnesota). The breach of security affects personal information of credit card holders. The result is that Wal-Mart (a member of the class of dis-favored merchants) must reimburse the costs of banks that cancel cards as a result of the breach -- even though reimbursement is not required under the contracts and standards negotiated among players in the credit card industry. And Wal-Mart's special requirement to reimburse arises because of a single, insignificant blunder in Mexico that has nothing to do with the breach of security in the Mid-West data center. Thus the punishment to Wal-Mart seems to be disconnected from and out of proportion to the mistake (storing forbidden data from a single card in Mexico).

--Benjamin Wright

Update: HF 1758 was an over-reaction to the TJX break-in. See more of my analysis of that over-reaction.

PCI Law: Should retailers pay when they lose card data?

Is PCI-DSS (Payment Card Industry Data Security Standard) a Sufficient Standard of Care to Support Retailer Liability to Banks?

Credit Card Number Security Incident Response

The mechanics and theory of credit cards are so jerry-built that it is legally unfair to make merchants pay damages to anyone when credit card data leaks to criminals. The credit card system was not designed with the idea that merchants would need Fort Knox-style security to protect electronic information. It was only after the system became wildly popular that financial institutions (acting through the PCI) articulated heavy data security burdens for merchants.

It remains an open question whether the johnny-come-lately PCI rules are effective at protecting the credit card system. Even after a merchant spends lots of money becoming "PCI compliant," hackers can still break into the merchant and steal the little units of data (name, account number, expiration date, security code) upon which the system so heavily relies. That's not because the merchant is negligent or guilty of privacy crime. It is because commercial information systems are inherently vulnerable to modern hackers in search of discrete units of data like names and numbers that are used over and over and over again.

The credit card industry needs to invent new ways to authenticate people and transactions, and to place less emphasis on maintaining the confidentiality of data elements like name plus account number plus security code.

I have published more analysis on the topic of merchant liability for a credit card data breach.

--Benjamin Wright

Mr. Wright teach the Law of Data Security and Investigations at the SANS Institute