It’s not as fun to read as Dr. Seuss, but in October 2005, the FDIC declared single-factor authentication inadequate for online banking authentication:

• Single-factor authentication methodologies may not provide sufficient protection for Internet-based financial services.
• The FFIEC agencies consider single-factor authentication, when used as the only control mechanism, to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties.
• Risk assessments should provide the basis for determining an effective authentication strategy according to the risks associated with the various products and services available to on-line customers.

IanG at Financial Cryptography recently noted and added valuable commentary to a WashingtonPost.com blog entry about how phishers have already adapted to this countermeasure WaPo sets it up:

The site asks for your user name and password, as well as the token-generated key. If you visit the site and enter bogus information to test whether the site is legit — a tactic used by some security-savvy people — you might be fooled. That’s because this site acts as the “man in the middle” — it submits data provided by the user to the actual Citibusiness login site. If that data generates an error, so does the phishing site, thus making it look more real.

But IanG adds the value:

More bad news for suppliers of 2-factor tokens and also US Banks which got a quasi-recommendation to implement something like this. I say, quasi-something, because the FDIC carefully did not recommend any specific technology, choosing instead to recommend that banks carefully review their _risk-based exposure_. The banks themselves may have assumed tokens or similar, for whatever reason.

(emphasis mine)

Of course, you would never know that the official guidance specified only that the bar had been raised (no more single-factor), not what it had been raised to (Buy two-factor authentication products!) unless you went and read the guidance document itself–not a difficult task since it’s only one page long and it’s the first result if you google for “fdic authentication”. (The Account Hijacking page is the second link, btw)

Also interesting, though, is that the FDIC did recommend two-factor authentication–in December 2004! If you look at “Putting an End to Account-Hijacking Identity Theft, an allegedly consumer-targeted page (but which talks a lot about things like log analysis and infrastructural analysis opportunities), they say:

Financial institutions and government should consider a number of steps to reduce online fraud, including:

1. Upgrading existing password-based single-factor customer authentication systems to two-factor authentication.

Of course, that report also speaks well of SenderID, so we would all be well-served to remember what become of that Silver Bullet.

Personally, I agree with IanG. It’s not the FDIC’s place to provide prescriptive guidance in this situation. It’s one thing to provide a common problem statement, “Single-factor authentication is not adequate.” Unfortunately, the people least likely to understand that there are many ways to provide a second authentication factor besides hard tokens are also the ones most likely to fall for the vendor pitch that some sort of hard token is the only second factor.

I will never know why the FDIC decided to pull back from “upgrade…to two-factor” to, “Risk assessments should provide the basis for determining an effective authentication strategy,” but I strongly believe it’s the appropriate approach to the problem. Banks do a lot of things, some visible and some not-so-visible, to reduce the risk of a successful breach (successful probably being defined as funds successfully transferred beyond recovery or large-scale enough to make the press). Since no two banks have the same set of risks and countermeasures (remembering that risk is the combination of asset value, threat & probability along with varying opinions of what is or is not an externality), no two banks should come to the same exact solution set, even if their risk position seems identical to an outsider.

Maybe someone pointed out that they guidance would remain and still be adhered to by the less-informed long after it had been overtaken by events. To reinforce that argument, on October 12th, 2005 (the same day that FIL-103-2005 was published), the Register had a story about phishers successfully compromsing a one-time/scratchpad system in Sweden. Perhaps a coincidence, but it would have been a bit ironic if the FFIEC had issued prescriptive guidance at the same time as that guidance (in the absence of other compensating controls) was shown to be inadequate.

John Quarterman at Perilocity has now picked up on this, as well.

Updated: Fixed the missing link, added a title and intro tie-in

All the encryption in the world won’t protect your data if the recipient decrypts it to store it.

AUSTIN, Texas - Equipment containing the names and Social Security numbers of about 1.3 million Texas Guaranteed Student Loan Corp. borrowers has disappeared, company officials said.
…
“It was not a security breach where someone hacked into our system,” said Sue McMillin, Texas Guaranteed’s president and chief executive.

The piece of equipment, which the company did not identify, was lost May 24. Officials said encrypted electronic files containing the data were sent to Hummingbird Ltd., which helps companies manage large amounts of information. A Hummingbird employee downloaded, decrypted and stored the files on a piece of equipment that was later lost.

We don’t know whether the mysterious “piece of equipment” was a tape, CD, USB stick, floppy disk, laptop, desktop, or stone tablet. Not that it matters.

This is an updated version of propping open the data center door. If a control is deemed too inconvenient, users will find ways to bypass it, usually rendering it ineffective in the process.

The failure here was not the technology, but rather the people and processes at Hummingbird and the contract governance by TGSL which didn’t ensure that the data was only decrypted while in use.

While the source is PGP, a vendor with a vested interest in people seeing privacy breaches, there is still some interesting research in this article on the Per-Incident costs of privacy breaches over at Network World while catching up on my reading. (Thanks to nCircle’s blog for the link)

The first report is a survey of 14 organizations that lost confidential customer information and had a regulatory requirement to notify the affected individuals. The 14 organizations primarily hailed from the financial services arena but also included retailers, insurance companies, telecom firms, higher education and healthcare.

To cope and recover from a single security breach cost on average $14 million per company per breach or $140 per lost customer record. The direct costs in incremental spending for outside legal counsel, increased call-center costs and related items alone were $5 million.

I bit the bullet and registered to download the actual studies. Here’s what that $14 million includes:

Breaches included in the survey ranged from 1,500 records to 900,000 records from 11 different industry sectors. In general, the largest breaches occurred in financial services, data integration, and retail; the smallest were in higher education and health care. Information in this study covers the costs of almost 1.4 million customer records compromised.

Among the study’s key findings:
• Total costs to recover from a data breach averaged $14 million per company or $140 per lost customer record
• Direct costs for incremental, out-of-pocket, unbudgeted spending averaged $5 million per company or $50 per lost customer record for outside legal counsel, mail notification letters, calls to individual customers, increased call center costs, and discounted product offers
• Indirect costs for lost employee productivity averaged $1.5 million per company or $15 per customer record
• Opportunity costs covering loss of existing customers and increased difficulty in recruiting new customers averaged $7.5 million per company or $75 per lost customer record. Overall customer loss averaged 2.6% of all customers and ranged as high as 11%.

These cost estimates include recovery costs only and do not include the cost of putting in place technology and procedures to ensure such breaches do not occur in the future.

Personally, I’d stop short of trying to claim any more than that $50/record of direct costs if I was using this to justify encrypting, destroying, or otherwise protecting data. Besides, unless you’re talking about more PII than the average personal address book, $50/record should produce a large enough number to get people’s attention and provides an easy-to-work-with number for ROM calculations.

One other interesting thing I noticed about this study. All three case studies were disclosure of credit card numbers, but none of them seemed to include the cost of re-issuing cards. That would mean that there was an unaccounted for externality here since there is a significant direct cost to the credit card issuer.

For some reason, $27/card pops into my head but I’m too lazy to check it right now. Even if that were the total cost of handling an incident, a range of $25-$50/record is still a pretty good figure to work with.

Privacy has taken on new importance here of late. I mean “here” both in terms of at work and in my personal life. Yesterday, I got a letter from my bank to let me know that my credit card was one of the 41 million card details stolen from Cardsystems, Inc.

Around the office, recent events have also created increased interest in identifying and securing Personally Identifying Information (PII) has come back into the spotlight, too, which is good for obvious reasons, but also bad because it really makes you realize how much work it is to securely keep and handle PII.

So here’s how we’re going about it. This is far from a comprehensive discussion of how to go about performing each step, but for anyone who’s suddenly finding themselves being asked what they’re doing to make sure that a privacy breach doesn’t happen on their watch, this might help organize their thinking.

I’m going to ignore the issue of how broad this effort should be. Basically, assume that whomever gives the mandate can only ensure compliance from people in their management chain. If it’s a department head, then just focus on the department. If it’s supposed to be for the whole company, then it probably needs to come with a public declaration directly from the CEO or her designate on the matter.

So whatever the scope, here’s how I’m going about it where I work. I’m breaking this up into four parts. Today is Part 1. Right now, I expect the full series will comprise:

1. Define the PII Perimeter
2. Tighten The PII Perimeter
3. Encrypt PII at-rest
4. Encrypt PII in-transit

So without further ado…

1) Define the PII Perimeter
Things that aren’t known about can’t be protected. When we start looking for PII, we’re often horrified by how much of it there is and how indiscriminately it’s transferred and stored.

The other reason to define the perimeter is that if we need to conduct this exercise at all, our normal level of data protection is probably not adequate for protecting PII. This means tighter controls, which means increased costs, both directly for security technology like PGP or full-disk encryption software.

Don’t be scared off at this point. Too many people still equate Ignoring Risk with Avoiding Risk. In reality, Ignoring Risk equates to Accepting Risk, only without checking if it’s a good idea first.

So where to begin? If there’s an inventoryof applications, this can provide a good starting point for tracking down official PII stores. To really track down all the high-risk PII stores, however, we have to leave IT and go talk to the Functional side. That’s where the people who use the PII live. They’re also the ones who are performing the activities that create unofficial PII stores.

Think the company email server isn’t a PII store? Think again. People email the stuff around all time, and when they do, it winds up in server-side message stores and on backup tapes.

Think that laptops and workstations aren’t storing PII? People save those emails in client-side archive files, unzip excel sheets of employee salary data into temp directories to read the attachment, or save a local copy “so it doesn’t get lost.”

Next, we’ve got to figure out where this stuff is used and where it’s shared. That means it’s time to find the data feeds. Track down processes which involve PII. If it’s in a database, it had to get there from somewhere. Find the flatfile, replication process, EAI link, or whatever other mechanism populates that data. Now go to that system and repeat the process.

We repeat this process until we encounter a link that extends beyond our Mandate. This might be another department internally, it might be a third party to whom we outsource some business function involving PII. Either way, we’ll mark this an an External Interface, define exactly what PII we’re exchanging with this party, and go on.

Eventually, we’ll find all the official and unofficial PII data stores that are within our mandate. It’s probably going to be a list of servers, workstations, laptops, tape libraries, storerooms, floppy disks, USB Thumbdrives, CD-ROM’s, and who knows what else.

Additionally, a second list should identify the organizations and processes which handle PII: Payroll (everything), Human Resources (everything again), Accounts Payable (T&E Payment distribution), Internal Audit (Payroll work papers, HR, work papers), etc.

Finally, there will be that list of External Interfaces: Payroll data to to ADP. SSN’s and more to Fidelity for 401k. Customer warranty data to marketing (assuming that the Privacy Policy allows it).

Tired yet? Well the fun is just beginning.

In part 2, I’ll discuss Tightening The PII Perimeter. We’ll explore some strategies for avoiding the risk of an incident and reducing the work (and cost) associated with protecting PII by minimizing the amount that’s kept around. But that’s another post for another day.

Over at The Economist, there is an article, “The Leaky Corporation,” which suggests that Information Protection could be becoming a much bigger deal within most companies than it is today, driven largely by the increased attention that data security breaches are receiving from both the press and regulators.

“Data is becoming an asset which needs to be guarded as much as any other asset,” says Haim Mendelson of Stanford University’s business school. “The ability to guard customer data is the key to market value, which the board is responsible for on behalf of shareholders”. Indeed, just as there is the concept of Generally Accepted Accounting Principles (GAAP), perhaps it is time for GASP, Generally Accepted Security Practices, suggests Eli Noam of New York’s Columbia Business School. “Setting the proper investment level for security, redundancy, and recovery is a management issue, not a techie one,” he says.

Specifically, they point to the FTC’s settlement with BJ’s Wholesale Club as an example of the changing expectation for data protection within the United States

The FTC decided to settle with BJ’s Wholesale Club, a retailer whose lax data-protection practices the agency said constituted an “unfair practice that violated federal law.” The firm collected too much data, kept it too long, did not encrypt it, lacked password protections and left its wireless network open. This, in turn, enabled criminals to produce counterfeit credit and debit cards using stolen customer data and rack up millions of dollars in fraudulent charges. The firm has agreed to fix these problems and undergo information-security audits for 20 years.

Data Protection is getting increased focus among several corporate security management types I know. We’re all busily erecting or resurrecting Data Protection and Privacy efforts. Risks that were once deemed acceptable without any actual Risk Analysis are now being called into question.

This is a Good Thing. If it’s on the minds of The Economist’s readers, that means that Management is waking up to the importance of paying attention to this stuff. While as a general rule I never wish misfortune on anyone, I’m not unwilling to leverage their misfortune for the common good.

Since Adam Shostack is suffering from Stupid Privacy Invasion Fatigue, I’ll take this one for him.

According to The Register quoting The Sun (deemed nsfw by many places, including my employer),

The paper says one of its journalists bought details of 1,000 UK banking customers from an IT worker in Delhi for £4.25 each. He was also able to buy the numbers of credit cards and account passwords. An unnamed security expert hired by the paper verified that the details were genuine. The information sold could be readily exploited by ID thieves to apply for credit cards or loans under assumed identities or to simply loot compromised accounts. The call centre worker bragged that he could sell up to 200,000 account details each month.

Well duh…take a well-educated, widely-underemployed, highly-entrepreneurial culture and give them ready access to information which is easily converted into cash and what’d you think would happen? I know that this may have been just a bad apple. I’ve seen the same things (and worse. Much worse, actually) occur in US Call Centers, where it’s a bunch of under-educated, lazy, corrupt idiots doing the work, they just want more money per-account.

I also know that companies aren’t willing to do anything “dramatic” about it, like prosecute the offenders, since that might entail accepting the risk of some negative press coverage. It’s only when it’s already hitting the fan in the press that they’re interested in getting The Cops involved.

This is just another example of corporations transferring risk onto their customers to save a buck (or Pound Sterling, as the case may be). The fact that they’ll then further sell out those customers when an incident occurs to prevent Brand Damage just makes it that much more offensive.

The NY Times published an editorial today, “The Data Fleecing of America,” which praises members of the US Congress who are trying to do something about Identity Theft Fraud by Impersonation.

If it were not for California’s pioneering law requiring notice to affected consumers, the rest of the nation might not have even heard warnings of how their assets and identities are increasingly at risk. Senator Dianne Feinstein, Democrat of California, is proposing a national requirement for consumer notification, with civil damages for negligent companies. Her bill is a good start in conjunction with a comprehensive measure by Senators Charles Schumer of New York and Bill Nelson of Florida to begin regulating data merchants by requiring registration with the Federal Trade Commission. It would adopt stronger safeguards, stop the easy access to Social Security numbers and help identity theft victims regain their fiscal balance.

Credit-card companies and information brokers - not consumers and merchants - bear prime responsibility for the ravages of data thieves.

(emphasis mine)

There’s some inkling of clue in that final sentence, but it’s too little too late to save this editorial.

How many times do we have to say it? The SSN cat is out of the bag. It can’t be put back, no matter how much people would like it to be. Fixing the problem is going to be hard and it’s going to be expensive. If I had to guess where in the Seven Stages of Grief people are at the loss of their beloved SSN as an all-in-one identifier and password, I’d definitely go with “Denial.”

So let me say it one more time: The number of compromised credit card numbers, Social Security Numbers, Bank Account Numbers, and other bits of PII is simply too great. When real life reads like something out of The Onion, it’s time to admit that Humpty Dumpty probably isn’t going to come out of this in one piece and start tackling the Root Cause of the problem–inadequate authentication methods for financial transactions.

Personally, I like Bruce Schneier’s suggestion that the US Government should announce that they are going to publish the SSN of every American in, say, two years. This would force the updating of financial transactional systems and as an added bonus, create a huge demand for all those poor FORTRAN and COBOL programmers who’ve been looking for work since Y2K.

I started reading this article/Akonix Media Relations placement about Instant Messaging because IM security is on my mind a lot lately. What I found most interesting about it was its focus on Legal Risk:

Lack of an IM policy can also produce problems during a legal-discovery process. For example, what if an executive logs IM conversations locally, yet the company at large doesn’t? After subpoenaing records, would lawyers have only part of the picture?

Thus, a business can put itself at risk by not having an authoritative record of IM communications. Call this IM’s “basic legal compliance” threat, says Francis Costello, chief marketing officer at Akonix in San Diego. He’s not referring to compliance in the Sarbanes-Oxley sense. Rather, it’s the “risk of discovery, human resources issues, and the risk of disputes.

When I look at risks, I’m generally looking at threats which might impact Confidentiality, Integrity, and Availability*. Legal Risk is something I farm out to the lawyers, and they’re notorious for not getting back to me since that would mean going “on record” about something, which apparently flies square in the face of Legal Risk management.

So what should the lawyer’s response be (at least according to this article)? IM Monitoring. Log it all, let the discovery process sort it out. No mention of the Second-Order Risks that implementing comprehensive logging and monitoring creates, such as Privacy issues or Personnel Risks created by the lowered morale that generally accompanies the feeling that Big Brother is watching.

Thus, this is a nice bit of strawman work. They’ve found a legitimate legal risk (incomplete response to a discovery request), rolled it in with a longstanding, real network security threat and suggested that there is only one solution to it, and that’s to log everything. The funny thing about this is that it seems to fly in the face of the overall trend toward retention policies in general, which is to retain as little as possible except where required by law to do otherwise.

But that wouldn’t help you sell an IM Monitoring and Security solution, would it?

* Actually, I usually look at risks in order of I-C-A, but that’s because I’m usually asked to comment from a SOX perspective and because everyone else is always obsessed with Confidentiality to the exclusion of all other risks. They always seem to forget that perfect Confidentiality means no Availability. An amateur-hour mistake, sure, but no less common for being so.

Wired has an article describing a researcher’s efforts to implement fingerprint-locked DRM for DVD’s.

This may be one of the dumber ideas I’ve heard yet. Why? Two words: movie rentals.

The studios make tons of money off of their agreements with Blockbuster, netflix, etc. They would have to provide unlocked DVD’s to those entities. And since most of the people I know who rip lots of DVD’s use Netflix to supply them with the movies they copy (for personal use or piracy is irrelevant here), this makes no sense whatsoever.

At best, it’s a solution in search of a problem. Encryption doesn’t stop piracy–pirates either make bitwise copies of the movies or run a “second shift” in the same factories and using the same masters as the legitimate copies. Cracking CSS was about providing a software player for Linux. The pirates never cared.

In reality, this is the sort of DRM that becomes so restrictive as to pretty much ensure that even the most law-abiding citizen is going to become a pirate out of sheer necessity.

Going back to the old adage that security is the tradeoff of effectiveness versus convenience, with the correct point on that continuum being the one where the risk of people creating bypass mechanisms is greater than the risk from the threat the countermeasure is intending to mitigate.

This solution skews so far in the wrong direction that it’s surprising that it’s even being taken seriously. I mean, consider the holes in this approach that come to mind as fast as I can type: How many fingerprints would be “too many?” If I buy the DVD, would that mean my wife couldn’t authenticate to the DVD player? What about my daughter? How would COPA affect gathering her biometric information? How about the babysitter? What about existing laws regarding fair use?

The list goes on and on. My point is made. When it comes to DRM, I think Forest Gump said it best, “Stupid is as stupid does.”

(Thanks to blog-on-nymity for slipping this into my world via the miracle of rss)

On the Internet I have an identity as the author of this Blog. I also have an identity as an online gamer (and a damn good one, if I may say so). And as a Security Manager for a major corporation. I also have identities as my Parents’ child and my wife’s husband out in meatspace. The list goes on and on.

While some of these identities overlap, I prefer that some of them stay separate. My mom doesn’t need to know everything about me that my wife does. While I’m careful what I say here, it’s probably also best if my employer doesn’t know about my Blog.

How carefully I maintain the separation of those identities should be up to me. I don’t have any Deep Dark Secrets that I’m aware of, but if I did, you damn well better believe that I’d want to keep them separate from my various public personae. Just ask the Mayor of Spokane about that one.

Sometimes, the government decides that certain identities cannot be kept separate, such as criminal history and firearm ownership. In other cases like the Fair Credit Report Act, the government mandates that personal identity must be kept separate from financial identity for non-discrimination purposes.

So how hard is it to keep those identities separate? Probably damn near impossible, according to this New York Times article:

Senator Ted Stevens wanted to know just how much the Internet had turned private lives into open books. So the senator, a Republican from Alaska and the chairman of the Senate Commerce Committee, instructed his staff to steal his identity.

“I regret to say they were successful,” the senator reported at a hearing he held last week on data theft.

His staff, Mr. Stevens reported, had come back not just with digital breadcrumbs on the senator, but also with insights on his daughter’s rental property and some of the comings and goings of his son, a student in California. “For $65 they were told they could get my Social Security number,” he said.

That would not surprise 41 graduate students in a computer security course at Johns Hopkins University. With less money than that, they became mini-data-brokers themselves over the last semester.

Working with a strict requirement to use only legal, public sources of information, groups of three to four students set out to vacuum up not just tidbits on citizens of Baltimore, but whole databases: death records, property tax information, campaign donations, occupational license registries. They then cleaned and linked the databases they had collected, making it possible to enter a single name and generate multiple layers of information on individuals. Each group could spend no more than $50.

Several groups managed to gather well over a million records, with hundreds of thousands of individuals represented in each database.

“Imagine what they could do if they had money and unlimited time,” Dr. Rubin said.

Read the article for more information on how easy this was for them to accomplish. And remember, these guys were unfunded amateurs.