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.
Comments
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).
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.
-mike.
"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.
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