StillSecure, After All These Years

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

Mike Fratto had an interesting blog up today about Steve Hanna having submitted in essence the TCG/TNC specifications to the NEA working group for consideration as working group documents.  According to Mike these were the only documents submitted.  This actually came as no surprise to me. I have felt for a long time that Cisco was not into leading the effort to blaze their own trail regarding NAC standards any more. They were just looking for a face saving way of going along with the TNC spec without looking like they caved in and crawled to Juniper and some of the other Cisco competitors in the TCG.  The NEA group is the perfect foil to call these standards by another name, but they remain the same. Frankly once Microsoft and the TCG joined forces, the writing was on the wall for Cisco.  Also, the fact that so many of Cisco's NAC customers use the NAC appliance and not the NAC framework, means that frankly the whole standards thing just didn't have the same aroma it used to.  The good news is that NAC customers and vendors (and not just NAC appliances, but everyone involved in the NAC ecosystem) can now all rally around one standard and build NAC systems that work.

Of course Fratto brings up "Grumpy" Rothman's incite about another down year for NAC.  Mike prides himself on predicting the obvious that NAC would not live up to its hype last year.  For this year he sees NAC moving into the network (NS, Sherlock). Mike finishes up with his who gives a hoot about standards spiel.  I think on that score, Fratto sets Mike straight and I will defer to Mike F.

Also to note Mike Rothman refers to another crystal ball blog article, this one by Thomas and Nate over at Matasano. With my history of mixing it up with Thomas, I don't want to come off as sour grapes on Thomas's outlook for NAC.  But I think in a classic case of when you are a hammer, everything looks like a nail , Thomas looks at NAC from the point of view of the kind of research he does.  The fact is what most customers want their NAC to do is not anywhere near what Thomas is talking about or the kind of things he researches. I also am not sure he is up on all of the different technologies used in NAC because you certainly don't need "100 crappy 1U security boxes" to do NAC across the enterprise.  I do think Nate has a better handle on it, with NAC becoming a feature on switches and in endpoint agents.

Frankly, I am always baffled by these predictions on NAC. I always wonder why they are not talking to our customers.  I find it hard to believe that I or the rest of us at StillSecure were that smart.  We have recognized from the beginning that working with network vendors was going to be key in the NAC market.  So we have forged OEM and partner relationships with most of the switch vendors out there. We have tried hard to allow NAC to leverage existing investments in security.  I think most of the customers and people looking at NAC see the value in it.  No, it is not the silver bullet (and maybe that great white hope tag is what is dragging down perceptions by some) but it is a great tool for security and compliance for most companies.  I know we are not alone among NAC vendors seeing this either.  Yes there was a lot of snake oil out there, but I think the shake out is  by real players staying and the BS walking.

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.