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.

Security execs are insecure about Twitter

On Friday we wrapped up a very successful Security Forum. I’m very pleased at how well the theme — navigating the new security & risk reality — resonated with the two hundred security execs that joined us in lovely San Diego.

For those who attended, let me send out a big THANK YOU. I know it’s a lot to take two days out of your schedule and, as always, we appreciate your attendance. And remember, you can head to the link above to get all of the presentations.

But now we must return to work and start implementing all of the insight we discussed. To help, I thought I’d take an opportunity to summarize this year’s top three takeaways, in no particular order.

Takeaway 1: Giant squids are the stuff of horror movies, and stand-up comedy. For those of you following along, you’ll know I struggled with whether I should incorporate the recent squid invasion of San Diego in my opening remarks. I did — and it went over well. I shall live to host another event.

Takeaway 2: It’s critical for security execs to master a shift in ownership. Ok, the first takeaway isn’t of much help, but I couldn’t help myself. So this one is for real. The entire event was organized around three shifts in the security and risk management landscape: 1) a shift in business expectations; 2) a shift in data ownership; and 3) a shift in security architecture. The shift in ownership proved to be the most critical. Why? Because a new generation of outsourcing and the consumerization of IT are usurping control from IT. The introduction of cloud computing gives IT the flexibility to tactically outsource IT services. At the same time, the enterprise workforce is demanding more flexibility, and employees sporting consumer-grade gear are eroding traditional security controls. As a result, today’s organizations don’t own their data anymore.

This leads me to . . .

Takeaway 3: Security execs hate Twitter. I’m not joking. This year’s audience was most excited when two speakers — Marcus Ranum and Hord Tipton — denounced the use of Twitter. On day one, there was loud, thunderous applause when Marcus mentioned that he is adamantly against Twitter. This was repeated on day two when Hord mentioned he, too, didn’t see the value in Twitter. Ironically, I was tweeting during both accounts (search for #FSF09 if you’re interested in my observations), but I digress.

In all honesty, this makes perfect sense. Twitter is a scary. There is the chance that intellectual property could be leaked; that users could click on malware links ingeniously disguised in tiny URLs; or that your company could be liable for inappropriate comments tweeted from a corporate device. Of course, all of that is added to the fact that there is a misconception that Twitter is just filled with nonsensical observations like, “The line is long at Starbucks right now.”

But I was still a bit shocked by the audience reaction. It’s very clear to me that we’re at an inflection point in information security. What we called a “shift in ownership” will be the challenge of all CISOs heading into 2010. It’s no longer sufficient — and definitely not necessary — to denounce the use of social media. Security has to find a way to let enterprises security embrace consumer hardware and software. Stay tuned for more research and blog posts, but in the meantime I’d love to hear your thoughts. Can security execs continue to simply prohibit apps like Twitter?

Let me know. Oh, and feel free to email me. I know you won’t tweet me your thoughts. (But just in case, it’s rwhiteley0.)

How Should Auditors Deal With Such Oddities?

Two weeks ago, I commented on the changing role of the risk management professional, and thought it would be worthwhile to spend a few moments discussing the auditor as well. In a contest of which job is likely to see more change in the next two years, I would expect a photo finish.

Over on the Institute of Internal Auditors (IIA) site, Norman Marks started an interesting discussion about continued fallout from the Heartland data breach. In a Q&A interview with CSO Online, an understandably defensive CEO Robert Carr states that the company’s Qualified Security Assessors (PCI auditors) were worthless and gave them false reports for the previous six years suggesting that their security systems were just fine. I don’t think we need to dwell on the concept that compliance with security standards does not equal total security, however this does bring up a more interesting debate about the role of the auditors.

As expectations for greater corporate accountability and disclosure continue to mount (some would say more slowly than expected) audit reports are going to be set under the most finely tuned of microscopes to be examined for accuracy and thoroughness. Two of the most important questions auditors will have to answer will be:

1. What is the scope of the audit?  This must include what is evaluated and what is not as well as what justification exists for including or excluding specific elements.
2. What are the auditors assessing specifically?  This must spell out very clearly the purpose for the audit (e.g. We are evaluating whether or not these systems are compliance with PCI, no other opinions should be inferred from this report).

If this information is not clear, both sides are left exposed. Would an auditor be demonstrating additional value and good faith by calling out other possible issues outside of their official report?  Yes. However, it would be unfair to expect them to volunteer information that is beyond their defined scope... there is more than enough pressure as it is to get that right.

[Posted by Chris McClean] 

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?!

The Trials And Tribulations Of Public Sector CISOs

Just the other day, I was speaking with a state CISO about the security challenges she's facing in today's environment. In many regards, she echoed what I've heard from other CISOs in the private sector -- the business (Govenor) is expecting us to do more with less, Web 2.0 bring along a whole new challenge in terms of security, etc. At the same time, she reminded me just how different things are for the public sector by articulating the extra challenges she has on top of all the usual ones:

1. CEO (Governor) and executive management (Administration) changes every four years. That means you have to start from scratch every four years with the new administration. You also have build to relationships one level below the political appointees to ensure continued support.
2. You are competing for budgets against pretty important priorities, i.e. healthcare, education. Legislators often don't understand why it's important to upgrade the state's IT infrastructure.
3. The IT environment consists of several dozen smaller agencies working independently. Many of the smaller state agencies don't even have a dedicated IT person, making it harder to centralize anything and enforce security policies consistently.
4. No room for error. A mistake is guaranteed to make newspaper headlines. A lot more information needs to be fully disclosed to the public, just as part of doing business as a state entity. So when things go badly, everyone knows.
5. Procurement processes are cumbersome. You cannot just go out and buy a tool or hire a consultant. You have to go through the state mandated process that could take months. This makes it more difficult for the security organization to be nimble and agile.
6. Public sector is subject to additional regulations. Some of these regulations simply don't apply to the private sector.

Now combine these challenges with two facts: 1. states possess a wealth of personally identifiable information (PII) and other confidential information on citizens and businesses, and 2. states process billions of dollars a day. And you have yourself a very attractive target for malicious attacks. As the state CISO, this leaves you with a huge burden of responsibility on your shoulders and a tough road ahead of you.

How should we address some of the above challenges, while ensuring taxpayer money is being spent appropriately? Do you find yourself facing other similar challenges as a public CISO? As always, I would love to hear your thoughts.

[posted by Khalid Kark]