Strategic Security – Embedding it

Posted by Gunter Ollmann on June 12, 2008 at 9:00 PM EDT.

A sizable part of my role involves finding solutions and answers to difficult security questions. It’s easy enough to talk about the threats observed today, and not too difficult to extrapolate how those threats will evolve over the next couple of years, nor is it that difficult to discuss how current protection technologies function against the threat and the types of research or investment likely needed to combat their evolutionary descendents, but it gets a whole lot tougher if you have to dust off the old crystal ball and provide a longer-term perspective on the shift from tactical security technologies to strategic security delivery.

A whole subset of difficult questions regularly asked of me relates to the horizon-three strategic aspects of security – in particular, how will security technologies be deployed in the future?

While there are multiple components in answering this particular question, I’ll attempt to explain my long-term vision of one aspect; security technologies will become increasingly embedded in to the products and services we purchase in the future.

(I hope to cover other aspects to this same question in future blog entries)

A Future for Embedded Security

First of all, I believe that the Software industry places too much emphasis on the end user having to protect themselves, and that end users have too high an expectation that software vendors can make their products impervious to security flaws. There is room for compromise, and embedded security technologies play a critical role.

Embedding security means different things to different people. In my mind’s eye, I envisage it as the embedding of particular (more often ‘specialized’) protection technologies directly within the applications, physical devices and services we use for business on a day-to-day basis. I also feel that, for these embedded security technologies to be successful, they have to be transparent to both the end user and their support staff.

While some security technologies, such as encryption and event logging, have made strong inroads on the embedding front, more interactive protection technologies such as anti-virus and IPS are struggling. A likely reason for this is the fact that almost any organization feels that they can create code, or drop in an existing library, to cover encryption and event logging; but it’s very rare for them to attempt the same with the more sophisticated and dynamic protection elements.

Non-security professionals like to use the automotive industry as an analogy for the software industry – which I think is a bit unfair given the length of time each as had to mature and learn from its failures (the automotive industry has a hundred-year head start and, if we were to compare advancements over the same elapsed period of time, car divers were still expected to have a servant walking ahead of their vehicle waving a red flag to alert riders that they should control their horses in case they were startled by the approaching noise) – but, while I dislike the analogy, I’ll stick with it to explain how I see the software industry changing and embedding security technologies in the future.

First and foremost, what could we learn from the automotive industry?

  1. Safety and security are embedded technologies – and car buyers base a proportion of their purchase decision on the extent to which they are present, rather than who manufactured them.
  2. Car manufacturers don’t build everything themselves – they assemble cars using components from the most appropriate source.
  3. The most successful safety and security technologies embedded in to vehicles do not require interaction with the driver – they are designed to automatically protect and secure.

When someone goes out to buy a car, they not only have access to information about that vehicles crash test performance, but also a list of all the safety and security features built-in. Using this information, the potential purchaser can evaluate whether those security and safety features tick their personal “risk acceptance” box – along with more important decisions like engine performance, color and whether grandma will be able to get in to the back seat with her arthritic knees. At no time are potential purchasers told to go elsewhere for the safety components, nor are they confronted with who actually made the safety equipment – it doesn’t matter, as long as they trust the company that assembled the vehicle to have installed that safety equipment correctly.

You also don’t decide to buy a new vehicle and then be confronted with questions such as “do you want the 4 inch or 5 inch embedded side-impact door-bars?”, nor do you expect to buy a car with all the airbags neatly stacked on the backseat (still in their shrink-wrapping) so you can install them yourself when you get home. The most important safety technologies are integral to the vehicle.

So why do we still leave these safety (i.e. security) decisions to the poor guy trying to buy a software business solution? We know they need security, we know they expect it, yet the software industry leaves it to the purchaser to try figure most of it out. Given a consumer choice in purchasing a Web server solution destined to be protected after procuring security products from multiple vendors, and a Secure Web server with all those protection technologies already built-in, which one do you think they’ll go for?

The same, but different

So what’s the holdup in successfully embedding more security technologies? A major hurdle yet to be overcome is the process of shrinking many of the commoditized protection technologies in to engines that can be easily deployed and embedded in a wide array of products. Today, while some security vendors do sell OEM-able security modules, they are typically only incorporated in to another security vendors commercial security products – such as multi-function security appliances.

Part of this problem is due to the reactive nature of the technologies and their need for constant updating or chaperoning. For example, if signature-based anti-virus products were airbags for cars, you’d have to get the gas refilled every couple of days, the bags re-stitched monthly, and you’d probably need to push a big red button on the dashboard to get it to deploy prior to an accident (see why “transparency” of operation is important?).

Over the next few years I’m expecting preemptive protection technologies to become more prevalent. These engines typically do not require a stream of updates, and instead make use of advanced heuristic, behavioral and adaptive technologies – and are already here to some extent. But, until they become commoditized and widely available, some security vendors may feel there's more money to be made selling them as separate security solutions than as embedded components. (btw thats just an observation rather than some kind of covert, undisclosed IBM strategy)

Obviously, the research and development of preemptive protection technologies is a pretty important facet of what X-Force does.

That said, I believe it inevitable that many of the stand-alone security products we see today (especially application specific solutions) will become largely redundant in the future as they are replaced with “secure” versions of the applications the consumers wanted in the first place. I don’t think it matters to those consumers who added the “secure” part, merely that they’re confident that it works.

Sure, one size doesn’t fit all, and it’s not likely to turn the security industry on it head by itself. Just like the automotive world with its kit-car builders, F1 racing cars and enthusiasts that want customize their “ride”, you’ll still have requirements for the high-speed security solutions and other boutique offerings from all the brand names. But the fact remains, security is an integral component of modern software solutions and needs to be treated as such. The more embedded a security technology is, the more integrated it will be, and the more transparent its successful operation will be to the end user. And that’s what we all want!

    Copyright 2001-2008 © Gunter Ollmann