DrewDilloNet

Securosis is right on a number of fronts about what you’ll see in Data Security at the RSA Conference this week. And, from the discussions I’ve been in with the analyst community recently, you’re about to be blasted with all kinds of coverage of aliasing / tokenization and format preserving encryption (FPE).

Full disclosure, I do work for a company that competes in this space, but I really do have concerns about what customers are being promised and the shortfalls they may not yet understand.

Tokenization, per Securosis:

… replaces credit card numbers or other sensitive strings with random token values (which may match the credit card format) matched to real numbers only in a central highly secure database.

It’s not new. Also known as “data aliasing”, Shift4 and Ingrian both offered this as a service going back as far as 2005. A number of credit card processors have also offered transaction IDs the same size/shape of credit card numbers for years. Companies I spoke with still needed, or thought they needed, credit card numbers for marketing demographic data.

What changed? Partially hype, partially that companies began to offer tokenization products. I do credit that hype for teaching companies their options, but, as with all hype, some of those now excited about tokenization just aren’t good candidates.

Why it’s the best thing since sliced bread:

• Systems that don’t need to use sensitive data are taken out of PCI audit scope. Though, per the latest PCI FAQ, a system strongly encrypted (read: entry point for FIPS in PCI), is also out of scope for PCI audits.
• Sytems can pass around data without expanding data types to hold expanded ciphertext. There are a number of encryption modes that perserve data length, but who is to say that the resulting ciphertext won’t contain a character a system can’t handle (string terminator, etc)?
• Systems may continue to use sensitive data as primary indices. This is more common for SSNs or tax IDs, which is why a lot of tokenization deployments actually begin with HIPAA or SOX compliance.

Why it’s worst thing since Windows Vista:

• This free lunch is more expensive than most. Think about it: if just one of your applications starts speaking tokens, while all others are speaking credit card numbers, the whole house of cards falls. Meaning, there is no piecemeal deployment. All systems must be changed at once, a level of coordination I have rarely seen in the enterprise.
• This may change with some of the transparent database encryption vendors making inroads, but today, also per Securosis:
  

  No matter what anyone tells you, there are always requirements for application and database changes, but some of these approaches can minimize the pain.

FPE, per Rich again:

Format Preserving Encryption encrypts the numbers so you can recover them in place, but the encrypted values share the credit card number format.

That’s a little high level for we tech weenies. Proponents of FPE bill it as a mode of AES that returns data of the same input type (ASCII, numeric, etc.) and the same byte-length as the input.

There’s a lot of interesting thought behind how this works, but no magic. If you decrease the number of inputs to a certain function, you can decrease the size of the resulting vector space by the same amount. This is legal in math and thus crypto.

In a wild oversimplification: a function can be found f(x), such that for values of x only being 16 bytes within the ASCII numeric range, the output y will also be within the 16 byte ASCII numeric range.

Why it’s the best thing since sliced bread:

• The same pluses, generally, as tokenization. Note that, unless your auditor finds FPE to be in the “strong encryption” bucket, per the new FAQ, FPE does not remove systems from audit scope.
• “Local” options are much cleaner than tokenization. Libraries that can receive AES keys and operate remotely, POS, etc., can perform FPE autonomously for extended periods of time very easily.

Why it’s worst thing since Windows Vista:

• The same drawbacks as tokenization, there’s a large coordination/conversion effort that requires all hands on deck.
• Some FPE AES modes are “under review” by NIST, for what that’s worth, but there is yet no standard. Meaning, the FPE you buy today may be different if/when these mode finally get approved. Or they may never be approved at all and vendor lock-in could be painful to pull out of.
• Combinatorially speaking, decreasing the vector space to ASCII or, more so, to numeric values of ASCII, means a much smaller number of possible outcomes. Anyone attempting to crack AES CBC may have a leg up knowing that the input is a credit card and will thereby be limited to numeric ASCII, but limiting the output would seem to raise the odds of collision yet higher.
• FPE has the same key rotation complications of regular encryption. The matter is even worse in FPE land, where these values may be all over the place and rotating them en masse means a repeat of the intial roll out for each rotation. As long as PCI requires six month to a year rotations, this is a big problem.

We hear it all the time now. Mom and Pop shops calling us up and asking about tokenization/aliasing or FPE, when all they have is one Oracle database. Each definitely serve a need, but do go into each with your eyes open. They’re not quick fixes and there ain’t no such thing as a free lunch.

See you at the conference.

There is always a lot of finger-pointing at compliance mandates and their application. They are not, as their critics often cite, “real” security. Real security is an abstract land where authentication is an ever-evolving heuristic dance, internal networks are impenetrable walls of malevolent retribution, every atomic element is encrypted within a FIPS Level 4 module and is only visible to users who absolutely need to see it that particular second, and only exists in the mind of ubergeeks and cryptography professors.

In the real world, the data being so rigorously protected in the above scenario becomes either so locked down as to become completely unusable or the staff required to maintain this level of security is so large as to drive a company into the ground. All this in the name of protecting the information assets that drive business.

On the other end of the spectrum isn’t compliance, it’s business. In business land every piece of information is available when needed, calculations and different views of information can be pulled from hundreds of millions of sources instantly, and your level of efficiency is a product you can sell. Business land built up some meager defenses, maybe even raised a militia, but they are instantly bowled over at the slightest hindrance of business.

This one isn’t hypothetical, it’s where most companies are:

Why would I protect a customer’s confidential information? It might take seconds out of my response time. Maybe I’ll put controls around this piece of information, after all, if a competitor got everyone’s email addresses they might steal all my customers!

That was the state of information security in the 90s, that’s the state of Data Protection in the late 00s. Bare minimum, protect the business as long as you don’t even slightly impact the business.

Now, this isn’t anything new. Risk Management is an old discipline and many attempts have been made to tie security risk management to ROI. ROSI has long been a byword among security architects, but the numbers always come out too high to be credible, even when true.

From the vendor perspective, every security company wades into this quagmire thinking, “We can do this, we can be the company that makes the case for security.” They put together 10 fear slides to scare the bejeebus out of the customer, slap on an architecture diagram and lose the prospect in the first five minutes. That is not to say the fear approach always fails, but the vast majority of the time, one little vendor can’t bridge the divide between security and business.

Businessland’s laissez-faire attitude toward security is destructive though, eventually another entity has to step in with regulation. Regulation has three goals:

1. Helping we little guys — rare
2. Protecting a bigger fish in the pond — do-as-I-say-not-as-I-do regulation
3. Preventing legal action that could burden the legal system or cause a massive industry collapse

Regulatory compliance isn’t security. It’s insurance against the wildest reaches of negligence. It’s justice for those security architects that can’t seem to convince the CFO that the sky is falling.

Give us your tired, your huddled IT security masses, yearning to segment their networks…

Compliance isn’t security in the same way that the local police department isn’t security. It’s a baseline intended to prevent chaos. And compliance done right is a baseline for building out a higher level of overall security.

As a vendor, this is a completely different conversation. Compliance is a business driver, so budget flows for compliance in ways it never will for security fear sales. And, beyond cynical business concerns, compliance gives vendors the opportunity to actually help a customer by making a real tactical impact on the bottom line. There’s also a chance here to be emissaries for Securityland, knocking down some of the fear that security is going to bring business to a halt. But that’s a topic for another time.

And all of this is not to say compliance is perfect. Compliance mandates sometimes adopt baffling requirements from Securityland.

Is a brute force collision against a significantly-random AES256 key really the most likely attack vector?

But if applied correctly, and I will call out PCI DSS in particular, they go a long way toward business-proofing a company’s security posture.

If I were to put forth one complaint about compliance, it would be the method of application. Auditing of compliance varies between auditing companies and even among team leads at the same company. I have worked with customers whose auditors say that they need to see source code on all data protection products to verify secure key transmission and storage and other companies where simply buying a data protection product earned the organization a one year pass.

The blame of uneven compliance application doesn’t fall solely to the QSAs, Businessland asserts itself again in selection of auditors. One popular auditing company in the US has had trouble overseas, where they are seen as being too strict. I won’t pretend to know the answer of how best to audit the auditors, ideally this is built into the regulation itself, either being more prescriptive or adding a periodic check on audit results.

Compliance is an easy target for blame, especially when you’re in a CNN moment breach, but you don’t get very far blaming the police for the theft of your unlocked car. Use the regulations, use the business case of compliance, use the auditors findings, use vendors who understand security, business, and compliance, and build toward real data protection. IT risk management may never catch on at the c-level, but compliance is an easy and achievable baseline for limiting risk and doing so with business owners’ buy-in.