CTO Chronicles

Silly SNAC's, part Duex

So, Jennifer over at security uncorked believes I went off a bit half-cocked on the silliness of Symantec's "Peer to Peer" NAC referred to in Tim Greene's Network World NAC Newsletter.  I have not had the opportunity to meet Jennifer, so hi, Jennifer.  Nice to meet you; thanks for the feedback.  One of the many things about which I'm uninformed is whether a blog debate such as this should take the form of different entries or simply replies off of the original entry.  I finally decided on the former. By the by, is there no dead-thread rule in the blog-o-sphere?

I digress.  Just so we're clear, my original post was not intended to be a critique of Symantec's overall approach to NAC, nor was it intended to imply that Symantec is somehow moving solely toward peer-to-peer NAC and away from infrastructure based NAC.  It was meant to be a critique of the peer-to-peer approach generally, and to point out that I'm having difficulty seeing the value pitch.  I stand by that original assessment, though in the spirit of digging for facts, I do have a barrage of questions below for Jennifer or anyone else to help answer.  Anyhow, here goes:

From Tim's Article:

With peer-to-peer NAC, groups of endpoints fitted out with Symantec’s NAC software can be restricted to talking only to other endpoints in their group and only of those endpoints meet NAC requirements.

Aside from being editorially challenged (I assume 'of' should be 'if'), this seems to imply that the endpoint must have Symantec's NAC Client (or Symantec's Endpoint Protection Client, or both) in order to carry out the enforcement of the centrally set policy.  No huge surprise, but worth stating for the record.  Now, this also implies that blocking communications while outside the bounds of the enterprise is possible (the primary point of peer-to-peer NAC, according to Jennifer), since the off-premise peers would clearly not be in the same "NAC group" as the governed endpoint.  However, a few paragraphs down, Tim says this:

The big limit of this feature is that it can apply only to machines that are managed and have the Symantec NAC client. So guest machines and those owned by consultants would not support this feature, and they would have to be isolated via other means.

The good news is that the confusion over which client you need is cleared up, which is good.  But if peer-to-peer NAC can't block incoming connections from guests within the enterprise walls who aren't in the governed endpoint's NAC group, how is it to block connections from endpoints outside the enterprise walls?  Tim's a smart guy, so it's hard for me to see his getting something this important this wrong.  It's even harder for me to see Symantec's not responding with a correction if he had gotten it wrong.

So, I'm left with the following questions:

If off-premise protection is the primary benefit to Symantec's peer-to-peer approach, why not pitch it that way to Tim?  Why bother even going into the within-the-walls scenarios in such a short article?

If peer-to-peer NAC can limit inbound connections from off-premise hosts, why not limit on-premise guest machines' access the same way as an additional layer of security?

What is the difference between the off-premise protection outlined in Jennifer's post and the functionality provided by any host-based firewall or intrusion prevention product out there?

Finally, what, exactly, do you really get with this approach?  Is it fine-grained control over the communications between and among enterprise clients operating within the walls of the enterprise and running Symantec's NAC software, as Tim's article implies?  Or is it governance and protection of clients when they are outside the walls of the enterprise, as Jennifer's rebuttal implies?  Or, as if by magic, is it both?

On balance, I still say it's the first one, and it's still a silly place to start.

The Threat Inside

Another summertime stalwart for me is Mark Twain.  Whether it's due to the super-cool white suit, the fact that most stories were set during summer, or just his cool-glass-of-lemonade style of storytelling, Mark Twain stories were a mainstay of my surviving the inevitable 18 hour car trips on summer vacation.  Of course, Twain had a famous quote on statistics, and I was reminded of that quote when reading the recently released databreach report from Verizon's Business Risk Team.  Nathan McFeters was apparently reminded of similar things given his recent entry on zdnet.  Nathan asks some reasonable questions in his entry, but it seems that the bulk of the coverage of this report has centered around the idea that the insider threat has been misoverestimated.  A reasonable impression, if you read the Executive Summary.  But the "Insider Threat" in the report seems to be limited to internal people (most often IT people) doing bad things for whatever reason.  So, really, the report's main finding is that most of your people are good people, rather than bad people.  Good to know.  Not exactly groundbreaking, but still good to know.

What's missing from the report (as well as the coverage of it that I've seen) is any discussion of the role played by botnets and keystroke loggers in accomplishing the initial breach.  At least in my experience, this has been a major, critical factor in what ultimately ends up in data loss/corruption.  To me, this is really where NAC comes in.  In addition to walling off your partners and securing your critical assets, it just seems to make good whitewash-your-fence sense to put in place "reasonable" desktop policies and procedures that (a) deploy patches and AV/AS updates regularly, (b) enforce access policies around the consumption of those deployed updates, and (c) watch what users do even when they're patched and updated.  A combination of those basic, non-rocket-science things would, I'm willing to bet, have prevented the overwhelming number of breaches investigated by Verizon's team.  Then instead of fighting databreach fires, we could all have a cool glass of lemonade.

And Verizon could focus on making my phone work.

NAC now? NAC later? How about both?

Since it's sum-sum-summertime, I'm inevitably reminded of afternoons spent at the swimming pool, which in turn (of course) reminds me of candy.  Now, everyone had their own favorite candy back then.  Some would continue to insist on candy that, in the space of about 3 seconds, was going to melt in the heat that is a trademark of Texas summers.  Others would go for a more heat-resistant candy that, while far less delicious, at least wouldn't melt away like a wet wicked witch.  My own favorite was Now and Later.  Marketing delayed gratification to kids is always a tricky business; however, these candies were a stroke of genius.  Eat them now.  Save them for later.  They're a tasty treat either way.

I was reminded of all of this last week, reading Tim Greene's article on the Gartner Marketscope report.  Greene summarizes Gartner's viewpoint that even initial NAC deployments must take into account the organization's larger strategic vision of network security, endpoint compliance, etc.  Certainly, we agree with that.  However, the article also seems to pose a choice to organizations between an "overlay" solution that may have a short shelf life (say, a Snickers bar), and a more broadly integrated infrastructure-based solution that's not quite there yet (those fun dip things that had the inedible edible stick).

Any pure-play (overlay, whatever you want to call it) NAC vendor that cannot articulate a vision for how their solution fits into a larger overall framework is going to melt away very quickly.  And even before it melts away altogether, organizations are likely to get disgusted with what it's turning into and simply toss it.  By contrast, current pure-play vendors that do have that vision are like the Now and Later candy.  They provide a good firm texture now, but are pliable enough later to mold into your general network security strategy.

So, I say the choice is not as stark as portrayed in Tim's article, either for customers or vendors.  You can get your NAC snack now, knowing that even after some cannonballs and back flips, you'll still have something that is not just relevant, but delicious.

Silly SNACs

Tim Greene has a newsletter story on Symantec's "Peer to Peer NAC."  No, this is not using NAC for the purposes of governing Peer to Peer application usage, but rather leveraging the idea of Peer to Peer communication for the purposes of enforcing NAC policy.  Setting aside, just for the moment, whether the chickens can guard their own henhouse, this is just a silly idea.  It's a silly idea from an enforcement perspective because NAC policy enforcement (especially for managed assets capable of running a persistent agent, which is the only kind of asset Symanatec can govern in any event) will be done at the point of access (WAP, Wireless Controller, VPN Termination, Ethernet switch, etc.).  It's silly from a policy definition perspective since, again, it has no notion of unmanaged (or unmanageable) assets.  So it's purely a short term stop-gap, useful only until standards evolve that allow for ubiquitous enforcement at the point of access.  Yet, it's only a stop gap for general purpose computing assets that are tightly managed by the organization.  Pretty much by definition, these are the assets that pose the least risk to your organization.  Why would you start there?  Why implement a short term stop-gap product for assets that pose the least risk?

Silly.  Fusilli, Jerry.

Educause SE Regional Event

While I am sitting not attending any of the regional Educause conferences this year, our own beloved VP of Marketing, Trent Fitz, is speaking along with Chuck Adams of Northwest Mississippi Community College.  We love it when any of our customers speak in public; and Trent, in spite of being from Oklahoma, is a good speaker and all around fine American.  If you're headed down to Jacksonville, by all means stop in and throw a tomato (or a tomatoe, if you prefer) at Trent.