Zurich can't dodge $1M+ liability for credit card hack of insured bank; Court finds fraud coverage impermissibly swallowed by exclusion

(I should note that I wouldn't normally post on a case like this. But, considering that "cyber insurance" is a hot topic, I thought it appropriate given the interesting facts)

In First Bank of Delaware v. Fidelity & Deposit Co. of Maryland, No. N11C-08-221 MMJ (Del. Super. Ct. Oct. 30, 2013), a Delaware court held that Fidelity (now Zurich), could not avoid liability for a hack of its insured (First Bank) which resulted in monetary assessments against the bank (for fraudulent use of the credit cards), brought by Visa and Mastercard. The court found the insurance contract unambiguous, but balked at Fidelity's attempt to construe its insurance contract in a manner that allowed a coverage exclusion to swallow the original grant of coverage. Harkening to my days in insurance law, it is axiomatic that contracts are construed against the drafter. As a result, the superior court's opinion granted First Bank's motion for summary judgment on both of its breach of contract causes of action; Fidelity was found in breach of contract for denying reimbursement for the aforementioned assessments.

The facts, as described by the court:

The primary issue in this case is whether First Bank’s insurance policy provides coverage for losses incurred in connection with a data breach incident. Fidelity issued the D & O SelectPlus Insurance Policy (“Policy”) to First Bank

(that policy, by the way, can be found here: Zurich Private Company Select); continuing:

First Bank had a relationship with a company then known as Transend, LLC (“Transend”) for certain card transactions. Transend had a similar relationship with Data Access Systems (“DAS”). Transend introduced First Bank to DAS. First Bank provided DAS with access to the Visa and MasterCard networks.
…
First Bank was liable for any losses or expenses caused by its agents under the Visa and MasterCard agreements designating First Bank as a principal member of the networks.
…
DAS’s web server terminal was hacked on or about May 17, 2008. The hackers gained access to debit card numbers and the corresponding personal identification numbers. Millions of dollars of unauthorized withdrawals were taken from customer accounts as a result of the data breach. DAS hired VeriSign, a computer forensics firm, to investigate the hacking. VeriSign concluded that DAS was not in compliance with PDI DSS, the security standard required by the Visa and MasterCard agreements.

After the breach, First Bank was assessed fees by both Visa and Mastercard which, together, totaled over $1M. First Bank asserted that their policy with Fidelity covered such losses; Fidelity disagreed and denied coverage.

The court proceeds to analyze the insurance contract and the various clauses. Prior to the analysis of "Exclusion M," the outcome looked promising for Fidelity. But, as always, the other shoe dropped. The court:

Section 4 Exclusion M 

Section 4 contains a list of exclusions from coverage. Exclusion M provides that the Insurer shall not be liable for any claim against the insured based upon or attributable to or arising from the actual or purported fraudulent use by any person or entity of any data or in any credit, debit, charge, access, convenience, customer identification or other card, including, but not limited to the card number.”
…
Fidelity contends Exclusion M applies and therefore Fidelity is not liable for First Bank’s losses. Fidelity argues that the Visa and MasterCard assessments are excluded from coverage because the assessments arise from the fraudulent use of data by the hackers.
…
Fidelity argues that there is a meaningful link between the hackers’ fraudulent use of the breached data and the Visa and MasterCard assessments. DAS’s computer system was breached, and the data obtained as fraudulently used to make unauthorized withdrawals. Visa and MasterCard incurred costs associated with this fraudulent use of credit cardholder data. First Bank assumed liability for these costs in its agreements with Visa and MasterCard. Fidelity concludes that the Visa and MasterCard assessments arise from the fraudulent use of data as contemplated by Exclusion M. Therefore, Fidelity is not liable for these losses.
…
While Fidelity argues that the assessments arose from the fraudulent use of data, First Bank argues that the assessments are based on First Bank’s failure to ensure that DAS was PCI DSS compliant. The Court finds that First Bank’s failure to ensure PCI DSS compliance may qualify as a parallel basis for the assessments. 

Fidelity has met its initial burden of demonstrating that Exclusion M applies. Therefore, the burden shifts back to First Bank to prove that an exception to the exclusion applies. First Bank contends that Exclusion M does not apply because: (1) Exclusion M is unintelligible and ambiguous; and (2) application would render coverage illusory.
…
The Court finds that Exclusion M is somewhat unclear grammatically. Nevertheless, it is clear that the first half of the clause — “based upon or attributable to or arising from the actual or purported fraudulent use by any person or entity of any data” — is intended to exclude the “fraudulent use” of data, however fraud occurs.
…
First Bank [also] contends that the application of Exclusion M renders the coverage grant illusory. First Bank argues that coverage for unauthorized use and unauthorized access to data in the definition of “Loss Event” includes claims resulting from the fraudulent use of data. First Bank notes the difficulty of finding an example of unauthorized use or access that does not contain some element of fraud. . . . 

Fidelity asserted at oral argument that “fraudulent,” as used in Exclusion M, is distinct from “unauthorized” in the definition of a Loss Event. Fidelity’s distinction is that “unauthorized” is broader and covers unintentional and mistaken use or access. Fidelity contends that the two provisions can be reconciled to provide coverage for losses resulting from the non-fraudulent unauthorized use of data. . . .

The Court finds that the language in Exclusion M is unambiguous in its attempt to exclude coverage for the fraudulent use of data. The Court finds that Fidelity has met its burden to prove the elements of the exclusion by showing a meaningful link between the fraudulent use of data and the claims at issue. However, when the burden shifts back to First Bank to prove that Exclusion M should not be applied, the Court considers that a grant of coverage should not be swallowed by an exclusion. The principle that a grant of coverage should not be rendered illusory protects the reasonable expectations of the purchaser. 

The Court finds that applying Exclusion M would swallow the coverage granted under Section 4.III(L)(1) for “any unauthorized use of, or unauthorized access to electronic data . . . with a computer system.” It is theoretically possible that an example of non-fraudulent unauthorized use of data exists. However, in the context of this Policy, all unauthorized use could be, to some extent, fraudulent. The abstract possibility of some coverage surviving the fraud exclusion is not sufficient to persuade the Court to apply an exclusion that is almost entirely irreconcilable with the Loss Event coverage.

 

Read More

GoDaddy gets torpedoed - Anonymous claims responsibility

GoDaddy's website and sites that it hosts have gone down as the result of an alleged attack by Anonymous. It's a pretty significant Denial of Service (DOS) attack and this incident is surely going to result in an FBI investigation - remember what happened after the Paypal DOS - Feds Arrest 14 ‘Anonymous’ Suspects Over PayPal Attack, Raid Dozens More. Hopefully, if they do find, arrest, and prosecute the offenders, they will do a better job of handling the evidence than they did in the Paypal case - see my post about that here: In Paypal DDOS case, government reprimanded for failure to analyze and return data in a timely fashion.

Anonymous claimed responsibility via Twitter.

GoDaddy has confirmed, via twitter that it is experiencing issues - see their twitter account here: GoDaddy

A CBS news story regarding the incident can be read, here: GoDaddy goes down, Anonymous claims responsibility.

(As I post this, I see that Cybercrime Review is down - not sure if this is a part of the GoDaddy lulz.)

Update 1: As I mentioned on Twitter @Cybercrimerev, it appears the attack was not Anonymous collectively, but AnonymousOwn3r individually. This tweet here (NSFW), shows some dissension in the Anonymous ranks - an unsurprising development since the group has never congealed into a fully aligned faction.  In my opinion, that is the greatest strength of Anonymous - anyone can pick up the torch.

Read More

An attempt to make the case for "hacking back"

Justin's recent post, "The illegality of striking back against hackers," presents a number of interesting issues with regard to organizations hacking in retaliation against those who hack them first. It is only fair that such an act should be allowed in light of the current state of our legal system. But as Justin correctly states, allowing retaliation is not a clear-cut issue and should not be considered lightly.

Hacking cases are complex. Beyond the cases where hackers go to the Internet to boast about their actions, it can be very difficult for law enforcement and prosecutors to track down the perpetrators. Facing a lack of resources, cybercrime investigators tend to focus their attention on issues such as child pornography. Hacking cases and the identity (or other) thefts that follow present great hurdles for millions of Americans each year.

Of course, there is a remedy for consumers - file a lawsuit. After LinkedIn's recent security breach, many quickly jumped at the chance to file. LinkedIn committed a grave error, and attention needed to be brought to the issue so they'll fix the problem and other companies will be warned as well. No amount of investment in security, however, will make a system perfect and neither will it make a company immune from lawsuits and damage to their reputation when breaches occur.

Likewise, there is also a solution for the hacking victim - file a lawsuit. The CFAA allows a civil suit to be brought for certain damages, but it carries with it a multitude of problems. Often, the hacker could only be found by an investigation that would, in turn, violate the CFAA (see Justin's point number 2). They may be located in another country. They may not have any money, and even if they do, there may be no legal process for getting to it. For these reasons (and many others), companies like LinkedIn are often required to take the beating from the press and users, spend a lot of money beefing up security, and keep their fingers crossed.

Until law enforcement and prosecutors make these cases more of a priority, American organizations (and therefore, consumers) will be left without a true means of protecting themselves. But suppose we modified the CFAA to allow a self defense-type approach. In some ways, being hacked is like being punched in the face. If you retaliate in either situation, it's possible that others will come in defense of the attacker (imagine a bar fight where all of your friends are already outside, and you're now facing five guys twice your size). Similarly, if you were in a crowd and weren't sure who the punch came from, you can't just start hitting everyone to get back at the true puncher. However, if you can find them and timely respond, you may be able to defend yourself from further harm.

There are a few ways in which such a modification would be helpful:

1. Investigation - Allowing victims to hack back would allow them to collect the information that would be essential to any civil or criminal case - information like the IP address of the hacker.
2. Security Improvement - Patching security issues is much easier if you know how the infiltration happened. Further, knowing what resources hackers are using would allow technology security teams to better plug the holes in their networks. Perhaps the statute could require mandatory reporting so that the government could collect data in an effort to study developing patterns in the hacking world.
3. "Cathartic Chest Pounding" (Justin's words) - Billion dollar corporations have at least one thing that common hackers don't - a billion dollars. Not every business has the ability to dedicate essentially unlimited resources to protecting themselves, but these do. Hacking back may result in more attacks at first, but the right successes might turn hackers away. (The problem here, of course, is that if large companies make themselves essentially hack-proof, the market for unauthorized data will result in attacks on small business that have no such resources.)

Obviously, there's no easy solution to this problem, but rest assured - the CFAA is not likely to hinder everyone. Now we have the waiting game to see how prosecutors, Congress, and corporations will respond.

Read More

LinkedIn's negligence in failing to adequately secure user passwords

As most of you are aware, LinkedIn's site has apparently been hacked, and 6.5 million passwords of users were exposed (if you weren't aware, change your password); the likely attacker operated out of Russia. Take all I say with a grain of salt, as LinkedIn has recently tweeted "[o]ur team continues to investigate, but at this time, we're still unable to confirm that any security breach has occurred. Stay tuned here." But, I doubt that this is a false alarm, and for the uninitiated, let me translate that tweet in honest technology speak - "We've realized a breach occurred, we are panicking in a board room and attempting to spin this in the least damaging light possible."

In this day and age it is unsurprising that a large site has been owned by hackers; I think most would agree that this has become commonplace. But, it appears that corporations are failing to evolve based on the failures of their compromised brethren. While LinkedIn should be applauded (quietly) for their use of SHA-1 hashes to store passwords, they should then immediately be criticized for failing to also salt the passwords, or use a more cryptographically strong algorithm such as SHA-256, or SHA-512.

A quick explanation will make their negligence clear. Let us assume that the chance of disclosure of passwords is merely a function of exposure to the internet, multiplied by the traffic of (aka attacks on) the company, divided by the security measures in place to prevent data disclosure. The equation can be noted as EXP * TR / SEC = DISC(%). That equation is of course not scientific, but it helps to explain the current atmosphere of the internet. The variables EXP and TR are hard to control by any company that is out on the internet, and in fact, most companies interested in making a profit want those values to increase. The key to business viability, trust of the consumer (industry respect), and meeting the responsibility placed on you as a data steward is the company's SEC value. I would also argue that the more vital the service you are offering on the internet is, the more responsibility and obligation you have to increase your SEC value.

By using unsalted SHA-1 hashes, LinkedIn essentially conceded that the value of DISC would be enormous, and it did so by negligently failing to salt those passwords. I say negligently because it is commonly understood in the industry that use of a salt makes cracking password significantly harder. Take for example the NIST Enterprise Password Management Guide, which states:

The use of salts also makes cracking more difficult—for example, using 48-bit salting values effectively appends a 48-bit password hash to the original password hash, assuming that the attacker does not have access to the salting values and that the salting values are well-chosen. So a salted password might have the same effective length, and therefore be roughly as time-consuming to crack, as an unsalted password  that is several characters longer. Also, salts typically use the full range of possible values, unlike passwords that have limited character sets, so salts can strengthen the effective password complexity. Policies for password expiration, length, and complexity should take into account the use of salts.

The use of salts defeats, or at least slows down the use of "rainbow tables," which are tables of already calculated hashes of passwords. So, if I know that your site uses SHA-1 hashing, I take a wordlist of X number of words, and hash all of those into a database. Then, when a Russian hacker discloses all of your passwords, I merely correlate the values disclosed with the values in my table to discover passwords. I may not get all of the passwords, because the dictionary file originally used normally does not have every word or possible combination of letters, numbers, and symbols used by individuals, but I am guaranteed to get a large portion because users typically have bad passwords (or shall I say weak/predictable passwords).

The use of salting defeats rainbow tables because the hope is that the potential "cracker" of the passwords is clueless on the salt used to hash the passwords by the particular site, so a traditional rainbow table is useless. Thus the hacker would need to create a rainbow table for every possible iteration of the salt - an extremely time consuming task, and wholly not worth it. In all of these password cracking scenarios, there is a race condition going on. Specifically, that the number of entrants to the race decreases exponentially as the complexity and difficulty of the passwords that could be cracked increases (the value of SEC increases). As an internet company you need not outrun the bear behind you that is attempting to expose your security weaknesses, you merely need to be running faster than the others around you.

It is no argument for LinkedIn to assert that they could not have feasibly implemented a salt on their SHA-1 hashes, nor is it an argument for them to assert that others are using SHA-1 hashes. It is widely known that SHA-1 has been significantly weakened, and SHA-2 (256, 512) algorithms are better alternatives - the federal government urged federal agencies to stop using SHA-1 in March, 2006, and a competition has been running since 2007 to come up with SHA-3.

We must assume that password hashes are going to be disclosed because of the plethora of weaknesses in software currently implemented worldwide. What we shouldn't assume is that the stewards of our data are failing to exercise due diligence in protecting our information. The driver of an increase in the value of SEC is the real world accountability for preventable security failures.

Update: As expected, LinkedIn has confirmed the breach.

Read More