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.

MSSP and NAC - True Love

As a company with long-standing relationships in the Managed Security Services space, we've talked a good deal around here not only about how our own product can be leveraged in the MSSP space, but also the general pros and cons of having NAC as a managed service.  Our own VP of marketiing has an advertorial here.  Where I come down on this is that Managed NAC is a no-brainer for organizations that already subscribe to managed security services, and absolutely worth considering for organizations that leverage managed services for other parts of their IT business (Help Desk, WAN, Internet bandwidth, etc.).

Given both the technical and business problems that NAC solves, managed NAC is a natural extension to current managed security offerings, from the perspective of both the MSSP and the business organization.  It provides the MSSP the opportunity to bring governance "deeper" into their customers' networks rather than being limited to reacting in the perimeter; and it provides the customer the opportunity to leverage economies of scale and breadth of experience inherent in managed provider offerings.  Given the switching and desktop depth of most NAC solutions, managed NAC has synergy (Buzzword Bingo!) with managed LAN environments as well.

So, if you're currently with an MSSP who does not offer managed NAC, then you absolutely should ask them what their plans are for adding NAC to their portfolio, as well as what bundling options they're planning to offer their customers.  Regional MSSP's are moving rapidly in this space, and I think it's only a matter of time before the larger managed service players add NAC to their portfolio as well.

More Musings on MS and Managed

Interop remained all atwitter about MS NAP, and the press articles continue.  Joel Snyder had a webcast on Network World, where MS NAP was the main topic.  We've got a whitepaper up on the same topic, and Alan Shimmel continues to post as well.  There are nits that I could pick with just about everybody (e.g., most recent Cisco gear is perfectly capable of running per port ACL's), but I want to try to stay as high level as possible.  Here are the big-picture things I still see missing from the discussion:

Device Discovery

Whatever governance coverage NAP brings (Greenstein's comments are well taken here), it brings that governance for Vista and XP 3 machines owned and managed by the organization.  That leaves an extremely broad swath of devices, both specialized and general computing, outside the NAP umbrella.  Snyder mentions using MAC based authentication and external device profilers to help; but for many organizations with highly dynamic networking environments, just getting the list of printer MAC addresses (much less badge readers, PDA's, security cameras, the list goes on) is a daunting task.  And having an(other) external tool map and profile devices strikes me as a science experiment run amok.  It seems to me that it is critical to have a built-in device discovery and profiling mechanism.  It goes without saying that the discovery mechanism must also be impervious to host based firewalls, transparent to the physical connection, and indifferent to address assignment.

Post Admission

Just when I thought post admission security was in, they pulled it back out.  What's up with this seriously?  Gartner, Forrester, Frost & Sullivan, Tim Greene over at NWW all seem to agree that NAC encompasses (or at least should encompass) policy enforcement throughout the endpoint's network lifecycle.  The TCG announced a new specification last week aimed specifically at post-admission security.  Yet the bulk of Snyder's talk completely ignores post-admission monitoring and enforcement.  Even the perennial and predictable "blah-blah is dead" post from Stiennon assumes that no NAC solution offers post-admission security beyond the occasional re-scan.  Not so, folks, just not so.  Good post-admission security not only provides flexibility with respect to pre-admission policy, but also provides a means to verify what the endpoint just told you was true.  It's not rocket surgery, for heaven's sakes.  OK, it sort of is, but we're really good at it.

Adaptive Enforcement

Should enforcement be through VLAN placement or ACL assignment?  The truth is that as long as you're in the boat of not being able to change or modify the initial decision it doesn't really matter.  Say an endpoint joins the network and needs remediation.  So it gets put in the remediation VLAN (or has a remediation-specific ACL applied to its port), and gets automagically remediated.  Now what?  How does the endpoint get placed into the "you are now a good endpoint" VLAN (or have the "you are now a good endpoint" ACL applied to its port)?  The answer is that, absent not-so-great methods like CLI or SNMP, the mechanism doesn't exist.

I'm picking (mainly) on NAP here, but really all software/infrastructure based NAC solutions assumed managed assets and are therefore in the same boat.  You have to have some mechanism to discover and profile devices currently on your network; you need the backstop of post-admission security; and you have to be able to change/revoke an endpoint's access as its compliance status changes.  We can argue about a whole litany of things (enforcement methods, device management, policy lifecycle, etc); but none of it is really relevant those three basic needs are met.

Microsoft Takes a NAP on Non-Managed Devices

Since the release of NAP compatible 2008 server ostensibly inaugurated this blog, I thought this week would be good time to revisit the big hairy beast that is Microsoft NAP.  While it's true that our (read: my) primary focus around infrastructure-based NAC is biased towards what the IETF ratifies, we remain NAP partners and continue to follow its progression.  One of the more common RSA questions, from press, analysts, and booth visitors was how we (specifically) and NAC pure plays (generally) compete with Microsoft NAP.  The answer, of course, is that we don't.  And the smart ones won't even try.  Here's why:

First, it's worth exploring what NAP is, what it isn't, and where its focus lies.  While some amount of "NAC is stupid/dead/bad" hay has been made over the number of NAC "Standards" offered, the truth is that CNAC, MS NAP, and TNC don't really differ by all that much.  They all look to leverage the initial authentication event to glean endpoint data characteristics; they all have a model for both granting and gating a level of network access based on the combination of endpoint characteristics and user identity; and they all have a fundamental presumption that the endpoint has the capability and willingness to run the endpoint software to make the declarations.  They presume what's connecting to your network are general purpose computing devices, with general purpose operating systems, managed by you, the IT organization.

Now, what's wrong with that model?  The answer, really, is nothing, so far as it goes.  Governing access to your network for your general-purpose computing assets is definitely a problem for you to solve.  MS NAP, with all of it's tradeoffs, is as likely to solve this problem for you as anything else is.  But controlling access for assets you *don't* own, as well for assets that you own but that are specialized in their function (printers, security cameras, cash registers, HVAC controllers, badge readers, the list goes on) is also a problem for you to solve.  Reasonable people can disagree over what percentage this is, and the percentage likely varies by vertical in any event, but that it is "some number greater than zero" is a slam dunk.

This is really where pure play vendors come in, and why (at least here) we openly welcome the advancements of NAP/TNC/NEA.  I've believed for a while now that you will govern your internally-owned desktops and laptops with something other than us.  Symantec.  McAfee. IBM.  Microsoft.  Juniper.  That's a good list; go to it.  But remember the "courage, serenity and wisdom" prayer?  You not only need a solution that brings governance to the class of non-managed (both unmanaged and unmanageable) devices, but you also need one that has the wisdom to know the difference.  The basic visibility of detecting and classifying what's connecting to your network is a tough thing to make a must have or to wrap ROI around (around which to wrap ROI?  Honestly, some times it's just better to end with a preposition).  But the truth is that discovery and classification do have value, and are critical pieces of any kind of reasonable NAC policy (They may be critical for an unreasonable NAC policy, but I try not to worry with such things).

So, what you get with NAP is governance for the Windows Vista and Windows XP SP3 devices that you own and administer.  What you don't get is governance for anything else.  That's a perfectly fair tradeoff, and a perfectly appropriate thing (I think) for Microsoft to go off and solve.  But what's left?  Why might you want some other (granted, integrated) NAC solution to help?  Here's why:

State:  What's on your network?  The importance of answering this basic question can't be overstated.  At least in all the environments I've ever had to manage, it's a moving target.  Minute by minute, second by second.  Which means that robust, real-time state of all devices is the first step.

Classification:  An extension of the above, this is where you get an additional level of detail about the endpoint, as well as when you split between, say "MS NAP" devices and "Non MS NAP" devices.

Post-Connect Monitoring:  Wheels within wheels.  This not only helps make your network safe by providing another layer (importantly, defined within the same management console, under the same policy construct), but it also gives some flexibility on making the front-end admission decision.  Reasonable people continue to disagree over whether organizations will accept a NAC policy that restricts at entry based on what many consider to be IT failures (firewall, patch, AV status), and Microsoft's own internal NAP deployment called out that tension.  A strong monitoring policy post-connect is the best way to cross that chasm.

Integrated Rollups and Status:  Duh

Enforcement:  Duh. See previous post and don't forget the C.

Ticking Away the Moments

(Errata Notice:  When I read the entries on Steve's blog, my eyes interpreted shanna as "Shanna;" and I incorrectly assumed that someone else at Juniper had posted an entry in Steve's blog.  I've corrected the entry below.  My apologies to Steve and my thanks to Chris Radkowski for pointing out my error.)

So, I've been in a discussion with Steve Hanna over on the Juniper NAC blog about the state of TNC NAC standards within the IETF (Steve's initial post that spurred my comment is here; his response post is here).  Network World's Tim Greene also had a newsletter item on the same topic.  Setting aside that Tim's view is necessarily more pessimistic than Steve's, there is no doubt in my mind that progress on the standards front is a good thing for all NAC vendors.  A rising tide that lifts all boats.  The strong-armed quarterback that completes the West Coast Offense.  The Turn card that completes the flush.  You get the idea.

Steve's initial post was around IETF's acceptance of the TNC client-server protocol definitions.  My follow-on question involved the progress, if any, of standards adoption for the enforcement pieces.  Steve's response was both helpful and encouraging, and I look forward to reading additional details as they come.  I'm not looking to minimize the importance of standardizing client-server communication within a NAC framework. However, we continue to impatiently tap our fingers waiting for a similar level of progress on the enforcement front.  The reasons for this are (a) it's "easier," at least politically, since there is broad agreement as to where enforcement should be done; and (b) enforcement puts the C in NAC, since there can be no control without enforcement.  As is obvious, NAC without the C just becomes NA.  Not an acronym (abbreviation, actually, but that's a whole other rant) that any of us wants.

Now, to be sure, every NAC vendor in the space claims "some" kind of enforcement capability, including Mirage.  And it remains more likely than not that at least some of these enforcement mechanisms remain relevant post standards adoption, for unmanaged assets if nothing else.  After all, whether you're talking about NAP, TNC, NEA or some kind of hybrid, the enforcement elements look pretty much the same, which is to say based around a RADIUS authentication handshake, which holds a two-fold assumption that the asset is (a)managed by the organization and (b) capable of running some kind of host-based software (VPN client, 802.1x supplicant).

Still, for that class of managed assets running host-based software, I don't believe there is significant disagreement that RADIUS extensions are the way to go.  RFC 3580 was great, in that it defined a standard way of providing VLAN assignment and port-based filters to connecting users according to the policy defined on the RADIUS server.  The missing piece is the ability to change those attributes post entry outside the context of an authentication handshake.  This is important not only for post-admission security but also for remediation, since remediation by definition changes the status of the endpoint.  By extending the traditional RADIUS Packet of Disconnect to be a more generic Change of Authorization, RFC 3576 fills this gap, seamlessly, across switching platforms, and for all connection methodologies (wired, wireless, VPN).

So, what's the holdup?  I honestly have no idea.  As Steve points out, RFC 3576 is 5 years old now.  5 years.  5.  Five.  Why hasn't the unknown-pantone-blend switching company (Are they gray?  Blue?  Green?  Pick one!) just gone ahead and implemented it?  It would sell more of their switches.  It would keep them a relevant player in the NAC arena irrespective of whatever else happens (see above).  And it's just the right answer.  My hope is that Juniper (now that they're in the switching business), along with maybe Enterasys, will provide the competitive push that is clearly necessary.  Hope is good.  Hope springs eternal.  Time, I suppose will tell us whether Hope fell down and sprained her ankle.  Let's just please make the time something less than another 5 years.

The ROI of Freedom

As with all things security related, one of the primary challenges for NAC adoption is the proof of some sort of quantifiable ROI model.  While there are some "hard" elements out there (Brand Protection is certainly one; I haven't been in or even met an IT organization yet that wants its company's name in the papers), the real truth is that it's squishier than that.  After all, security is really about peace of mind, about enablement, about freedom.  Where's the ROI in that?  How do you quantify the ROI of playing catch with your kids in the yard instead of fighting yet another malware outbreak (or data breach, or outage, or whatever) at work?  There are likely some productivity gains you can point to, but no job is without its TPS Reports, so even that's a slippery hook on which to hang your hat.

In the end, and at its best, freedom is really what controlling network access should really be about.  It should be about enabling rather than disabling.  It should be about managing the risks of doing business on your network in recognition of the simple fact that your network exists to do your company's business.  It should be about empowering IT organizations to say "How," in recognition of the simple fact that they can't say "No."  We're analogy heavy here at Mirage, and analogies abound within the walls of the company, both for the NAC space generally and for our product specifically (most have to do with either poker or college football but that's a different blog entry).  A common analogy used by me and others has been that NAC (generally) and Mirage (specifically) are essentially the TSA of networks, ensuring safe network travel.

In many ways this fits.  People are going to fly (recent bankruptcies and flight cancellations notwithstanding), and do fly to the tune of some 2 million travelers in the air every day.  Moving that many people through the air has risks, both at a micro and macro level.  You manage the risks as best you can.  You find the best balance that you can between security of travel and doing of business. And that's really as good as it gets.  However, given the average grumbling from the average person in the average security line, no one really wants to associate himself/herself with TSA.  The analogy used at Oasis that I really liked is that we're the guys (er, I mean people) on the skydiving plane checking your chute before you jump.  We're not there to keep you from jumping out of the plane; we're there to see that you do it as safely as is possible.

At RSA, we introduced this notion in a new campaign.  Free your network.  Free your people. Free your business.  Free your world.  Leverage NAC to say How, so that you can quit trying to say No.  Let them jump, knowing that we've checked their chute and they're going to be fine.  Then go home and play with your kids.  Or on the Wii.  Or Dungeons and Dragons.  Whatever it is you do when you're not at work.