DrewDilloNet

As a security geek, you no doubt hear from all the industry luminaries that security will someday built right into all technology. The overly used metaphor that you’ve no doubt heard in reference to this is the modern automobile: complete with seat belts and airbags.

The metaphor doesn’t make sense. This will never happen.

Conventional wisdom says that if a company is selling something that grossly endangers its customers, the government (or some other large external entity) will eventually step in and mandate protections. We do see signs of this: PCI and state privacy regulations as the modern day seat belt. But the similarities quickly end…

Let’s start diving into the metaphor itself: car? what car?

In the PCI/privacy example, the car is a whole organization that is handling the end users’ private information. This may be the largest element that can be held accountable to a customer, but this doesn’t really make sense. If there’s a hole in an obscure OS that’s exploited by a hack, isn’t the breach the fault of the company that provided that OS? There is a negligence factor with companies of a reasonable size not managing patches, upgrades, etc., but the scope of this problem is massive. It’s hard for most end-users to keep up with all the OS/network/hardware/application holes in their 1-3 home machines, much less massive organizations that aren’t technology focused.

I realize this is a paper tiger, I don’t think this point is actually being argued, but this is where we are with enforcement today.

So the cars are each product that reside in the OSI stack? Seems to make the most sense, if any products within the stack are unsafe, the whole motorcade is in trouble. BUT… to call products that reside at all of those levels by one name is a very weak generalization.

Two of these “cars” would be database software and a switch. What do these cars have in common? One is pure software, designed to run atop a commercial OS; the other is primarily custom hardware with proprietary firmware. The seat belt that one might provide, embedded firewall, is quite a different animal than the other, transparent encryption. They could be unified by identity or access control, but even those require some external negotiation: another “car”. These aren’t Hondas and BMWs, they’re more like matter and energy. Attempting to regulate the two together would be extremely difficult and that regulation would be obsolete as soon as the next version of either one come out.

Let’s focus in a little, then: databases. The largest vendors here are either relational or warehouse-focused. To classify these database types as cars is to compare a backhoe to a formula one racer. The two are very different in function and their security mechanisms must also be very different. Just try to install TDE on your Oracle Warehouse node. I’ll wait…

Operating systems are no different. Windows, Linux, UNIX, mainframe, common security practices can be devised across each, but the application and reasoning behind these solutions is very different. They’re serve entirely different problem spaces. And what is an operating system automobile to a relational database automobile? A car carrier? It’s a stretch to say the least.

What it comes down to is regulating usage of these systems. Looking back a bit: you can’t take a formula 1 car on the road in the US. Nor can you drive a backhoe on the highway. Those vehicles aren’t regulated the same way. it wouldn’t matter if it was legal to drive it down to Wal-Mart anyway, because the car couldn’t be used the way it was designed. They would still have to drive the speed limit.

To that end, a car is a finite object in the eyes of the government four wheels that move seats forward between 1-80 MPH. It has to have the following with regard to safety and everything else is completely ancillary. There is no re-inventing the car, there is no new product category.

New product categories are created all the time in IT. Would you let your usage of ERP be driven by laws written for CRM? Would SalesForce have succeeded if it had to comply with regulations created for its’ terrestrial competitors? Could you really mandate specialized certification for correct operation of the myriad systems that make up an IT shop? Good luck getting any startup off the ground with that rule.

You can’t run your data warehouse so quickly, it’s unsafe.

You can’t use UNIX, you only have a Windows license.

In the end, it comes down the mechanics running your shop. Companies have to hire generalists, because–no, they don’t have cars–they have vast, complex motor pools, roads connecting those motor pools, storage spaces, refueling stations, and have to maintain all of them. Sure we could all do a better job, but there’s a combinatorial problem with all the possible holes.

You can’t effectively regulate software vendors without missing the mark or killing innovation, you can punish companies for being particularly stupid with A/V or access control, but there’s no car in that oil. Old holes will still exist, new holes will be found. You don’t hear that about seat belts or airbags. And no one is actively trying to find ways to crash your car.

Beyond metaphors, there is a leap that security needs to make to emerge from the dark corner of the server room and into the mainstream of IT management. There is a maturity gap born of reacting, rather than anticipating the next hole–of band-aids, instead of helmets. IT system management is a discipline, but each new attack vector sends them scrabbling for gear outside established BPM. Now THAT is interesting.

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.

Cloud technology, it’s only up from here. Gartner’s predictions may be wild, but they’re not wrong to think BIG when they talk about cloud technology and it’s impact on every aspect of IT.

For those in the vendor space, cloud is another disruptive technology. Disruption is, as always, both opportunity and risk. Can the vendor capitalize faster than their longstanding competitors? Will new competitors emerge with tighter focus? Will they move quickly enough to keep drinking their own milkshake?

Cloud security is three levels of disruption:

1. Enabling security for liftoff – making companies comfortable with the idea that their data is everywhere.
2. Managing security from the cloud – enabling security on premise and in the cloud with the redundancy, availability, flexibility of the cloud.
3. Blow it out – securing the unique collaborative capabilities of the cloud, protection in a world where the walls have fallen.

None of this is new or proprietary. If you are a security vendor and your company isn’t thinking like this, it’s too late. Start looking for acquisition targets.

The one question that does stick out in my mind, particularly in security: even if the tech is cool, will companies trust cloud-based startups to perform tasks that they already have vendors for on premise? Essentially, what’s the stickiness of on premise trust with all the pressure to move into the cloud. How much time will on-premise vendors be given to get their cloud act together?

I suspect I know the answer, that it will depend on how deeply ingrained a product is in an organizations’ line of business or how hard it would be to strip out. This disruption, however, is still too soon to call. Too early to guess where the killer app will come from.

It may never pass the first stage of Schopenhauer’s truth, but here is my small contribution to the world of cloud computing:

terrestrial – physical IT infrastructure, housed on premise by an enterprise

I was actually laughed at the first time I used it, but I see a clear logic in extension of the cloud metaphor to describe the classic data center. It’s a paradigm shift to describe complex systems this way, certainly, but it’s a forceful description of the market today to say that the state of IT technology is bound to the earth.

There comes a time in every market where the tables turn, the clouds part, the wave crashes, the metaphors mix, and the sales process goes from an uphill battle to Olympic slalom. Typically, this is also a time of convergence in the market, the best-fed fish eat the smaller ones and sharks from a completely different food chain start eying them.

In the security market, we have seen two forces that drive this:

1. A problem becomes so easy to solve that it’s virtually painless — labor or product-wise, it’s all money at the C-level, the problem just becomes cheaper to solve than it does to live with
2. A problem becomes so widespread that a company would be grossly negligent for not doing something about it

In essence, the product becomes a no-brainer.

This wave has crashed a number of times in security: antivirus, firewalls, full disk encryption, to name a few. Some would say DLP, but I would argue that DLP is a foundational technology that really only answers half of a problem.

Sometimes the wave never crashes. Email encryption, for example, has bumped along for a decade, but never really exploded. Why? Email is terrifyingly insecure and holds yottabytes of the most sensitive information. But email protection just never became easy. No one ever created a #1 to balance out the #2. Some CISOs drove it through and slapped it in bold letters on their resume, but it’s not a no-brainer.

Disk encryption, particularly mobile disk encryption, was the complete opposite. It was weakly mandated at first, still an uphill battle to sell, but case after case after case after case after case built up a powerful #2. And at that point, about two years ago, the products were at a point of maturity to make #1 true as well. Wave, convergence and now the market hangs around $250 million with a healthy rate of growth.

Where’s the next wave?
What’s the next no-brainer?
And how will it be strapped to the hot air balloon to the cloud?

It will be hard to recognize those today, likely they are rough, not simple enough to satisfy #1. And CIOs have likely used some other technology to give themselves a false sense of security for #2.

Ever more atomic data protection at ever increasing levels of specificity, with less and less impact to IT practices and end-user experience. That’s the mantra here on earth and in the cloud.

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.