John Cougar Mellencamp on NAC

John Cougar Mellencamp on NAC

Summary: Much is being made of a presentation at Black Hat by Ofir Arkin of Insightix. In that session, Arkin "raised questions" about the ability of Network Access Control technologies to do what they say they can do.

TOPICS: Networking

Much is being made of a presentation at Black Hat by Ofir Arkin of Insightix. In that session, Arkin "raised questions" about the ability of Network Access Control technologies to do what they say they can do. Without the benefit of having actually seen the presentation, my sense of it is that the paradigm of NAC itself was questioned. And rightly so, because one version of that paradigm may be broken.

Defending the Network

Nearly all of the language around IT security (especially Network security) still lives in the middle ages; in the days of castles and moats and walls (made of fire, inevitably) and defense. Network security is a constant battle, a daily walk of siege mentality. One problem: the business guys keep demanding that the walls have holes in them. This problem led Jim Allchin of Microsoft to use the more than awkward phrase, "semi-permeable firewall" back in 2002.


Network access control (especially as it exists in the Cisco and Microsoft product sets) is still wrestling with this metaphor of a "semi-permeable" firewall. They're trying to come to terms with the idea that *context* is really the key to network health and security. Context, in turn, demands understanding the role that any given individual or device is playing in the network. And understanding roles leads one *firmly* into the land of identity. The real issue with NAC is the missing steps of context and role.

Vendors that *are* working on the context and role problem (vendors like Identity Engines, Trusted Network Technologies, ConSentry and Forescout) are beginning to find a marketplace awakening to a post-medieval paradigm. Lessened in importance are the castle walls, moats and forces of defense, while knowing who someone is, what they want to do and whether or not they have the right to do it is being elevated. Innovative NAC vendors are now beginning to tip-toe into a new paradigm that operates on that old John Cougar Mellencamp ditty - "When the Walls Come Tumbling Down."

Postscript: I debated going with the Pink Floyd, "Another Brick in the Wall" ending, but thought Mellencamp more appropriate. I'd be interested in hearing your thoughts.

Topic: Networking

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • I notice

    I notice that, except for Identity Engines, all the companies you mention ar epart of the Trusted Computing Group. Does this mean that the TNC approach is different? Better? Why no mention of the third NAC approach, TNC?

    I would think that an open, standard approach is the way to go. No vendor lock-in. Broadly supported. Broadly tested and implemented. Etc.
    • Standards will be hard to establish

      Being in this space, I can tell you that developing standards will be extremely difficult since many of the vendors have patents on exactly HOW the technology works for their solution.

      I think Eric's point is spot on - Identity needs to be an element of the network, and one that helps determine Access, assuming NAC means Network Access Control.

      The other piece to all of this is that there is basically one key vendor that has written the baseline code for the NAC solution out there - OPSWAT. They are 100% channel focused which is a pretty cool way to do it. I think it will allow them to stay focused on keeping the baseline code set as pure as possible and let other guys extend/enhance the feature set.

      That's my two cents

      identitystuff @
  • Not sure what opinion you were seeking

    I personally find Mellencamp annoying, don't like his style or song writing.

    Now onto the real meat. An open standards system will most likely be watered down, include too many compromises and will require a committee which is the kiss of death for getting something Real Soon Now.

    I think vendors ought to develop their own systems that enable the level of security the customer wants, the customer defined as the service provider. With the provisio that the service provider is liable for the damages incurred by the loss of the data or identity of their client/user.

    Strike fear into the heart of a CEO and you'll get great motivation for designing secure systems with logging etc. Internet banking systems come immediately to mind. Customer makes a transaction, gets his identity expoused by the bank's application, the customer can sue and win just by showing that they used the banks software to generate the transaction.