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.

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.