StillSecure, After All These Years

In search of Unicorns

Here at Interop the show floor was pretty dead yesterday.  I had a chance to sit in the audience on a panel on NAC hosted by Mike Fratto.  Mike had 5 panelists including a few friends of mine. It was pretty much the usual NAC panel.  Steve Hanna from Juniper/TNC touting the standards that his group offers, Cisco saying they will support standards, HP ProCurve always loves standards, Microsoft actually being very pragmatic and then there was JJ.  My friend Jennifer Jabbusch was her usual self talking as she sees it and giving quote fodder to the journalists like Michael Sean Kerner who wrote about the panel in this article.

Of course the media loves to jump on any angle as to why NAC has not brought world peace and helped cure cancer.  So Kerner’s article screams that authentication is where we screwed up.  He says the audience demanded to know when NAC is going to deliver on the promise. How can we have a standard without Cisco. Well I was in the audience too and had all I could to bite my tongue and not say anything.  But hey that is why I have a blog. So let me respond here:

1. Authentication is where we screwed up.  Who said NAC was about authentication?  Listening yesterday you would think that 802.1x authentication was a direct result of NAC needing a secure authentication process.  Guys lets not put the cart in front of the horse.  802.1x offers a lot of other features and advantages besides NAC authentication. In fact it is the other way around.  NAC vendors adopted 802.1x because it offered some distinct advantages.  It was widespread in wireless networks.  However, JJ is right.  It is complex. There are a lot of moving parts. If you have not done everything right to implement 802.1x on your network, don’t bother trying  to use it for NAC.  But if you had, it does work like a charm. As I have said  before it is not for the faint of heart.

But back to my original comment.  Originally NAC/NAP was not the authentication.  NAC rode on top of your existing authentication. We as an industry have issues around easy to use, robust authentication methods.  So this became NAC’s problem?  A good NAC solution should be able to use the authentication system you are using.  Authentication sucks?  Look to the folks developing authentication.  Hint: it is the same network vendors sitting on the panel.  But lets not saddle NAC with albatross.

2. Searching for the mythical NAC Unicorn. Fact is there was one member in the audience who was quite vocal (no not me) and kept insisting that NAC would not be real until everyone adopted one standard, that no matter what network we log into, no matter what different software I had, NAC would solve it all because “a big database” would contain all of this information. Yeah, all right.  I wanted to ask the guy if he still leave out cookies and milk for Santa Claus.  From what I understand this particular individual makes a habit of doing this at NAC panels.

The guy from Microsoft said it best. It is OK if NAC does not give you all of this, it is still valuable.  Stop trying to make it all things to everyone and take it for what it is. It is not the answer to authentication, it is near impossible to treat heterogeneous network environments like they were homogenous, but that is  not what it is about.  Stop looking for Unicorns and make use of what you have to work with!

A NAC in hand is worth two in the bush

Mike Fratto, fresh off hosting the NAC festivities at NY Interop (wanted to make it up there but had to go to St Louis instead) has an interesting article up called "Beating the NAC Standards Bush".  Mike relates his experience hosting a panel of paid sponsors for NAC day.  Like other fairy tales, this story has three characters, one was Cisco (too big), one was Sophos (too small) and one was Symantec (just right). The discussion on the panel, as invariably happens at Interop got around to NAC standards.  Of course Cisco is Cisco and is working with IETF.  So what if it moves on geological time frames. Symantec and I guess Sophos are part of the TCG/TNC (as is StillSecure, in the spirit of full disclosure). 

It seems some people gave Rich Langston of Symantec a tough time because the TCG is a "closed" group, as opposed to the IETF.  Rich responds that the closed group allows them to move forward faster and more efficiently.  At the end of the day, Mike says customers want "a standard" to come to the forefront and don't care much which one it is, as long as it is one.  He  seems to be partial to the TCG.

My view as in the title, is it is more important today to get a NAC product that works.  People are tired of the alphabet soup of NAC standards.  Though Symantec and 45+ others are members of the TCG, the perception is that it is still the Juniper standard. 

Yes, it would be nice to have a dominant standard and I hope it is the TCG standard too.  But Mike is right on with his last sentence in the article.  Only when customers are truly making decisions based upon these standards will NAC vendors fully support them.

NAC day at Interop NY with Mike Fratto

Just wanted to make sure you were all aware of NAC day at Interop NY this year, which is Sept 16th (next Tuesday).  Joel Snyder usually runs Interop NAC events and does a great job. However it seems Joel had a scheduling conflict this year.  The show organizers went to the bullpen and have none other than Mike Fratto as master of ceremonies.  Mike I am sure will do a great job.  You can read more about  what Mike says about it here.

In addition to Mike you can hear from some NAC vendors, primarily Microsoft, Cisco and Juniper.  The reason being that they are the only ones to pony up the 30k or so it takes to get on the panel for NAC day.  Realize that though educational, the Interop folks charge vendors an arm and leg to educate you.  My only beef is that if Interop wanted to really educate you on NAC they would have NAC experts who did not "pay to play".  Shame on them for not making it clear that these companies have paid that kind of money to be called NAC experts!

Not 'who you gonna run to" but "who you gonna call"?

You could try ghostbusters, but don't bother calling the PCI council. So says Mike Fratto and Martin McKeay in response to my earlier article about when you have an obligation to go public. Of course I was responding to Martin's earlier post on the TJX employee getting fired. What all three of us agreed on though is that there is no place or person that an employee or any other person frankly can call to report a company that is not in compliance with the PCI.

Mike Fratto says "PCI has no teeth because VISA/Mastercard doesn't want to bite the hands that feed it." Martin says the PCI council has established a way for people to report violations because "that’d make the Council responsible for acting on those reports. And that’s something they really, really don’t want." So are the PCI regs toothless. I wouldn't exactly go that far. I think we have to draw a distinction about having the power to act versus actually exercising that power. Mike is right, so far the PCI council has to exercised the powers they were granted to impose sanctions and penalties. That doesn't mean they won't in the future though. I think they will have to make some "examples" otherwise people are going to begin to ignore the requirements all together.

Without some process to report violations the credit card companies are inviting the government to step in. This is exactly the reason as Mike Fratto points out that they imposed the PCI regs to begin with, that is to keep the government out. Until they do though, I think going public and the court of public opinion may be the only recourse.

Is NAC clawing its way up the "slope of enlightenment"?

Its no secret that over the past year it has been quite fashionable to bash NAC.  It has not lived up to the hype.  It is not the promised silver bullet.  Some companies in the market went belly up.  Yes, yes and true.  But as I have said all along this was I think just the natural evolution of a technology as it matures.  There was no way it could live up to the over hype that it was saddled with.  Those who spoke about it realistically always said it was not the next "great white hope" of security, just another arrow in the quiver. However, the reason that people got excited about NAC was that at a rather simple level it was very easy to describe the problem it was trying to solve.  As it turns out, solving that simple problem takes a rather complex solution, no matter how you slice it.

In the end though what we have seen in the NAC market is textbook hype cycle.  The technology triggers for NAC were unseen before numbers of guests having legitimate reasons to access the network.  The spread of malware not through downloading via the Internet, but by introduction via devices logging on and the need for compliance or otherwise to enforce access policies with the network technologies to make it happen.  With Cisco announcing their Network Admission Control program in December, 2003 and Microsoft announcing NAP that summer (interesting that it would be years before either one was actually available) NAC buzz went through a big bang expansion to the very height of inflated expectations. What goes up, must come down and NAC certainly has been dragged into the trough of disillusionment. However, the inherent appeal of the problems it can solve continue to drive customers and interest.  Now we are seeing real signs of NAC emerging into the slope of enlightenment on the way to the plateau of productivity.

What has got me so optimistic?  It is a variety of things.  Let me list them:

1. Network Computing's 3rd annual NAC survey which while it shows demand is down for NAC from past years, it is still substantial and appears to be deeper if not as wide. It also has several other metrics that show people are being more realistic in what they want to accomplish with NAC and have more confidence that it will work.

2. Forrester's new report that shows that customers think NAC is mature enough to be ready for more wide scale deployments. Remember this is the same Forrester who said that NAC as we know it would fail last year. Has NAC changed so much in a year or has Forrester?

3. That Ebenezer Scrooge of NAC, Mike Rothman, actually admits that maybe we are seeing some progress with less inflated expectations with NAC. What could be next, the NAC Grinch, Richard Stiennon admitting it might be OK as well. Here is my prediction: When Rich's new MSSP can make money offering a managed NAC service, Richard will jump on the NAC bandwagon with bells on.

4. My own observations at Interop, RSA, SANS and other events where I spoke to real live potential customers.  I have personally seen a marked upturn in the amount of real NAC projects that we see coming into both our partners and our sales pipelines. I assume that other NAC products are seeing the same pick up.

All of this is very gratifying to see after the bashing NAC has taken.  Now it is onwards and upwards to the plateau of productivity.   See you there!

A rose by any other name

So whats wrong with having it both ways?

People have been telling me that I want my cake and eat it too since I was a little boy, starting with my Mom.  So I take no offense at all when Mike Fratto accuses me of trying to have it both ways when it comes to host assessment in NAC. Hey Mike whats the matter with playing both sides of the aisle? Maybe I should throw my hat into the presidential race?  Seriously, I think Mike may have misconstrued what I was saying in talking about vendors like LANDesk who say they are NAC players versus what I have said about the importance of host assessment being a central piece of the NAC formula.

Let me be really clear here. I think you can't have NAC without host assessment. That is the starting point for NAC as far as I am concerned.  However, I don't think it is the ending point. i think the NAC vendors who will survive in the future will do more than admission control.  They will perform access control.  There are elements of behavior analysis and monitoring involved, as well as identity based access control involved, among other things.  On the other hands vendors who seek to provide "checkbox" NAC by using their on board agents to check configuration, ala LANDesk or Big Fix for that matter, are missing the boat here.  Customers want their NAC solutions to do very different things than their configuration managers.  Lets not even use the G spot.  Yes, thats right guests.  Almost by definition, these host based NAC "products" (and I use that term loosely) have a huge blind spot regarding guests.  With guest access such an important piece of the NAC equation, how can you have a NAC solution without a guest solution.

But Mike don't shoot the messenger here.  I think the words from the fellow from LANDesk are what sinks him. He says NAC vendors who are "strategically centered around NAC" will fail. So does he tell his customer that they don't consider NAC strategic to LANDesk but they will provide them NAC?  No that sounds like a winning sales pitch if I ever heard one.  The fact that we never see LANDesk in any NAC deals is also a clear indication to me of how the NAC buying public views their feature as well.

When it comes to NAC, he who laughs last, will laugh best.

The herd approach to security disturbs some folks

It seems my article the other day commenting on Matt Hines article on Andy Jaquith's report on security companies relying on "the safety in numbers" approach to security to protect the herd as a whole has invoked some feelings strong enough for people to comment. Currently there are three comments which I want to highlight.  The first is from Mike Fratto.  The Syracuse whiz I think agrees with me that this type of approach is pragmatic and ultimately delivers more results and protection than all of the so-called zero day protection that we have heard so much about.  Mike calls it dead on when he says bad guys make malware, good guys then have to find it and protect against it.  That is the way it is and the way it will always be.

Next is the middle approach from Shawn.  Shawn agrees that this is a logical first step, but sees the risk to the individual as a member of the herd. Can we truly trust the herd to protect us?  Do the ones keeping the herd have our best interests at heart? Is giving up some of our privacy and individuality worth the protection we potentially get?  All good questions by Shawn.  Whether we are talking about security or any other threat to a group, I think these are the questions that the herd mentality raises.  I think nature has already answered these questions and by by its frequent use of the herd behavior the answer is that it is worth the sacrifice and the risk for the greater common good.

Last and I think most disturbing to me is Mitchell's reaction.  I don't know, maybe since Mitchell left StillSecure he has been drinking heuristic Kool Aid.  Mitchell, I think says that the bad guys will always be faster in this "flawed model of security".  However, what I think Mitchell misses is that the bad guys are always faster anyway.  The security industry is always re-active to the bad guy almost by definition.  So why do Mitchell and those who agree with his view feel this way?

I think that in their quest to "win the war" on security they think they will move from reactive to proactive.  That they will outsmart the bad guys and be able to anticipate the next bad guy move.  They want to think they can win.  I think it is in what you define as winning.  I don't think we ever are faster than the bad guys or act before they do. I think a much more pragmatic approach is to do what we can to harden our systems against attack and mitigate the risk of attack, but assume a new type of attack can succeed because we just cannot anticipate everything the bad guys do.  Therefore in an analysis of the greater good, a pragmatic approach that leverages a "neighborhood watch" as Mitchell calls it offers real world, real protection, rather than pie in the sky, wishful thinking about out thinking the bad guys.

Waiting for TCG/TNC

In the play Waiting for Godot by Samuel Beckett, the characters wait throughout the entire play for the appearance of Godot, who never arrives. Godot's failure to arrive has led to much speculation and interpretation over the years. In much the same way, the ability of the TCG/TNC to capture the NAC buying publics attention has led to much speculation and interpretation over the past 2 to 3 years.  Mike Fratto in writing about the new blog of the TCG, has laid out one of the most insightful analysis for the lack of adoption of the TCG/TNC that I have seen.

Mike points out that Network Computing's own research, in line with other research, indicates that only a minority of potential buyers of NAC technology are aware of the TCG/TNC standards and even fewer actually have a grasp of the technology.  Mike rightfully calls TCG/TNC a group, "for vendors, by vendors". Mike lays bare the soft white underbelly of the situation, in that most TCG/TNC members are not active in the working groups and have taken a wait and see approach regarding the TNC spec.  Mike again nails it when he points out that until customers demand TCG specs, vendors won't provide it. 

Ultimately Mike says vendors are looking to get out from under in providing their own agent for NAC.  The TCG/Microsoft NAP partnership gives vendors hope that this could happen.  Mike wraps it up in a nice circle, "1) Vendors build it when there is customer demand. 2) Customers demand when they trust the technology is good. 3) The first step to trusting the technology is good is knowledge about the standards and the future directions."

While Mike is not wrong, let me put a little vendor perspective in here.  Here at StillSecure, we are TCG members and are committed to supporting the TNC spec.  We have been members for a number of years and frankly like Mike says have been waiting for the TNC standards to mature and gain some market acceptance. Though we were committed to supporting it, it never made it to the top of the priority list when we were adding new functionality to Safe Access.  Frankly, up until the Microsoft announcement, it was starting to look doubtful that the TNC would be anything more than Juniper's effort to combat Cisco's and Microsoft's own NAC frameworks.  However, that did change with the NAP/TNC interoperability and StillSecure like many NAC vendors have been hard at work on developing our support for both of these specs in our product.

It is not necessarily the lure of getting out from under our own agent though that drives this as Mike thinks.  For us the real appeal of the TCG/TNC standard is that it is a true open standard that is not dictated by one tech hegemony or another. Especially ones that have driven countless other tech companies out of business over the years. Do we as NAC vendors trust our future to Cisco, Microsoft or a consortium of many NAC vendors?  If you picked Microsoft or Cisco, you guessed wrong.  However, if you are an end user, trusting the spec to Cisco or Microsoft may not be a bad idea.  Especially if you are not jittery about one vendor who already probably controls much of your technology, controlling one more aspect of it.  But if you value diversity and true open standards based on market economics, a real consortium such as the TCG has to be your choice.

Yes, Cisco and Microsoft will point to all of the companies that are partners in their own respective specs, but lets face it, those are people hedging their bets.  The thought of having to dance to the Cisco/Microsoft beat is frightening to many tech companies, but they don't have a choice.

Another reason to support the TCG is that the world is not made up of just Cisco and Microsoft networks (close but not entirely). If your network has gear other than Cisco gear, if you run another OS that doesn't start with the letter W, than being able to have your diverse gear play nicely with each other from a NAC prospective is what the TCG offers. This cross-vendor interoperability and multi-vendor standardization is the attraction of the TCG to end user customers.

Ultimately it is the lure of diversity and true open standards that draws vendors to the TCG.  However like in the play, unless customers also recognize the importance of supporting this independent standard which will give them the greatest choice going forward, TCG/TNC vendors are destined to wait under a tree for something or someone that never comes.  Lets hope NAC customers who demand TCG compliance are not like Godot.

Fratto says - Open source? Bah humbug!

With Mike Fratto working at Syracuse University, I never figured him for an open source foe.  But in the middle of this holiday season Mike has done his best Scrooge imitation and smacked down not just open source NAC, but open source in general. Mike started out by taking a shot at David Davis's TechRepublic article that touted open source NAC alternatives. I had read the same article but was too busy to write up my own critique of it. I thought Davis had some things wrong in the article and didn't really understand NAC.  Mike jumps all over him for it and rightfully so.

Open source NAC has been around for a while and I know of several universities that have given FreeNAC and PacketFence a whirl. I have also heard of several schools who have developed their own home grown NAC programs.  Mike is dead on, neither we nor any other commercial NAC vendor is losing much sleep over these solutions at this time. NAC is a complicated process and these open source tools usually can't do the AtoZ that customers want and require.

However, Mike goes beyond just calling out open source NAC for what it is and makes a pretty broad indictment against a lot of open source software in general.  Here are the final two paragraphs from Mike's article:

You shouldn’t have any expectation that the open source community will help you solve your problems. You can't really cajole a volunteer to spend time on your problem on your schedule. There's nothing binding them to you other than their goodwill. If you don't like this open source project and go find another one, fine, what impact do you have on the project? None. It's not like you're taking money out of their pockets or food off
their table.

When you accept an open source application without a commercial support contract, you accept the full burden support for the application. If you have the staff in-house that you can train and can dedicate to the application, then you are in good shape (and you should, of course, give back to the project). If you don't have the people with the necessary skills, avoid open source.

Ouch! Come on Mike, it is not that bad. Where is your holiday spirit after all? I hope that the ghosts of NAC past, present and future don't visit you one night soon.  Until then a happy holiday to all and to all a good night.