NAC Attack Part 3: Interoperability, do you care?

Submitted by Mike Rothman on Wed, 2006-05-10 05:52.
::
Getting back to the NAC series, let's discuss interoperability. My friend, Joel Snyder (yes, that's a joke) did a lot of work for the InteropLabs (tests detailed here) to see if any of these solutions actually interoperate. Since collaboration is such a huge part of the marketing and positioning of NAC, it leads you to believe that there would be some measure of interoperability between the solutions. The InteropLabs tests showed that getting these products to work together is not there yet. But they see the light at the end of the tunnel.

So sometime within the next couple of quarters, we are going to see interoperable solutions. Great. But, I'm of the opinion that we are way too early in the market to worry about different products working together. NAC is a bit different in that you have a bunch of campus equipment and desktops that need to play ball, but those issues are not insurmountable. You add an agent to the device and support a VLAN configuration standard (only if you are out of band) to get the job done. I'm having a hard time seeing a use case where you'd mix up vendor equipment to deploy NAC today.

The inherent problem with the Interop test was that they make the assumption that customers will actually buy an ARCHITECTURE, as opposed to a set of products to solve specific problems. I think that's a bad assumption, especially since the paint is hardly dry on the products that make up these architectures. In Vista/Longhorn's case the doors aren't even on the car yet. Of course, it is Interop - so they need to know if things work together - but the test was premature based on where the market is.

From what I'm seeing, customers are buying interim products to solve specific problems. Though NAC is clearly strategic, right now the products being bought are solving tactical problems. Whether it's protecting conference rooms from the insider threat, making sure mobile devices are not cesspools before they access the network, or doing some internal network segmentation, these are tactical problems that don't require a brain transplant. These are not architectural-level problems.

Let me make the distinction a bit more clearly. Tactical solutions don't need to interoperate. They just need to solve the problem for a certain amount of time until the "strategy" is worked out. On the other hand, strategic architectural-level infrastructure must interoperate because you are looking at a much longer time frame and a much larger level of investment.

If you are going to overhaul your campus networks (which you will over the next 18 months), you want to pick a product that plays into an architecture that you are going to build out. If you are trying to keep the contractors out of the finance system, you buy a box to front-end the finance application and enforce some pretty coarse policies.

So in a roundabout way, I'm saying that the Interop tests were interesting because it indicates that we are going to move into an architectural buying cycle next year, when interoperability is real and will increasingly matter. Until then, buy something that works for your environment and solves your problem.