Hack-igations

Hack-igations
The word "hack-igations" meshes hacking + litigation + investigations.

This blog examines the intersection of law, technology and
(audit, police, forensic, liability, security and regulatory) investigations.

Wednesday, November 14, 2007
Instant Message Record Retention & E-Discovery
Some large corporations are coming to rely heavily on instant messaging (IM). My humble prediction is that they will eventually find themselves needing to retain IM records the same as they do e-mail records.

Today I am not aware of a judicial decision punishing an enterprise for failing to store (or for being unable to find) IM records, but the cases will eventually come. Litigants will seek access to IM records under the e-discovery provisions of the rules of civil procedure.

IM records are already being created, though corporate IT departments may not be storing them centrally. User's PCs are creating those records. And, the latest operating systems such as Vista and Apple's Leopard automatically make shadow copies of everything on a PCs hard drive, which includes IM logs.

Eventually, corporations will come to believe they are wise to store all IM records centrally. When those records are demanded as part of e-discovery (or as part of an internal fraud investigation), an enterprise prefers to sift through centrally-managed records than to search for local records on individual PCs.

Some will take the attitude that if IM records are discoverable, then IM should be banned from the enterprise. I disagree with that attitude. If tools like e-mail and IM are helping people be productive, then those tools should be available for use.

All electronic tools (PCs, smart phones, e-mail, IM etc.) create records that are discoverable in litigation. The quantity of records grows much, much bigger every day. This reality is something any enterprise should become accustomed to.

Rather than trying to prevent the creation of records, which is a futile undertaking, an enterprise is wiser to look for ways to understand and exploit its ever-growing ocean of records. In litigation (and elsewhere) voluminous records can be used to advantage.

Posted by Ben Wright at 8:02 PM 0 comments Links to this post

Labels: e-discovery, electronic evidence, records


Wednesday, November 7, 2007
Social Networking Privacy Terms of Service
Privacy advocates such as NYU professor Clay Shirky argue people should be entitled to a degree of privacy for their postings in social networking sites like MySpace and FaceBook. They argue employers (for example) should not as a matter of public policy be trolling these sites to spy on employees or prospective employees. See this video:



An idea: People could post legal terms of service on social networing pages declaring that employers and prospective employers are forbidden from looking at or copying from the pages. Such terms would be like No Trespassing signs on land. Some case law supports the notion that terms posted on a web site can restrict the right of visitors to gather information off the site.

Arguably, if an employer grabs information off of a site in violation of posted terms, and that leads to termination of an employee, then the employee could sue the employer for violating the terms of the web site.

Even if the terms are not legally binding on the employer, they could be ethically binding. An ethical obligation can be more than high-minded hot air. It can carry substantive implications. For example, suppose Bob posts a prominent notice on his MySpace page that his employer may not view the site. Suppose further that the employer ignores the notice, looks at the page, doesn't like what it sees, and fires Bob. The employer might be poisoning its relationship with its entire employee population. Many employees may feel the employer had crossed a line it should not have crossed. Moreover, many customers and suppliers might feel the same way when they learn about Bob's plight.

Posted by Ben Wright at 7:14 PM 0 comments Links to this post

Labels: terms of service


Wednesday, October 3, 2007
Assembly Bill (AB) 779 Suffers from Sloppy Draftsmanship
[Update: The California Governor vetoed AB 779]
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 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.

Posted by Ben Wright at 8:05 PM 1 comments Links to this post

Labels: AB 779, credit cards, payment cards, PCI-DSS


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.

Posted by Ben Wright at 11:32 AM 0 comments Links to this post

Labels: AB 779, credit cards, data break-in, payment cards, PCI-DSS, security law


Friday, September 14, 2007
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.

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.

Posted by Ben Wright at 5:22 PM 3 comments Links to this post

Labels: AB 779, credit cards, data break-in, payment cards, PCI-DSS


Tuesday, September 11, 2007
The Law of Anti-Forensics Tools
Hackers use so-called anti-forensics tools to make break-ins harder to detect and harder to trace once they are detected. Observers have
speculated that anti-forensic tools helped the crooks who stole credit card data from TJX.

If a hacker is caught using anti-forensics tools, it will be easier to prosecute him and impose stiff punishment. The use of such tools will be evidence of his sinister intent.

Historically prosecution of hackers has sometimes been hard if they did not clearly steal anything. The hackers garnered some sympathy by saying they were just snooping around and not trying to harm anyone. But if a hacker uses anti-forensics tools, any sympathy will evaporate.

Posted by Ben Wright at 6:44 PM 0 comments Links to this post

Labels: computer crime, data break-in, hackers


Friday, September 7, 2007
Endless investigations
Engadget reports that a motorist successfully stymied a drunk driving prosecution by demanding to see the source code for the breathalyzer used to determine he was drunk. This story is a specific example of a big phenomenon in our legal system, caused by technology.

Information technology begets an ever-growing ocean of records. Records are irresistable to a legal investigation. Any investigation naturally wants to delve into all the relevant records. The relevant records in a drunk driving case include even the source code of the breathalyzer used to determine the driver was drunk.

Net result: legal investigations and prosecutions grow ever more expensive and difficult to close. In any controversy, there are always more records to inspect and argue about. If you want to gum-up an investigation, just demand access to more relevant records.