Monday, May 05, 2008

Traveling Wilbury Security

Sorry for the 20-year-old song reference, but I couldn't help myself after seeing the lines in Greg Shipley's diagram from his recent InformationWeek security article. I like what he shows but I think it can be radically more simple.

The technology world can be boiled down to two camps: those who trust their products to operate as expected and those who do not. You can guess into which camp I muster. I believe the first camp is naive and detached from the real world. (The real world is the place where intruders constantly violate assumptions, subvert logic, and make a mess of well-intentioned offerings.) The first camp spends more time talking about "enabling business" and "elevating the infosec conversation" while the second camp deals with the mess caused by the first world's ignorance of security problems.

Using this simple and intentionally provocative model I can propose two sets of lines. The first set could be labelled "compute" while the second could be labelled "transport". You could call these "host" and "network" if you like.

If you are a first camp person, the compute set is only one line -- that which computes. The transport line is also only one line -- that which transports (like a switch). This makes sense to me from a functionality (not security) standpoint. Anything of value ends up in the "OS" or the "switch". This is happening right now.

If you are a second camp person, the compute set is two lines -- that which computes, and that which verifies or at least observes the computation; call it a hypervisor or supervisor. The transport line is also two lines -- that which transports (again like a switch), and that which verifies or at least observes the transportation; call it a traffic intelligence system (to reuse terms mentioned in this blog).

This might sound suspiciously like trust but verify, i.e., trust the computer/switch but verify its operation. First campers trust, second campers trust when verified.

10 comments:

Anonymous said...

this remindes me of a conversation i had last week.
salesmen from two vendors presented their n-draft wifi-solutions.

the one seemed to focus higher on security.
the second advertised more the integration with other "enabling business" products.

while i would love to be able to make hardware/software disicions on a 'trust when verified' basis, i know i lack a whole lot of information on their production processes and attackers capabilities... so for me it still comes down to 'trust but verify'.
i try to compensate the deficits by pointing out to my ppl (as well as the salesperson) that its never an easy desicion and a main question should be/stay "how long is it going to take me till i recognize an intrusion (attempt) with this product?"

frankly i dont care weather a salesperson advertises 'security features' or 'enabling business'.
i know i can only rely our own security strategy... and this also includes 'trust but verify' (for the next decade).

Anonymous said...

This looks like yet another writer (Shipley) taking an extreme position on the viability of a (number of) technologies in order to get press and links to their article. Congratulations Rich; you've helped him get a few additional readers. This is soapbox stuff. IMHO there isn't anything really actionable in Shipley's work and your "camps" analogy isn't really a gem either.

Amrit said...

Although I agree with most of your comments I think you are misaligning the enabling business speak with the trust in their products camp. having a discussion about the importance of security to the business, and how it can be used to enable the business to increase the bottom line (think new revenue streams through the use of technology) doesn't mean that those same people sit around blissfully ignorant that products do not always (or rarely) work as advertised. Seemed like an inappropriate dig...

Anonymous said...

In just looking at the graph, and seeing the consolidation of multiple systems into smaller groups, how does this jive with the standard enterprise recommendations.

A recent article on Enterprise Best Practices stated: "Employ ... multiple overlapping, and mutually supportive defensive systems to guard against single-point failures..."

So, which is it?

You can't consolidate technology and then employ overlapping and mutually supportive systems.

Michael Dundas said...

Simple but succinctly put and true unfortunately.
-mike.

ntokb3 said...

This sentence bugs me:

"The first camp spends more time talking about "enabling business" and "elevating the infosec conversation" while the second camp deals with the mess caused by the first world's ignorance of security problems."

I don't work in the "security industry." I work in the real world and where I work security is infrastructure (i.e. overhead.) A good security product/process needs to occupy both of Rich's "camps." Think of it this way, if you're totally in the first camp, then you're not really implementing security... you're planning it or just selling stuff. Being totally in the second camp means that you're probably "disabling the business" and "lowering the level of the infosec conversation"... neither of which will get your projects funded or convince the business to comply with your controls. The dichotomy probably works for security vendors, but when infosec isn't a line-of-business, solutions need to span both camps to produce actual results.

JimmytheGeek said...

I get the point of the post, but not the song reference.

Did You Know? said...

very nice blog... Keep up the good work! God Bless!

W60 said...

Just a point to note - why is SSL VPN and IPSEC VPN network technologies being phased out on the diagram in to the firewall line? Yes most firewalls can do IPSEC and of late SSL VPN's but just because many features are becoming available in firewalls does not mean people are dropping dedicated devices. I am network security architect and there are many senarios/designs where you do not want to be putting the load or the network location is wrong to be using a firewall for these jobs. It goes against many 'best practise' modular designs to be inter-mingling these functions. I think the diagram does not represent the truth

Matt said...

Rich,

As opposed to the prior posters, I loved the title and am surprised to see the reference. Time to fire up iTunes.
I skipped the rest of the post though. :)

- Matt