It’s The Database, Stupid

Yesterday’s announcement that the Clear service could soon be baaaaack, along with a spate of recent client questions on electronic credentials and biometrics, have triggered this post.

My colleague Andrew Jaquith’s analysis of the myriad problems with the way that Verified Identity Pass and the TSA handled the Clear shutdown in June (including the potential for customers’ PII to be sold off) was spot on.

So with the prospect of the return of a registered traveler program in the US, the ongoing debate over REAL ID, and the slow but steady advances in the use of various biometric technologies for identity authentication, it’s worth taking a step back and separating the wise from the foolish, and hopefully knock down a few pervasive myths while we’re at it.

What separates a “good” implementation that protects privacy and civil liberties from a “bad” one? The upshot: The devil’s in the details – and, quite often, in the database.

Worry #1: What if my biometric's stolen? I can't replace my fingers, after all.

This is indeed a valid concern if: (1) the full fingerprint (face, iris, etc.) scan is stored; (2) it’s stored in the clear; and (3) subsequent scans to authenticate a person compare the full fresh scan with the stored full scan. In the case of the FBI and other law enforcement agencies, at least (1) and (3) are likely to be true. And if these databases proliferate and are used by other agencies, then maybe the anti-gummint folks are on to something.

But this is simply not the case for the vast majority of biometric implementations. For example, when you enroll a fingerprint, the software chooses a few dozen discrete points (called “minutiae”) from that scan and applies a hash function to it, essentially boiling down the fingerprint data to a single number. Authenticating involves taking a fresh fingerprint scan, choosing the same minutiae from it, and then hashing it. If the two hash values match, the user is authenticated. There’s no way to reverse-engineer the full fingerprint from either the raw or hashed minutiae.

Worry #2: There's no way they can properly secre all of that network traffic phoning home to check my (biometric) ID credentials or sync the local and central databases.

This is likely to be true in some cases – and that’s why it’s important to understand the distinction between one-to-one (1:1) and one-to-many (1:N) matching.

1:1 matching asks the question, “Is this person in front of me the same person as on this credential?”, whereas 1:N matching asks the question, “Who is this person? Look at everyone’s data and find who matches the credential.” Ideally, 1:1 matching would be used for the everyday task of authenticating people, and 1:N would be reserved for instances where there is a pressing need to identify someone.

1:1 matching is far more secure and does a better job of protecting privacy (and it’s faster and more efficient, too!). The point of authentication doesn’t retrieve your data from a remote central database (risking network-based attacks) or check it against a local copy of such a database (risking this kind of potential data leak situation).

Amsterdam’s Schiphol Airport has a registered traveler program called Privium that uses 1:1 matching. Travelers’ iris scan data is stored on a secure smart card chip. When travelers need to pass through security or passport control, they stick the card in the reader, scan their iris, and if the live scan matches the one stored on the card, they’re good to go. No database to compromise at the point of authentication.

Worry #3: The electronic ID card I would have to carry is the biggest threat to my liberty and privacy.

This scenario has been playing out in the UK for several years now. Unlike in other European countries with electronic IDs, the British are not happy with the “liberty-killing” prospect of having to carry and show identification. The Government has obliged by keeping the terms of the debate focused on the cards themselves, while in the background quietly assembling and cross-linking extensive databases of intrusive and critical personal information, such as DNA records.

The proliferation of poorly secured databases containing large volumes of critical personal information is a far bigger threat to privacy and civil liberties (leaving aside the question of ubiquitous CCTV cameras for another day) than the requirement to produce ID on demand – particularly when the database holder has a rather checkered history of data security.

That’s why I say, “It’s the database, stupid.” Right, that’s enough for now – tune in next time to find out why airport security really works.

Don’t worry — I backed up my phone to the cloud!

I just nuked my phone.

Ok, so maybe I didn’t nuke it, but I wiped it clean. It’s all part of an experiment. I’m one of a lucky few (20 to be precise) that are piloting iPhones here at Forrester. So far, it’s been great, although there are the usual bumps and stumbles you might imagine with any new technology. For example, has anyone else out there come across the mysterious disappearing calendar item? Every once in a while I come across something that’s on my desktop Outlook client, but not on my iPhone. I’ve done some pretty exhaustive scenario testing and I think I’ve isolated what triggers it, but of course there’s no discussion of it anywhere in the Googlesphere. Very strange, but I digress. As much as I’d like to talk about my iPhone experience, I’m actually more interested in any consumer mobile device in the enterprise.

(Psst. Apple, if you’re listening I can be contacted on this blog, on Twitter, or via email. I may not be one of our device analysts, but my analyst credentials would be revoked if I didn’t at least have an opinion.)

Ok, so why am I interested in mobile devices? Because in the last few weeks we’ve been swamped with clients’ requests to help craft their security policy for this technology populistphenomenon. Not only has iPhone proven to have enterprise staying power, but the promise of Palm Pre and Windows Mobile 6.5 has many an executive dreaming of replacing their old scroll-wheel driven BlackBerry with a slick touch interface.

Now I don’t profess to have all the answers. In fact, we’re working on it. At the Security Forum next week, Natalie Lambert will be moderating a panel of IT experts from Cisco, Citrix, and Google. I know, I know… You’re probably thinking “Yeah, but their vendors — that doesn’t count.” Wrong! These are the actual folks in charge of building and executing the internal strategies for these companies. Think about it. Combine the California work culture with a tech-savvy employee population and these vendors are the perfect petri dish for consumerization in the workplace. After all, they’re still large enterprises with thousands of employees going mobile. But we don’t just rely on the experts. We’ll also be conducting a roll-up-your-sleeves workshop with about 30 Security & Risk and Infrastructure & Operations executives to craft a policy that handles the data security and IT support requirements for a large enterprise. (Stay tuned for lessons learned and feel free to join the dialog on Twitter with #FSF09.)

But back to device wiping. This is where things get interesting. I was recently reading about how Microsoft will provide quite a few services for free with its Find My Phone service. Clearly a rebuttal to Apple’s paid MobileMe service. According to a recent CNET article:

In a July interview, Todd Brix said that the Find My Phone can be used to remotely send a message to a phone and cause it to ring, even if it is set to vibrate. If that still doesn't locate it, users can look up on a map where the phone last synchronized to the service. Users can also remotely lock the phone and send a message to it urging whoever has it to call a specific number. If that doesn't work, users can also remotely wipe the device.

That last part shocks and awes me. One of the longstanding issues with these consumer devices has been the inabilityto wipe them clean if lost or stolen. Now Microsoft is going one step further and allowing individual users to brick their device if they want. Umm… that’s something you’ll need to update in your security policy! I don’t think your local help desk will enjoy trigger-happy employees who wipe devices and claim “Oh, don’t worry… everything was safely backed up to the… errr… you, know… cloud.”

I’d be curious to get your thoughts, though. Should users be allowed to wipe their own devices clean, or should that be reserved for IT? Does it matter where the data is backed up — in iTunes or in the cloud?

Supporting consumer mobile devices is inevitable, but how you support them is still rich for debate. So please contact us if you’d like to weigh in our leave comments below. I look forward to hearing from you!

P.S. If I don’t respond right away is because I nuked my phone. What was I thinking?!

Lost Laptops Get the Press; Server Breaches Cause More Stress

In the next few weeks, Forrester Research will release my report, Forrester TechRadar: Database and Server Data Security, Q1 2009. In this report, we describe how the risks of theft, corruption and abuse has made securing data stored on servers and in databases much harder. To help security and risk professionals plan their next decade of investments in server data security, the report describes current and future state of 8 important technologies: centralized key management, data classifiers for security, data discovery scanners, data obscurity tools, database activity monitoring, database encryption, outbound web application filtering, and tape and backup encryption.

As part of the process of researching some of the business drivers for this report, I analyzed data from DataLossDB, a public database containing information on data loss events reported in the press and to governmental organizations as required by various disclosure laws. The data makes for fascinating study, and I urge our readers to take a look at it if they want to see what's been going on in the whole area of data breaches. Best of all, I know some of the principals involved in the project, and they are doing a terrific job.

Some of the analysis nuggets we mined from the database are fascinating. I thought I'd share one here, as excerpted from the report:

• "Bulk customer data remains the coin of the realm for thieves. Personally identifiable information that enterprises keep about customers is often used to manufacture identities and open credit lines. According to the Open Security Foundation’s DataLoss DB, 67% of 553 reported data theft incidents in 2008 targeted Name and Address or Social Security Numbers.... Data loss type 'Stolen laptop' was the most common, at 20% of incidents (112 incidents).
• "Databases remain target-rich environments. A significant proportion of sensitive information resides on web-based applications connected to databases. While lost and stolen laptops remain the most common source of lost data, according to DataLoss DB, hacks were the second-most common kind in 2008 (16%, or 88 incidents). Non-exhaustive analysis of these incidents shows that the vast majority were hacks against web applications, typically using SQL injection or other common techniques. Hacking incidents, generally against SQL servers, were extremely effective, with an average of 200,000 records disclosed per incident.
• "By contrast, lost, stolen and missing laptops and computers resulted in one-eighth as few lost records. Of 154 incidents of type LostComputer, LostLaptop, MissingLaptop, StolenComputer, StolenComputer/StolenDrive, StolenLaptop, StolenLaptop/StolenDocument, StolenLaptop/StolenMedia, and StolenLaption/StolenTape, the total records affected was 4 million. Average records per incident was 26,270, with a standard deviation of 89,665."

So the punchline is this: if you believe the numbers (and my analysis), servers tend to be 8-10x more radioactive than endpoint computers. I will likely be recommending a few methodological changes to the DataLoss DB schema to capture a few more pieces of information and make analyses such as mine more credible.

In the meantime, I'd love to hear from blog readers on the subject of data breaches. What kinds of data are "toxic" for your organization? How are you protecting them? We'd like to hear from you.

Beyond the Heartland Incident: Is It Time to Re-Visit Old Security Models?

As just about anybody reading the security trades knows, last week Heartland Payment Systems reported that it had suffered a serious security breach. As I understand it from public reports, a malicious party planted a piece of designer malware on a key server, and was then able to "sniff" credit card numbers as they passed through. Estimates vary widely about the extent of the breach. Certainly, SB 1386 and other disclosure laws will ensure that something resembling the truth will emerge sooner or later.

Clearly, this particular incident is a serious one. Various observers have used this incident to take issue with Heartland, the PCI DSS, their auditors and more generally the process for certifying QSAs. That is all well and good, but the non-stop parade of toxic data spills makes me wonder whether we, as an industry, aren't missing a few fairly obvious points.

The first point is this: attackers are changing their targets. It is clear that payment processors, in general and Heartland in particular, was a huge and tempting target for the attackers. Why bother knocking over a lone merchant when you can go after the processing network that it, and thousands of other merchants, send all their cardholder details to? In this respect, the attack on Heartland Payment Systems (a back-end payment processor) is an improvement on the "normal" techniques for filching card data: compromising a merchant's website or 0wning a consumer's PC.

In my experience, back-end providers sometimes rely on the relative obscurity of their businesses to stay off of the front pages of the newspapers. But they no longer have that luxury. Remember the 2003 Ohio/First Energy power outage? It acquainted the general public with hitherto-obscure acronyms like SCADA and NERC. In the same way, 2009 will focus a laser-beam on payment processors, and on their central role in our credit-card driven economy. That means we'll be hearing more about what Paymentech, First Data, Alliance Data Systems et al are doing to keep cardholder data secure -- or not doing.

The second point relates to economic incentives. As I mentioned, the affected party in this case is a back-end service provider (Heartland) that most ordinary people have never heard of. Consumers don't have a choice in who their merchants use to process their payments, and they can't "vote with their wallets" to use another payment processor if they want to. Merchants, on the other hand, are motivated primarily by price. So they will select select the payment processor that costs them the least as long as they are "compliant." The incentive, clearly, is for payment processors to do the absolute minimum required to pass their PCI audits, and no more. These incentives are not aligned with the concerns of the parties with the most skin in the game: the merchants and card issuers who share responsibility for losses, and secondarily consumers affected by breaches.

This brings me to the third point: it's time to dust off an old technology. It's one that operates on the simple principle that attackers can't steal sensitive data that isn't there. Seasoned industry observers, especially the Better Living Through Cryptography crowd, will remember a stillborn payment card industry initiative called Secure Electronic Transactions. SET certainly had its problems, but the objective was noble: to prevent the need for merchants to retain cardholder data at all. It did this using double-blinded cryptography that allowed both parties (cardholder and merchant) to authenticate transactions without actually needing to transmit cardholder information.

With payment processing networks now under attack, it's time to dust off SET. How about "Son of SET?." But instead of trying to keep just merchants clean, the focus should be on removing the need for all intermediate parties to transmit, hold or process cardholder data. Ideally, only two parties should need to know the card number: the end-user and the card issuer ("the bank"). Everybody else is just a target waiting to be discovered.

Can we get there? Not anytime soon. But until we figure out how to remove toxic cardholder information from the transaction flow, headlines about hacks on merchants and payment processors will keep coming fast and furious -- PCI DSS or no PCI DSS.

Privacy Policies Best Practices

Here at Forrester I get a number of questions about how companies should write their privacy policies and I wanted to share some of the top tips with you. You have probably come across some illegible privacy policies if you've ever stopped to read them. They are pages and pages long and finding the information you actually want is difficult if not impossible. So how should you write your privacy policy?

1. The main privacy policy should be very short. Ideally, the high level policy should fit on a single Web page. Check out Proctor & Gamble for a great example. It should consist of an overview of the information and lots of links to more detailed information should the customer want it. If the policy must fit on a single Web page, the top should have an outline and links to later sections.
2. The policy needs to define it's scope upfront. Which Web sites does the policy apply to? Or more importantly which ones does it not apply to?
3. The policy needs to be comprehensible to the everyday person. Far too many privacy policies have been written by corporate lawyers using terms that most regular people will not understand. Think of your mother or your brother or your child, could they read and understand it? If you need an example of what not to do, look at your bank. Most banks sites are atrocious. Using high-level principles to explain your policy often makes it easier to understand. Take a look at a rare financial example with ING Direct. Often times this requires that your privacy practices be very conservative about sharing data.
4. When explaining the customer's options, provide a link or information on how to exercise those options in the same place. If you give the consumer a choice about how their information is used, point them in the direction of how to tell you about their choice. If customers who want to opt-out can't figure out how, you've now aggravated a potential customer who might then walk away.

Following these ideas can be easier said than done. How can you tell if you've met some of the above goals? Have someone else review the policy pretending to be a potential customer, such as a parent wanting to grant permission for their child to use your site, or to deny it; a customer who wants to know what information you collect or prevent you from sharing it with your affiliates.

What do Britney, McCain, Obama, and Clinton have in common?

They have all been the subject of stories in the news lately which highlight the difference and the challenges between corporate security and privacy. All of the presidential candidates had their passport files improperly accessed by independent contracts who did not have authorization to access their information. Britney Spears' medical files were also inappropriately read during her most recent hospital stay. Heads have rolled at both organizations in response to the improprieties.

I've written research here at Forrester to show how privacy and security are related but different issues. All of these cases show how data privacy requires more than just technology, such as access control systems, but also employee training and enforcing consequences for bad behavior. Privacy and security teams need to work together to ensure that they aren't leaving a gaping hole between them where an authorized user or intruder can bypass their systems.

Surveillance Best Practices

This week the Office of the Privacy Commissioner of Canada put out guidelines for respecting the privacy of employees, customers, and potential passers-by when using video surveillance. Occasionally, our team here at Forrester is asked about physical security measures which can fall outside our area of expertise. Other times, such as the following best practices, the suggestions are a specific example of the steps one should think through for a privacy impact assessment. In fact, many times when a client has questions about best practices for privacy in business, I will recommend following the guidelines from Canada because they are leaders in the area. If you are using video surveillance, here are their universal recommendations and guidance for doing so in a privacy-respecting manner.

1. Determine whether a less privacy-invasive alternative to video surveillance would meet your needs.
2. Establish the business reason for conducting video surveillance and use video surveillance only for that reason.
3. Develop a policy on the use of video surveillance.
4. Limit the use and viewing range of cameras as much as possible.
5. Inform the public that video surveillance is taking place.
6. Store any recorded images in a secure location, with limited access, and destroy them when they are no longer required for business purposes.
7. Be ready to answer questions from the public. Individuals have the right to know who is watching them and why, what information is being captured, and what is being done with recorded images.
8. Give individuals access to information about themselves. This includes video images.
9. Educate camera operators on the obligation to protect the privacy of individuals.
10. Periodically evaluate the need for video surveillance.

New Privacy Policy Wrinkles: Online Behavioral Advertising; and Potential new EU Data Protection Policy

Last year, Google proposed a $3.1 billion acquisition of Doubleclick, which prompted consideration of the acquisition by the Federal Trade Commission and a hearing before the Senate Judiciary Committee’s subcommittee on Antitrust, Competition Policy and Consumer Rights. Both the FTC and the Senate were addressing not only anti-trust risks for competition but also the implications for consumer privacy of a merger of the leading Web search engine and leading behavioral advertising provider.

The discussion led the FTC to suggest last month that Web advertisers using behavioral targeting consider adopting several privacy principles, called "Governing Principles For Online Behavioral Advertising" (The Principles are excerpted below). The FTC has suggested that these should be considered for implementation as private sector self-regulation in the same way that earlier online privacy principles had been adopted by the US private sector self-regulation in response to the Safe Harbor agreement to meet the privacy mandates of the European Union’s Data Protection Directive. The FTC is presently soliciting private sector comment on these principles and their impact on online commerce.

FTC-proposed Governing Principles For Online Behavioral Advertising Privacy

To address the need for greater transparency and consumer control regarding privacy issues raised by behavioral advertising, the FTC staff proposes:

• Every Web site where data is collected for behavioral advertising should provide a clear, consumer-friendly, and prominent statement that data is being collected to provide ads targeted to the consumer and give consumers the ability to choose whether or not to have their information collected for such purpose.

To address the concern that data collected for behavioral advertising may find its way into the hands of criminals or other wrongdoers, and concerns about the length of time companies are retaining consumer data, the FTC staff proposes:

• Any company that collects or stores consumer data for behavioral advertising should provide reasonable security for that data and should retain data only as long as is necessary to fulfill a legitimate business or law enforcement need.

To address the concern that companies may not keep their privacy promises when they change their privacy policies, FTC staff proposes:

• Companies should obtain affirmative express consent from affected consumers before using data in a manner materially different from promises the company made when it collected the data.

To address the concern that sensitive data – medical information or children’s activities online, for example – may be used in behavioral advertising, FTC staff proposes:

• Companies should only collect sensitive data for behavioral advertising if they obtain affirmative express consent from the consumer to receive such advertising.
• FTC staff also seeks comment on what constitutes “sensitive data” and whether the use of sensitive data should be prohibited, rather than subject to consumer choice.

The staff is seeking additional information about whether tracking data is being used for purposes other than behavioral advertising and whether such secondary uses, if they occur, merit some form of heightened protection.

These principles and the US self-regulatory approach to the issue of behavioral advertising were presented this month to the European Parliament’s Committee on Civil Liberties, Justice and Home Affairs. The committee was considering the privacy policy implications of   

"..."behavioural marketing" founded on computerized data collection and on targeted advertising which are creeping into nearly every aspect of the social and commercial transactions – searching, browsing, networking, emailing and telephoning. This new situation, however, raises some critical issues about the sufficiency of  companies’ disclosures, the level of consumers’ understanding and control of their personal information as well as the security and confidentiality of the massive amount of sensitive personal data. Moreover, behavioral marketing directed at vulnerable individuals, such as young people and teens, clearly raises the question of the degree of privacy protection."

These discussions are preparatory to the pending update of EU Directive 2002/58/EC on data and consumer protection in the telecommunication domain by the Article 29 Working Party of the EU Directorate General for Justice, Freedom and Security. This group also is currently preparing a report on how well the privacy policies of the search engines of Google, Yahoo!, Microsoft, and others comply with the mandates of the EU’s Data Protection Directive.

A comment made by the chair of this group during the parliamentary meeting this month suggested that the Article 29 Working Party is considering implementing into EU policy that the Internet Protocol (IP) addresses associated with a specific person will be considered to be "personal data" and thus subject to the legal protections provided under the EU Data Protection Directive.

If this position should in fact become the basis for EU privacy policy, it could have enormous implications for Internet search engine operations within EU nations and may also impact the provisions of the US Safe Harbor agreement with the EU. This blog will track this activity as it unfolds and update events as they occur. Stay tuned.

What's in your wallet?

About a year ago, one of my credit card companies "upgraded" two of my credit cards to include a paypass RFID token in the card. In doing so, they automatically canceled my old card account and changed my credit card numbers (so my automatic charges failed). In my research, I have explored the security and privacy risks of RFID, mainly for a business. But these risks are not limited to the business, the same attacks can work on consumers carrying these cards in their wallets, cards could be cloned or be made to accept fraudulent charges. Thankfully, the financial risk to the consumer is fairly minimal, as any financial loss is carried by the card issuer. Alerting and fixing any mistakes is still a responsibility of the consumer. My complaint with the cards, is that I was sent them automatically with no choice and then had tremendous hassle to get my normal cards back. I called customer service and the representative could not understand why I did not want the card. He had not been trained in how to respond to questions about the technological aspects of the card, and instead he tried to follow his (non-relevant) script about the benefits. After he finished subjecting me to that, I spoke to his manager and was able to get my old cards back. But those came with different numbers because they had to cancel the account and create a new one, which possibly impacted my credit rating.

It seems that UK banks are now experimenting with similar technology, but at least two of their citizens were dismayed (the one who got the card and the one who bothered to write the article). UK (as well as EU and Canadian) citizens seem to be more privacy sensitive as a whole. I did not see any similar articles in the US press, beyond Mastercard assuring consumers that their technology is secure.

As a consumer, the subject of the article and I are both frustrated by the lack of choice given to us by companies trying to impose experimental technology on us. Generally, I am an early adopter of technology, but I don't appreciate the long pages of fine print that accompanied this change. As a business, what should you do about this? Explore which of your customers might be interested in trying out new technology, and get their permission to "upgrade" first! Many people won't care, but you risk alienating those customers that do by not notifying them of the change or giving them a chance to opt-out. You should at least send along a new matching wallet to go with the card.

Highlighting the importance of data privacy... one person at a time

I've seen an increasingly common trend for vendors or others to post sensitive personal information in public places, to prove that no harm will come, or that their solution will protect against any possible misuse. One person to do this recently, in response to the data loss by HM Revenue and Customs is Jeremy Clarkson, a TV broadcaster specializing in cars. Despite having no background in finance and fraud, he published his personal information in a newspaper column trying to diminish the idea that harm could come from the data breach. And that has come back to haunt him, as someone set up an automatic debit from his account of 500 GBP a month to be given to charity. My favorite part of the story is his new attitude:

"We must go after the idiots who lost the discs and stick cocktail sticks in their eyes until they beg for mercy."

Beyond a good laugh, what can we get from this story?

1. Review your bank accounts online regularly whenever possible. He did not check his account until the end of the month statement came and lost valuable time to oppose the debits.
2. Don't make yourself an easy target. He obviously called attention to himself as a TV personality that most regular people wouldn't be able to do (publish their bank account in a newspaper), but you should still remove the low-hanging fruit (easy data to steal). For instance, shredding sensitive information and only sharing it when mandatory.
3. As more people are harmed by misuse of their data, the outcry for better protection will grow stronger. This will filter up to the ears of our legislatures who will strengthen data protection laws to assist identity theft victims. Especially once it strikes their parent, sibling, or children.