The NAC Unbeliever

If you didn’t tune in for the NAC debate between Joel Snyder and Richard Stiennon you should check it out here.  It was a good exchange but Snyder was clearly speaking from stronger ground.  This was one of Stiennon’s comments in the debate (talking about NAC):

Richard_Stiennon: I agree that it is turning into a religion, which makes me an atheist.

I knew he hated apple pie.  I knew it.  Actually, that was just Richard being Richard, but even when discussing the real issues he seemed to be all over the place. Here’s my take on a couple of other nuggets of wisdom he shared in the NAC debate.

Stiennon's historically wrong: 

Richard_Stiennon: “MSBlaster was essentially a zero day [exploit] for most enterprises. If they had had NAC fully deployed they still would have gotten hit.”

The CERT advisory on blaster was issued on August 11, 2003.  The security bulletin and the patch were available on Microsoft's web site on July 16, 2003.  Roughly 30 days.  Nowhere near zero-day.  Indeed this works against Stiennon's other argument about patch and software distribution management solving this problem long ago.  SMS was ubiquitous three years prior to the Blaster outbreak.

Stiennon's philosophically wrong:

phreno: Richard, some NAC products offer behavioral policy enforcement. I can get identity, endpoint checks, and behavioral policy enforcement that stops botnets, DDoS attacks, etc. that do find a way onto the network. What other technology offers that?

Richard_Stiennon: “Great question. This is where the IPS/AV industry is heading. Allow an infected end point to connect, but do not allow it to harm me. Filter out attacks at the edge. The capability you refer to in some "NAC solutions" is what they call post admission control. That is good but the action should be to drop packets, not end point connections.”

13th chime of the clock.  This statement, in itself, is just wrong-headed.  The notion of blocking bad traffic but leaving an otherwise useful connection was folly 5 years ago.  Much less today with, as Richard alludes to earlier in the debate, threats that blend SPAM, bot, keystroke logging and the like.  And we haven't even scratched the surface of malicious users.  What possible good comes from continuing to grant network access to a malicious user?  It is difficult for me to conceive of an answer that could be more wrong, more naive in its arrogance, than "just drop the bad stuff."

Comments

[NYC]

"What possible good comes from continuing to grant network access to a malicious user? It is difficult for me to conceive of an answer that could be more wrong, more naive in its arrogance, than "just drop the bad stuff."

A lot you open your self up to incredibly easy massive scale DOS style attacks by doing nothing more than sending triggering packets from machines on the network.

You have made the incorrect assumption that any 'bad' traffic from a user means all traffic from that user is 'bad'.

Also as to your timeline, CERT release date!=zero day discovery date, in fact it usually isn't even close, even vendors admission of security issue usually is not close to the actual discovery date of the vulnerabilty nor creation of tools to exploit it.

[Grant Hartline]

To NYC:

I'm not sure I get the point of your first paragraph; but the basic thrust of my post was that, irrespective of whether the vector is a malicious user or an infected endpoint, the first step ought to be to isolate the endpoint, remediate the vector and go from there. That was true even for single-purpose threats like Blaster (if you're going to cut off Windows Networking ports, you probably need to let the user know something), but is especially true with today's highly blended threats.

To me, it's wrong headed to phrase the problem around what percentage of the traffic is bad. Rather, it should be about weighing the benefits of allowing network access versus the risk posed by the endpoint. A malicious user, almost by definition, is likely not a productive one; and an infected endpoint is likely doing bad things that may not involve sending traffic at all (keystroke loggers are a good example). Isolate them. Fix them. Then resume normal.

On the Blaster timeline, I'm not arguing that CERT release equals zero day discovery date, rather that CERT release equals roughly the day that the exploit hit the wild on any kind of wide scale. We can always argue over just how efficient or fast CERT advisories are, but I don't think they've ever been off by more than 18 hours or so. In Blaster's case, it was about a month between the time that the MS patch was made available and the time that the exploit hit the wild.