Rational Survivability

Shimel's in Der Himmel & Stiennon's A Mean-Un...NAC Dust-Up Part Deux.

Nothing to see here folks.  Move along...

This is like a bad episode of "Groundhog Day" meets "Back To the Future." 

You know, when you wake every day to the same daymare where one person's touting that features like NAC are the next flux capacitor while another compares its utility to that of sandpaper in the toilet roll dispensers in a truck stop restroom? 

I know Internet blog debates like this get me more excited than having my nipples connected to jumper cables and being waterboarded whilst simultaneously shocked with 1.21 Jigawatts...

Alan Shimel's post ("Stiennon says NAC is dead - I must be in heaven!") in response to Stiennon's entry ("Don't even bother investing in Network Admission Control") is hysterical.

Why?

Because it's the exact arguments (here and here) they had back in August 2007 when I refereed (see below) the squabble the first time around and demonstrated convincingly how they were both right and both wrong.  The silly little squabble -- like most things -- is all a matter of perspective.

I'd suggest that if you want a quick summary of the arguments without having to play blog pong, you can just read my summary from last year, as none of their arguments have changed.

/Hoff

P.S. The German word "himmel" translates to "heaven" (and sky) in English...funny given Shimmy's post title, methinks...

Client Virtualization and NAC: The Fratto Strikes Back...

Attention NAC vendors who continue to barrage me via email/blog postings claiming I don't understand NAC:  You're missing the point of this post which basically confirms my point; you're not paying attention and are being myopic.I included NAC with IPS in (the original) post here to illustrate two things:

(1) Current NAC solutions aren't particularly relevant when you have centralized and virtualized client infrastructure and

(2) If you understand the issues with offline VM's in the server world and what it means to compliance and admission control on spin-up or when VMotioned, you could add a lot of value by adapting your products (if you're software based) to do offline VM conformance/remediation and help prevent VM sprawl and inadvertent non-compliant VM spin-up...

But you go ahead and continue with your strategy...you're doing swell so far convincing the market of your relevance.

Now back to our regular programming...

-- ORIGINAL POST --

I sense a disturbance in the force...

Mike Fratto's blog over at the NWC NAC Immersion Center doesn't provide a method of commenting, so I thought I'd respond to his post here regarding my latest rant on how virtualization will ultimately and profoundly impact the IPS and NAC appliance markets titled "How the hypervisor is death by a thousand cuts to the network IPS/NAC appliance vendors."

I think Mike took a bit of a left turn when analyzing my comments because he missed my point.  Assuming I'm wrong, I'll respond the best I can.

A couple of things really stood out in Mike's comments and I'm going to address them in reverse order.  I think most of Mike's comments strike an odd chord to me because my post was about what is going to happen to the IPS/NAC markets given virtualization's impact and not necessarily what these products look like today.

Even though the focus of my post was not client virtualization, let's take this one first:

Maybe I am missing something, but client virtualization just doesn’t seem to be in the cards today. Even if I am wrong, and I very well could be, I don’t think mixing client VM’s with server VM in the same hypervisor would be a good idea if for no other reason than the fact that a client VM could take down the hypervisor or suck up resources.

I don't say this to be disrespectful, but it doesn't appear like Mike understands how virtualization technology works.  I can't understand what he means when he speaks of "...mixing client VM's with server VM in the same hypervisor."  VM's sit atop of the hypervisor, not *in* it.   Perhaps he's suggesting that despite isolation and the entire operating premise of virtualization that it's a bad idea to have a virtualized client instance colocated in the same physical host as a VM next to a VM running a server instance?  Why?

Further, beyond theoretical hand wringing, I'd very much like to see a demo today of how a "...client VM could take down the hypervisor."

I won't argue that client virtualization is still not as popular as server virtualization today, but according to folks like Gartner, it's on the uptake, especially when it goes toward dealing with endpoint management and the consumerization of IT.  With entire product lines from folks like Citrix (Desktop Server, Presentation Server products, XenDesktop) and VMware (VDI) it's sort of a hard bite to swallow.

This is exactly the topic of my post here (Thin Clients: Does this laptop make my assets look fat?), underscored with a quick example by Thomas Bittman from Gartner:

Virtualization on the PC has even more potential than server virtualization to improve the management of IT infrastructure, according to Mr Bittman.“Virtualization on the client is perhaps two years behind, but it is going to be much bigger. On the PC, it is about isolation and creating a managed environment that the user can’t touch. This will help change the paradigm of desktop computer management in organizations. It will make the trend towards employee-owned notebooks more manageable, flexible and secure.”

Today, I totally get that NAC is about edge deployment (access layer,) keeping the inadvertent client polluter from bringing something nasty onto the network, making sure endpoints are compliant to network policy, and in some cases, controlling access to network resources:

NAC is, by definition, targeting hosts at the edge. The idea is to keep control access of untrusted or untrustworthy hosts to the network based on some number of conditions like authentication, host configuration, software, patch level, activity, etc. NAC is client facing regardless of whether you’re controlling access at the client edge or the data center edge.

I understand that today's version of NAC isn't about servers, but the distinction between clients and servers blurs heavily due to virtualization and NAC -- much like IPS -- is going to have to change to address this.  In fact, some might argue it already has.  Further, some of the functionality being discussed when using the TPM is very much NAC-like.  Remember, given the dynamic nature of VMs (and technology like VMotion) the reality is that a VM could turn up anywhere on a network.  In fact, I can run (I do today, actually) a Windows "server" in a VM on my laptop:

You could deploy NAC to access by servers to the network, but I don’t think that is a particularly useful or effective strategy mainly because I would hope that your servers are better maintained and better managed than desktops. Certainly, you aren’t going to have arbitrary users accessing the server desktop and installing software, launching applications, etc. The main threat to server is if they come under the control of an attacker so you really need to make sure your apps and app servers are hardened.

Within a virtualized environment (client and server) you won't need a bunch of physical appliances or "NAC switches," as this functionality will be provided by a virtual appliance within a host or as a function of the trusted security subsystem embedded within the virtualization provider's platform.

I think it's a natural by-product of the productization of what we see as NAC platforms today, anyhow.  Most of the NAC solutions today used to be IPS products yesterday.  That's why I grouped them together in this example.

This next paragraph almost makes my point entirely:

Client virtualization is better served with products like Citrix MetaFrame or Microsoft’s Terminal Services where the desktop configuration is dictated and controlled by IT and thus doesn’t t suffer from the same problems that physical desktop do. Namely, in a centrally managed remote client situation, the administrator can more easily and effectively control the actions of a user and their interactions on the remote desktop. Drivers that are being pushed by NAC vendors and analysts, as well as responses to our own reader polls, relating the host condition like patch level, running applications, configuration, etc are more easily managed and should lead to a more controlled environment.

Exactly!  Despite perhaps his choice of products, if the client environment is centralized and virtualized, why would I need NAC (as it exists today) in this environment!?  I wouldn't.  That was the point of the post!

Perhaps I did a crappy job of explaining my point, or maybe if I hadn't included NAC alongside IPS, Mike wouldn't have made that left turn, but I maintain that IPS and NAC both face major changes in having to deal with the impact virtualization will bring.

/Hoff

 

UPDATED: How the Hypervisor is Death By a Thousand Cuts to the Network IPS/NAC Appliance Vendors

Attention NAC vendors who continue to barrage me via email/blog postings claiming I don't understand NAC:  You're missing the point of this post which basically confirms my point; you're not paying attention and are being myopic.

I included NAC with IPS in this post to illustrate two things:

(1) Current NAC solutions aren't particularly relevant when you have centralized and virtualized client infrastructure and

(2) If you understand the issues with offline VM's in the server world and what it means to compliance and admission control on spin-up or when VMotioned, you could add a lot of value by adapting your products (if you're software based) to do offline VM conformance/remediation and help prevent VM sprawl and inadvertent non-compliant VM spin-up...

But you go ahead and continue with your strategy...you're doing swell so far convincing the market of your relevance.

Now back to our regular programming...

-- ORIGINAL POST --

From the "Out Of the Loop" Department...

Virtualization is causing IPS and NAC appliance vendors some real pain in the strategic planning department.  I've spoken to several product managers of IPS and NAC companies that are having to make some really tough bets regarding just what to do about the impact virtualization is having on their business.

They hmm and haw initially about how it's not really an issue, but 2 beers later, we're speaking the same language...

Trying to align architecture, technology and roadmaps to the emerging tidal wave of consolidation that virtualization brings can be really hard.  It's hard to differentiate where the host starts and the network ends...

In reality, firewall vendors are in exactly the same spot.  Check out this Network World article titled "Options seen lacking in firewall virtual server protection."  In today's world, it's almost impossible to distinguish a "firewall" from an "IPS" from a "NAC" device to a new-fangled "highly adaptive access control" solution (thanks, Vernier Autonomic Networks...)

It's especially hard for vendors whose IPS/NAC software is tied to specialty hardware, unless of course all you care about is enforcing at the "edge" -- wherever that is, and that's the point.  The demarcation of those security domain diameters has now shrunk.  Significantly, and not just for servers, either.  With the resurgence of thin clients and new VDI initiatives, where exactly is the client/server boundary?

Prior to virtualization, network-based IPS/NAC vendors would pick arterial network junctions and either use a tap/SPAN port in an out-of-band deployment or slap a box inline between the "trusted" and "untrusted" sides of the links and that was that.  You'd be able to protect assets based on port, VLAN or IP address.

You obviously only see what traverses those pipes.  If you look at the problem I described here back in August of last year, where much of the communication takes place as intra-VM sessions on the same physical host that never actually touch the externally "physical" network, you've lost precious visibility for detection let alone prevention.

I think by now everyone recognizes how server virtualization impacts network and security architecture and basically provides four methods (potentially in combination) today for deploying security solutions:

1. Keep all your host based protections intact and continue to circle the wagons around the now virtualized endpoint by installing software in the actual VMs
2. When available, take a security solution provider's virtual appliance version of their product (if they have one) and install in on a host as a VM and configure the virtual networking within the vSwitch to provide the appropriate connectivity.
3. Continue to deploy physical appliances between the hosts and the network
4. Utilize a combination of host-based software and physical IPS/NAC hardware to provide off-load "switched" or "cut-through" policy enforcement between the two.

Each of these options has its pros and cons for both the vendor and the customer; trade-offs in manageability, cost, performance, coverage, scalability and resilience can be ugly.  Those that have both endpoint and network-based solutions are in a far more flexible place than those that do not.

Many vendors who have only physical appliance offerings are basically stuck adding 10Gb/s Ethernet connections to their boxes as they wait impatiently for options 5, 6 and 7 so they can "plug back in":

5.  Virtualization vendors will natively embed more security functionality within the hypervisor and continue integrating with trusted platform models

6.  Virtualization vendors will allow third parties to substitute their own vSwitches as a function of the hypervisor

7. Virtualization vendors will allow security vendors to utilize a "plug-in" methodology and interact directly with the VMM via API

These options would allow both endpoint software installed in the virtual machines as well as external devices to interact directly with the hypervisor with full purview of inter and intra-VM flows and not merely exist as a "bolted-on" function that lacks visibility and best-of-breed functionality.

While we're on the topic of adding 10Gb/s connectivity, it's important to note that having 10Gb/s appliances isn't always about how many Gb/s of IPS traffic you can handle, but also about consolidating what would otherwise be potentially dozens of trunked LACP 1Gb/s Ethernet and FC connections pouring out of each host to manage both the aggregate bandwidth but also the issues driven by a segmented network.

So to get the coverage across a segmented network today, vendors are shipping their appliances with tons of ports -- not necessarily because they want to replace access switches, but rather to enable coverage and penetration.

On the other hand, most of the pure-play software vendors today who say they are "virtualization enabled" really mean that their product installs as a virtual appliance on a VM on a host.  The exposure these solutions have to traffic is entirely dependent upon how the vSwitches are configured.

...and it's going to get even more hairy as the battle for the architecture of the DatacenterOS also rages.  The uptake of 10Gb/s Ethernet is also contributing to the mix as we see customers:

• Upgrading from servers to blades
• Moving from hosts and switches to clusters and fabrics
• Evolving from hardware/software affinity to gird/utility computing
• Transitioning from infrastructure to service layers in “the cloud”

Have you asked your IPS and NAC vendors who are hardware-bound how they plan to deal with this Tsunami on their roadmaps within the next 12 months.  If not, grab a lifejacket.

/Hoff

UPDATE:  It appears nobody uses trackbacks anymore, so I'm resorting to activity logs, Google alerts and stubbornness to tell when someone's referencing my posts.  Here are some interesting references to this post:

• Mike Fratto - NWC NAC and Virtualization Immersion Center
• Dana Hendrickson - SecureAccessCentral

...also, this is right on the money:

• Chris Silva - Forrester

I think I'll respond to them on my blog with a comment on theirs pointing back over...

BrokeNAC Mountain - "I wish I knew how to quit you."

An entire day and forum dedicated to NAC in the NYC?  Huh.  I thought we did that at InterOp and RSA already!?  I suppose it's necessary to wade through all the, uh, information surrounding the second coming of network security.

If someone builds one for UTM, I will kill myself.   

Oh NAC...I wish I knew how to quit you!

(I was going to photoshop the poster to the left including Alan Shimel and changing the title to BrokeNAC Mountain, but I can't find my Photoshop CD and I've got a plane to catch to Milan...)

I've made it clear that I think NAC (Network Admission Control and Network Access Control) is valuable and worth investing in as part of a layered defense.  It ain't the silver bullet of security, however.  Maybe Stiennon can come up with a new name for it and it will be?

I've also made it clear that despite the biggest amount of hype since the Furby, NAC will become a feature as part of a conglomeration of solutions in the short term (24 months); it already is a replacement blanket marketing term for companies that used to be SSL VPN's that then became IPS's that are now NAC.  Look at the companies that now claim they're NAC-focused.  That's usually because the "market" they were in previously collapsed -- just like NAC will.

It seems that NAC's relationship with the world plays out just like a scene from Brokeback Mountain where the two main characters discuss whether the public sees through the thin facade of the uneasy relationship they project to the world -- just like the front NAC puts on:

Ennis Del Mar: You ever get the feelin'... I don't know, er... when you're in town and someone looks at you all suspicious, like he knows? And then you go out on the pavement and everyone looks like they know too?
Jack Twist: [Casually] Well... maybe you oughta get out of there, you know? Find yourself someplace different. Maybe Texas.
Ennis Del Mar: [Sarcastically] Texas? Sure, maybe you can convince Alma to let you and Lureen to adopt the girls. And we can just live together herding sheep. And it'll rain money from LD Newsome and whiskey'll flow in the streams - Jack, that's real smart.
Jack Twist: Go to hell, Ennis. If you wanna live your miserable fuckin' life, then go right ahead.
Ennis Del Mar: Fine.
Jack Twist: I was just thinkin' out loud.
Ennis Del Mar: Yep, you're a real thinker there. Goddamn. Jack fuckin' Twist; got it all figured out, ain't ya?

If the next NAC Forum is held in Texas, you'll know the end of the world is near...'course there ain't nuthin' wrong with the heavens rainin' money and streams full-a whiskey...

At any rate, I was catching up on my back-dated blog entries and just read Dom Wilde's (Nevis Networks  Illuminiations Blog) summary of the Network Computing NAC 2007 Forum and couldn't help but chuckle.  Shimel's review seemed a little more upbeat compared to Dom's, but since Alan got stalked by a blogger paparazzi in a three-wheeled, pedal-powered rickshaw, I can see why.

Snippet Summary from Dom's Post:

It's little wonder that people are confused about NAC.  Too many times during the day I found myself with a furrowed brow trying delineate between reality and fiction...Disappointing moment of the day - 7 panelists on the OOB panel frying the audience's collective brain, by taking 10 minutes each to say "me too".  Result: half the audience didn't return after lunch for more lively and concise discussions on in-line and framework based solutions, and more critically, to hear narratives and lessons learned from people who have deployed NAC.

Snippet Summary from Alan's Post:

Anyway, it was a great way for people looking at deploying NAC to come up and touch and feed a real live NAC vendor. Ultimately, you still have to install the product and play with it yourself to see if it works.  There were lots of claims and NAC crap flying today.  I also would like to see more of a panel of answering questions then just giving our elevator pitch powerpoints to the crowd.  Still a worthwhile day and a good job by Network Computing. I think all of the elevator pitches will be posted on NC site soon.

Sounds great.

Both Dom and Alan's companies provide NAC solutions.  Both were at the show.  Both seem to convey the sense that this was more circus than it was scholarly.  I'm not sure that's because it was focused on NAC or because in general most conferences/forums are completely useless, but I'm interested in anyone else's opinion from those what where there.

/Hoff

Really, There's More to Security than Admission/Access Control...

Dr. Joseph Tardo over at the Nevis Networks Illuminations blog composed a reasonably well-balanced commentary regarding one or more of my posts in which I was waxing on philosophically about about my beliefs regarding keeping the network plumbing dumb and overlaying security as a flexible, agile, open and extensible services layer.

It's clear he doesn't think this way, but I welcome the discourse.  So let me make something clear:

Realistically, and especially in non-segmented flat networks, I think there are certain low-level security functions that will do well by being served up by switching infrastructure as security functionality commoditizes, but I'm not quite sure for the most part how or where yet I draw the line between utility and intelligence.  I do, however, think that NAC is one of those utility services.

I'm also unconvinced that access-grade, wiring closet switches are architected to scale in either functionality, efficacy or performance to provide any more value or differentiation other than port density than the normal bolt-on appliances which continue to cause massive operational and capital expenditure due to continued forklifts over time.  Companies like Nevis and Consentry quietly admit this too, which is why they have both "secure switches" AND appliances that sit on top of the network...

Joseph suggested he was entering into a religious battle in which he summarized many of the approaches to security that I have blogged about previously and I pointed out to him on his blog that this is exactly why I practice polytheism ;) :

In case you aren’t following the religious wars going on in the security blogs and elsewhere, let me bring you up to date.

It goes like this. If you are in the client software business, then security has to be done in the endpoints and the network is just dumb “plumbing,” or rather, it might as well be because you can’t assume anything about it. If you sell appliances that sit here and there in the network, the network sprouts two layers, with the “plumbing” part separated from the “intelligence.” Makes sense, I guess. But if you sell switches and routers then the intelligence must be integrated in with the infrastructure. Now I get it. Or maybe I’m missing the point, what if you sell both appliances and infrastructure?

I believe that we're currently forced to deploy in defense in depth due to the shortcomings of solutions today.  I believe the "network" will not and cannot deliver all the security required.  I believe we're going to have to invest more in secure operating systems and protocols.  I further believe that we need to be data-centric in our application of security.  I do not believe in single-point product "appliances" that are fundamentally functionally handicapped.  As a delivery mechanism to deliver security that matters across network I believe in this.

Again, the most important difference between what I believe and what Joseph points out above is that the normal class of "appliances" he's trying to suggest I advocate simply aren't what I advocate at all.  In fact, one might surprisingly confuse the solutions I do support as "infrastructure" -- they look like high-powered switches with a virtualized blade architecture integrated into the solution.

It's not an access switch, it's not a single function appliance and it's not a blade server and it doesn't suffer from the closed proprietary single vendor's version of the truth.  To answer the question, if you sell and expect to produce both secure appliances and infrastructure, one of them will come up short.   There are alternatives, however.

So why leave your endpoints, the ones that have all those vulnerabilities that created the security industry in the first place, to be hit on by bots, “guests,” and anyone else that wants to? I don’t know about you, but I would want both something on the endpoint, knowing it won’t be 100% but better than nothing, and also something in the network to stop the nasty stuff, preferably before it even got in.

I have nothing to disagree with in the paragraph above -- short of the example of mixing active network defense with admission/access control in the same sentence; I think that's confusing two points.   Back to the religious debate as Joseph drops back to the "Nevis is going to replace all switches in the wiring closet" approach to security via network admission/access control:

Now, let’s talk about getting on the network. If the switches are just dumb plumbing they will blindly let anyone on, friend or foe, so you at least need to beef up the dumb plumbing with admission enforcement points. And you want to put malware sensors where they can be effective, ideally close to entry points, to minimize the risk of having the network infrastructure taken down. So, where do you want to put the intelligence, close to the entry enforcement points or someplace further in the bowels of the network where the dumb plumbing might have plugged-and-played a path around your expensive intelligent appliance?

That really depends upon what you're trying to protect; the end point, the network or the resources connected to it.  Also, I won't/can't argue about wanting to apply access/filtering (sounds like IPS in the above example) controls closest to the client at the network layer.  Good design philosophy.   However, depending upon how segmented your network is, the types, value and criticality of the hosts in these virtual/physical domains, one may choose to isolate by zone or VLAN and not invest in yet another switch replacement at the access layer.

If the appliance is to be effective, it has to sit at a choke point and really be and enforcement point. And it has to have some smarts of its own. Like the secure switch that we make.

Again, that depends upon your definition of enforcement and applicability.  I'd agree that in flat networks, you'd like to do it at the port/host level, though replacing access switches to do so is usually not feasible in large networks given investments in switching architectures.  Typical fixed configuration appliances overlaid don't scale, either.

Furthermore, depending upon your definition of what an enforcement zone and it's corresponding diameter is (port, VLAN, IP Subnet) you may not care.  So putting that "appliance" in place may not be as foreboding as you wager, especially if it overlays across these boundaries satisfactorily.

We will see how long before these new-fangled switch vendors that used to be SSL VPN's, that then became IPS appliances that have now "evolved" into NAC solutions, will become whatever the next buzzword/technology of tomorrow represents...especially now with Cisco's revitalized technology refresh for "secure" access switches in the wiring closets.  Caymas, Array, and Vernier (amongst many) are perfect examples.

When it comes down to it, in the markets Crossbeam serves -- and especially the largest enterprises -- they are happy with their switches, they just want the best security choice on top of it provided in a consolidated, agile and scalable architecture to support it.

Amen.

/Hoff

Network Security is Dead...It's All About the Host.

No, not entirely as it's really about the data, but I had an epiphany last week. 

I didn't get any on me, but I was really excited about the -- brace yourself -- future of security in a meeting I had with Microsoft.  It reaffirmed my belief that while some low-hanging security fruit will be picked off by the network, the majority of the security value won't be delivered by it.

I didn't think I'd recognize just how much of it -- in such a short time -- will ultimately make its way back into the host (OS,) and perhaps you didn't either.

We started with centralized host-based computing, moved to client-server.  We've had Web1.0, are in the  beginnings of WebX.0 and I ultimately believe that we're headed back to a centralized host-based paradigm now that the network transport is fast, reliable and cheap.

That means that a bunch of the stuff we use today to secure the "network" will gravitate back towards the host. I've used Scott McNealy's mantra as he intended it to in order to provide some color to conversations before, but I'm going to butcher it here. 

While I agree that in abstract the "Network is the Computer," in order to secure it, you're going to have to treat the "network" like an OS...hard to do.   That's why I think more and more security will make its way back to the actual "computer" instead.

So much of the strategy linked to large security vendors sees an increase in footprint back on the host.  It's showing back up there today in the guise of AV, HIPS, configuration management, NAC and Extrusion Prevention, but it's going to play a much, much loftier role as time goes on as the level of interaction and interoperability must increase.  Rather than put 10+ agents on a box, imagine if that stuff was already built in?

Heresy, I suppose.

I wager that the "you can't trust the endpoint" and "all security will make its way into the switch" crowds will start yapping on this point, but before that happens, let me explain...

The Microsoft Factor

I was fortunate enough to sit down with some of the key players in Microsoft's security team last week and engage in a lively bit of banter regarding some both practical and esoteric elements of where security has been, is now and will be in the near future. 

On the tail of Mr. Chambers' Interop keynote, the discussion was all abuzz regarding collaboration and WebX.0 and the wonders that will come of the technology levers in the near future as well as the, ahem, security challenges that this new world order will bring.  I'll cover that little gem in another blog entry.

Some of us wanted to curl up into a fetal position.  Others saw a chance to correct material defects in the way in which the intersection of networking and security has been approached.  I think the combination of the two is natural and healthy and ultimately quite predictable in these conversations.

I did a bit of both, honestly.

As you can guess, given who I was talking to, much of what was discussed found its way back to a host-centric view of security with a heavy anchoring in the continued evolution of producing more secure operating systems, more secure code, more secure protocols and strong authentication paired with encryption.

I expected to roll my eyes a lot and figured that our conversation would gravitate towards UAC and that a bulk-helping of vapor functionality would be dispensed with the normal disclaimers urging "...when it's available one day" as a helping would be ladled generously into the dog-food bowls the Microsofties were eating from.

I am really glad I was wrong, and it just goes to show you that it's important to consider a balanced scorecard in all this; listen with two holes, talk with one...preferably the correct one ;)

I may be shot for saying this in the court of popular opinion, but I think Microsoft is really doing a fantastic job in their renewed efforts toward improving security.  It's not perfect, but the security industry is such a fickle and bipolar mistress -- if you're not 100% you're a zero.

After spending all this time urging people that the future of security will not be delivered in the network proper, I have not focused enough attention on the advancements that are indeed creeping their way into the OS's toward a more secure future as  this inertia orthogonally reinforces my point.

Yes, I work for a company that provides network-centric security offerings.  Does this contradict the statement I just made?  I don't think so, and neither did the folks from Microsoft.  There will always be a need to consolidate certain security functionality that does not fit within the context of the host -- at least within an acceptable timeframe as the nature of security continues to evolve.  Read on.

The network will become transparent.  Why?

In this brave new world, mutually-authenticated and encrypted network communications won't be visible to the majority of the plumbing that's transporting it, so short of the specific shunts to the residual overlay solutions that will still be present to the network in forms of controls that will not make their way to the host, the network isn't going to add much security value at all.

The Jericho Effect

What I found interesting is that I've enjoyed similar discussions with the distinguished fellows of the Jericho Forum wherein after we've debated the merits of WHAT you might call it, the notion of HOW "deperimeterization," "reperimeterization," (or my favorite) "radical externalization,"  weighs heavily on the evolution of security as we know it.

I have to admit that I've been a bit harsh on the Jericho boys before, but Paul Simmonds and I (or at least I did) came to the realization that my allergic reaction wasn't to the concepts at hand, but rather the abrasive marketing of the message.  Live and learn.

Both sets of conversations basically see the pendulum effect of security in action in this oversimplification of what Jericho posits is the future of security and what Microsoft can deliver -- today:

Take a host with a secured OS, connect it into any network using whatever means you find
appropriate, without regard for having to think about whether you're on the "inside" or "outside." Communicate securely, access and exchange data in policy-defined "zones of trust" using open, secure, authenticated and encrypted protocols.

If you're interested in the non-butchered more specific elements of the Jericho Forum's "10 Commandments," see here.

What I wasn't expecting in marrying these two classes of conversation is that this future of security is much closer and notably much more possible than I readily expected...with a Microsoft OS, no less.   In fact, I got a demonstration of it.  It may seem like no big deal to some of you, but the underlying architectural enhancements to Microsoft's Vista and Longhorn OS's are a fantastic improvement on what we have had to put up thus far.

One of the Microsoft guys fired up his laptop with a standard-issue off-the-shelf edition of Vista,  authenticated with his smartcard, transparently attached to the hotel's open wireless network and then took me on a tour of some non-privileged internal Microsoft network resources.

Then he showed me some of the ad-hoc collaborative "People Near Me" peer2peer tools built into Vista -- same sorts of functionality...transparent, collaborative and apparently quite secure (gasp!) all at the same time.

It was all mutually authenticated and encrypted and done so transparently to him.

He didn't "do" anything; no VPN clients, no split-brain tunneling, no additional Active-X agents, no SSL or IPSec shims...it's the integrated functionality provided by both IPv6 and IPSec in the NextGen IP stack present in Vista.

And in his words "it just works."   Yes it does.

He basically established connectivity and his machine reached out to an reachable read-only DC (after auth. and with encryption) which allowed him to transparently resolve "internal" vs. "external" resources.  Yes, the requirements of today expect that the OS must still evolve to prevent exploit of the OS, but this too shall become better over time.

No, it obviously doesn't address what happens if you're using a Mac or Linux, but the pressure will be on to provide the same sort of transparent, collaborative and secure functionality across those OS's, too.

Allow me my generalizations -- I know that security isn't fixed and that we still have problems, but think of this as a half-glass full, willya!?

One of the other benefits I got form this conversation is the reminder that as Vista and Longhorn default to IPv6 natively (they can do both v4&v6 dynamically,) as enterprises upgrade, the network hardware and software (and hence the existing security architecture) must also be able to support IPv6 natively.  It's not just the government pushing v6, large enterprises are now standardizing on it, too.

Here are some excellent links describing the Nextgen IP stack in Vista, the native support for IPSec (goodbye VPN market,) and IPv6 support.

Funny how people keep talking about Google being a threat to Microsoft.  I think that the network giants like Cisco might have their hands full with Microsoft...look at how each of them are maneuvering.

/Hoff
{ Typing this on my Mac...staring @ a Vista Box I'm waiting to open to install within Parallels ;) }

Security: "Built-in, Overlay or Something More Radical?"

I was reading Joseph Tardo's (Nevis Networks) new Illuminations blog and found the topic of his latest post ""Built-in, Overlay or Something More Radical?" regarding the possible future of network security quite interesting.

Joseph (may I call you Joseph?) recaps the topic of a research draft from Stanford funded by the "Stanford Clean Slate Design for the Internet" project that discusses an approach to network security called SANE.   The notion of SANE (AKA Ethane) is a policy-driven security services layer that utilizes intelligent centrally-located services to replace many of the underlying functions provided by routers, switches and security products today:

Ethane is a new architecture for enterprise networks which provides a powerful yet simple management model and strong security guarantees.  Ethane allows network managers to define a single, network-wide, fine-grain policy, and then enforces it at every switch.  Ethane policy is defined over human-friendly names (such as "bob, "payroll-server", or "http-proxy) and  dictates who can talk to who and in which manner.  For example, a policy rule may specify that all guest users who have not authenticated can only use HTTP and that all of their traffic must traverse a local web proxy.

Ethane has a number of salient properties difficult to achieve with network technologies today.  First, the global security policy is enforced at each switch in a manner that is resistant to poofing.  Second, all packets on an Ethane network can be attributed back to the sending host and the physical location in which the packet entered the network.  In fact, packets collected in the past can also be attributed to the sending host at the time the packets were sent -- a feature that can be used to aid in auditing and forensics.  Finally, all the functionality within Ethane is provided by very simple hardware switches.       

The trick behind the Ethane design is that all complex functionality, including routing, naming, policy declaration and security checks are performed by a central controller (rather than in the switches as is done today).  Each flow on the network must first get permission from the controller which verifies that the communicate is permissible by the network policy.  If the controller allows a flow, it computes a route for the flow to take, and adds an entry for that flow in each of the switches along the path.       

With all complex function subsumed by the controller, switches in Ethane are reduced to managed flow tables whose entries can only be populated by the controller (which it does after each succesful permission check).  This allows a very simple design for Ethane       switches using only SRAM (no power-hungry TCAMS) and a little bit of logic.    

I like many of the concepts here, but I'm really wrestling with the scaling concerns that arise when I forecast the literal bottlenecking of admission/access control proposed therein.

Furthermore, and more importantly, while SANE speaks to being able to define who "Bob"  is and what infrastructure makes up the "payroll server,"  this solution seems to provide no way of enforcing policy based on content in context of the data flowing across it.  Integrating access control with the pseudonymity offered by integrating identity management into policy enforcement is only half the battle.

The security solutions of the future must evolve to divine and control not only vectors of transport but also the content and relative access that the content itself defines dynamically.

I'm going to suggest that by bastardizing one of the Jericho Forum's commandments for my own selfish use, the network/security layer of the future must ultimately respect and effect disposition of content based upon the following rule (independent of the network/host):

Access to data should be controlled by security attributes of the data itself.

• Attributes can be held within the data (DRM/Metadata) or could be a separate system.
• Access / security could be implemented by encryption.
• Some data may have “public, non-confidential” attributes.
• Access and access rights have a temporal component. 

 

Deviating somewhat from Jericho's actual meaning, I am intimating that somehow, somewhere, data must be classified and self-describe the policies that govern how it is published and consumed and ultimately this security metadata can then be used by the central policy enforcement mechanisms to describe who is allowed to access the data, from where, and where it is allowed to go.

...Back to he topic at hand, SANE:

As Joseph alluded, SANE would require replacing (or not using much of the functionality of) currently-deployed routers, switches and security kit.  I'll let your imagination address the obvious challenges with this design.

Without delving deeply, I'll use Joseph's categorization of “interesting-but-impractical”

/Hoff

It's a sNACdown! Cage Match between Captain Obvious and Me, El Rational.

CAUTION:  I use the words "Nostradramatic prescience" in this blog posting.  Anyone easily offended by such poetic buggery should stop reading now.  You have been forewarned.

That's it.  I've had it.  I've taken some semi-humorous jabs at Mr. Stiennon before, but my contempt for what is just self-serving PFD (Pure F'ing Dribble) has hit an all time high.  This is, an out-and-out, smackdown.  I make no bones about it.

Richard is at it again.  It seems that stating the obvious and taking credit for it has become an art form. 

Richard expects to be congratulated for his prophetic statements that are basically a told-you-so to any monkey dumb enough to rely only on Network Admission Control (see below) as his/her only security defense.  Furthermore, he has the gaul to suggest that by obfuscating the bulk of the arguments made to the contradiction of his point, he wins by default and he's owed some sort of ass-kissing:

And for my fellow bloggers who I rarely call out using my own blog: are you ready to retract your "founded on quicksand" statements and admit that you were wrong and Stiennon was right once again?  :-)

Firstly, there's a REASON you "rarely call out" other people on your blog, Richard. It has something to do with a lack of frequency of actually being right, or more importantly others being wrong.  

I mean the rest of us poor ig'nant blogger folk just cower in the shadows of your earth-shattering predictions for 2007: Cybercrime is on the rise, identify theft is a terrible problem, attacks against financial services companies will increase and folks will upload illegal videos to YouTube. 

I'm sure the throngs of those who rise up against Captain Obvious are already sending their apology Hallmarks.  I'll make sure to pre-send those congratulatory balloons now so I can save on shipping, eh?

Secondly, suggesting that others are wrong when you only present 1/10th of the debate is like watching two monkeys screw a football.  It's messy, usually ends up with one chimp having all the fun and nobody will end up wanting to play ball again with the "winner."  Congratulations, champ.

What the heck am I talking about?  Way back when, a bunch of us had a debate concerning the utility of NAC.  More specifically, we had a debate about the utility, efficacy and value of NAC as part of an overall security strategy.  The debate actually started between Richard and Alan Shimmel. 

I waded in because I found them both to be right and both to be wrong.  What I suggested is that NAC by ITSELF is not effective and must be deployed as part of a well-structured layered defense.  I went so far as to  suggest that Richard's ideas that the network 'fabric' could also do this by itself were also flawed.  Interestingly, we all agreed that trusting the end-point ALONE to report on its state and gain admission to the network was a flawed idea.

Basically, I suggested that securing one's assets came down to common sense, the appropriate use of layered defense in both the infrastructure and on top of it and utilizing NAC when and how appropriate.  You know, rational security.

The interesting thing to come out of that debate is that to Richard, it became clear that the acronym "NAC" appeared to only mean Network ADMISSION Control.  Even more specifically, it meant Cisco's version of Network ADMISSION Control.  Listen to the Podcast.  Read the blogs.  It's completely one dimensional and unrealistic to group every single NAC product and compare it to Cisco.  He did this intentionally so as to prove an equally one dimensional point.  Everyone already knows that pre-admission control is nothing you solely rely on for assured secure connectivity.

To the rest of us who participated in that debate, NAC meant not only Network ADMISSION Control, but also Network ACCESS Control...and not just Cisco's which we all concluded, pretty much sucked monkey butt.  The problem is that Richard's assessment of (C)NAC is so myopic that he renders any argument concerning NAC (both) down to a single basal point that nobody actually made.

It goes something like this and was recorded thusly by his lordship himself from up on high on a tablet somewhere.  Richard's "First Law of Network Security":

Thou shalt not trust an end point to report its own state

Well, no shit.  Really!?  Isn't it more important to not necessarily trust that the state reported is accurate but take the status with a grain of salt and use it as a component of assessing the fitness of a host to participate as a citizen of the network?   Trust but verify?

Are there any other famous new laws of yours I should know about?  Maybe like:

Thou shalt not use default passwords
Thou shalt not click on hyperlinks in emails
Thou shalt not use eBanking apps on shared computers in Chinese Internet Cafes
Thou shalt not deploy IDS' and not monitor them
Thou shalt not use "any any any allow" firewall/ACL rules
Thou shalt not allow SMTP relaying
Thou shalt not use the handle hornyhussy in the #FirewallAdminSingles IRC channel

{By the way, I think using the phrase '...shalt not' is actually a double-negative?} [Ed: No, it's not]

Today Richard blew his own horn to try and reinforce his Nostradramatic prescience when he commented on how presenters at Blackhat further demonstrated that you can spoof reporting compliance checks of an end-point to the interrogator using Cisco's NAC product using a toolkit created to do just that. 

Oh, the horror!  You mean Malware might actually fake an endpoint into thinking it's not compromised or spoof the compliance in the first place!?  What a novel idea.  Not.  Welcome to the world of amorphous polymorphic malware.  Been there, done that, bought the T-Shirt.  AV has been dealing with this for quite a while.  It ain't new.  Bound to happen again.

Does it make NAC useless.  Nope.  Does it mean that we need greater levels of integrity checking and further in-depth validation of state.  Yep.   'Nuff said. 

Let me give you Hoff's "First Law of Network Security" Blogging:

Thou shalt not post drivel bait, Troll.

It's not as sexy sounding as yours, but it's immutable, non-negotiable and 100% free of trans-fatty acids.

/Hoff

(Written from the lobby of the Westford Regency Hotel.  Drinking...nothing, unfortunately.)

If it walks like a duck, and quacks like duck, it must be...?

Seriously, this really wasn't a thread about NAC.  It's a great soundbite to get people chatting (arguing) but there's a bit more to it than that.  I didn't really mean to offend those NAC-Addicts out there.

My last post was the exploration of security functions and their status (or even migration/transformation)  as either a market or feature included in a larger set of features.  Alan Shimel responded to my comments; specifically regarding my opinion that NAC is now rapidly becoming a feature and won't be a competitive market for much longer. 

Always the quick wit, Alan suggested that UTM was a "technology" that is going to become a feature much like my description of NAC's fate.  Besides the fact that UTM isn't a technology but rather a consolidation of lots of other technologies that won't stand alone, I found a completely orthogonal statement that Alan made to cause my head to spin as a security practitioner. 

My reaction stems from the repeated belief that there should be separation of delivery between the network plumbing, the security service layers and ultimately the application(s) that run across them.  Note well that I'm not suggesting that common instrumentation, telemetry and disposition shouldn't be collaboratively shared, but their delivery and execution ought to be discrete.  Best tool for the job.

Of course, this very contention is the source of much of the disagreement between me and many others who believe that security will just become absorbed into the "network."  It seems now that Alan is suggesting that the model of combining all three is going to be something in high demand (at least in the SME/SMB) -- much in the same way Cisco does:

The day is rapidly coming when people will ask why would they buy a box that all it does is a bunch of security stuff.  If it is going to live on the network, why would the network stuff not be on there too or the security stuff on the network box.

Firstly, multi-function devices that blend security and other features on the "network" aren't exactly new.

That's what the Cisco ISR platform is becoming now what with the whole Branch Office battle waging, and back in '99 (the first thing that pops into my mind) a bunch of my customers bought and deployed WhistleJet multi-function servers which had DHCP, print server, email server, web server, file server, and security functions such as a firewall/NAT baked in.

But that's neither here nor there, because the thing I'm really, really interested in Alan's decidedly non-security focused approach to prioritizing utility over security, given that he works for a security company, that is.

I'm all for bang for the buck, but I'm really surprised that he would make a statement like this within the context of a security discussion.

That is what Mitchell has been talking about in terms of what we are doing and we are going to go public Monday.  Check back then to see the first small step in the leap of UTM's becoming a feature of Unified Network Platforms.

Virtualization is a wonderful thing.  It's also got some major shortcomings.  The notion that just because you *can* run everything under the sun on a platform doesn't always mean that you *should* and often it means you very much get what you pay for.  This is what I meant when I quoted Lee Iacocca when he said "People want economy and they will pay any price to get it."

How many times have you tried to consolidate all those multi-function devices (PDA, phone, portable media player, camera, etc.) down into one device.  Never works out, does it?  Ultimately you get fed up with inconsistent quality levels, you buy the next megapixel camera that comes out with image stabilization.  Then you get the new video iPod, then...

Alan's basically agreed with me on my original point discussing features vs. markets and the UTM vs. UNP thing is merely a handwaving marketing exercise.  Move on folks, nothing to see here.

'nuff said.

/Hoff

(Written sitting in front of my TV watching Bill Maher drinking a Latte)

NAC is a Feature not a Market...

I'm picking on NAC in the title of this entry because it will drive Alan Shimel ape-shit and NAC has become the most over-hyped hooplah next to Britney's hair shaving/rehab incident...besides, the pundits come a-flockin' when the NAC blood is in the water...

Speaking of chumming for big fish, love 'em or hate 'em, Gartner's Hype Cycles do a good job of allowing one to visualize where and when a specific technology appears, lives and dies as a function of time, adoption rate and utility.

We've recently seen a lot of activity in the security space that I would personally describe as natural evolution along the continuum, but is often instead described by others as market "consolidation" due to saturation. 

I'm not sure they are the same thing, but really, I don't care to argue that point.  It's boring.  It think that anyone arguing either side is probably right.  That means that Lindstrom would disagree with both. 

What I do want to do is summarize a couple of points regarding some of this "evolution" because I use my blog as a virtual jot pad against which I can measure my own consistency of thought and opinion.  That and the chicks dig it.

Without my usual PhD Doctoral thesis brevity, here are just a few network security technologies I reckon are already doomed to succeed as features and not markets -- those technologies that will, within the next 24 months, be absorbed into other delivery mechanisms that incorporate multiple technologies into a platform for virtualized security service layers:

1. Network Admission Control
2. Network Access Control
3. XML Security Gateways
4. Web Application Firewalls
5. NBAD for the purpose of DoS/DDoS
6. Content Security Accelerators
7. Network-based Vulnerability Assessment Toolsets
8. Database Security Gateways
9. Patch Management (Virtual or otherwise)
10. Hypervisor-based virtual NIDS/NIPS tools
11. Single Sign-on
12. Intellectual Property Leakage/Extrusion Prevention
    

...there are lots more.  Components like gateway AV, FW, VPN, SSL accelerators, IDS/IPS, etc. are already settling to the bottom of UTM suites as table stakes.  Many other functions are moving to SaaS models.  These are just the ones that occurred to me without much thought.

Now, I'm not suggesting that Uncle Art is right and there will be no stand-alone security vendors in three years, but I do think some of this stuff is being absorbed into the bedrock that will form the next 5 years of evolutionary activity.

Of course, some folks will argue that all of the above will just all be absorbed into the "network" (which means routers and switches.)  Switch or multi-function device...doesn't matter.  The "smoosh" is what I'm after, not what color it is when it happens.

What'd I miss?

/Hoff

(Written from SFO Airport sitting @ Peet's Coffee.  Drinking a two-shot extra large iced coffee)

A Funny Thing Happened at the Museum Of Science...

One of the benefits of living near Boston is the abundance of amazing museums and historic sites available for visit within 50 miles from my homestead.

This weekend the family and I decided to go hit the Museum of Science for a day of learning and fun.

As we were about to leave, I spied an XP-based computer sitting in the corner of one of the wings and was intrigued by the sign on top of the monitor instructing any volunteers to login:

 

Then I noticed the highlighted instruction sheet taped to the wall next to the machine:

 

If you're sharp enough, you'll notice that the sheet instructs the volunteer how to remember their login credentials -- and what their password is ('1234') unless they have changed it!

"So?" you say, "That's not a risk.  You don't have any usernames!"

Looking to the right I saw a very interesting plaque.  It contained the first and last names of the museum's most diligent volunteers who had served hundreds of hours on behalf of the Museum.  You can guess where this is going...

I tried for 30 minutes to find someone (besides Megan Crosby on the bottom of the form) to whom I could suggest a more appropriate method of secure sign-on instructions.  The best I could do was one of the admission folks who stamped my hand upon entry and ended up with a manager's phone number written on the back of a stroller rental slip.

(In)Security is everywhere...even at the Museum of Science.  Sigh.

/Hoff

Upchuck, Shrubbery, Bumps-in-the-wire & Alan does the "Shimmy"

Alan and I normally are close enough on our positions that I don't feel it necessary to argue with him.

I certainly don't feel compelled to come to the defense of a competitor that Alan's unloading on, but I'm really confused about his interpretation of what TippingPoint's Chief Architect, Brian Smith, is communicating and where Alan suggests that he and StillSecure's position lays.

To re-cap, Brian Smith was quoted in an SC Magazine Article as describing his views on how security ought to be positioned in the network thusly:

"Brian Smith, the chief architect of 3Com and a founder of TippingPoint, says his first-ever RSA keynote will focus on integrating solutions such as network access control, intrusion prevention and behavioral anomaly detection to create an intelligent network.

"I can do all of these sorts of synergies and when you trace it out, what ends up happening is you're able to debug network problems that you were never able to do before, get an unprecedented level of security, and also lower the total cost of ownership," Smith says. "They have to talk to each other. If we can pull all of these solutions together, I think that's going to be the trend over the next five to 10 years. It's a natural evolution in the technology cycle."

Smith says he also plans to emphasize the benefits of the bump-in-the-wire network approach to deploying security solutions. Rather than embedding solutions into switchers and routers, Smith plans to suggest overlaying solutions to allow for a more converged, cheaper way to add intelligence to the network."

Amen to that.  But lest you think I am intimating that we should all just toss appliances willy-nilly across the network (in fact, that's the opposite of what I think,) please read on...

Apparently it was the third (boldfaced) paragraph that got Alan's goat and provoked him into a state of up-chuckedness.  Specifically, it seems that it is repugnant to Alan that someone who works for a "switch" company could suggest that overlaying security can be facilitated as a "bump-in-the wire."  I guess that depends upon your interpretation of "bump-in-the-wire." 

I'm guessing that Alan thinks that means individual appliances being inserted between network segments with one "goesinta" and one "goesouta" cable and yet I can't figure out why  "...virtualizing some of this stuff and putting it on blades and so forth" has to be within the router or switch and not on an extensible services platform?

I have a feeling I'm going to hear the typical "not everyone can afford big iron" as a response...but if you can generalize to prove a point, I can become surgical and suggest that it's not fair to treat the Global 2000, Carriers, Service Providers and Mobile Operators as an exception rather than the rule when it comes to describing security trends and markets, either.

Summarily, it appears that the "convergence" of networking and security in Alan's eyes means that security functionality MUST be integrated into routers and switches in order to be successful and that adding security functionality on top of or in conjunction with the network is a lousy idea.

Strange comments from a guy whose company takes generic PC appliances  with security software on them and deploys them as bumps in the wire by sprinkling them across the network -- usually at the cursed perimeter and not at the core.  Confused?  So am I.

Alan goes on:

Most of the guys who do the bump in the wire are trying like hell to move up the stack and the network to get away from the edge to the core.  You may be able to do IPS as a bump in the wire at the core if you have the horsepower, but you are going to be forced to the edge for other security stuff if you insist on bump in the wire.  Single point of failure, scalability and cost are just working against you. Eventually you have to turn to the switch. I just don't get where he is coming from here.

So you're saying that your business model is already dead, Alan?

The final piece of irony is this:

Has selling big-ass, honking ASIC boxes to do IPS for so long totally blinded them to virtualizing some of this stuff and putting it on blades and so forth inside the switch and network.

Um, no. Again, not like I feel any inclination to defend Tippingpoint, but it's apparent that Alan is not aware of TippingPoint's M60 which is a huge multi-gigabit LAN switching platform (10-14 slots) with integrated IPS (and other functionality) that can either replace a typical switch or connect to existing switch fabrics to form an overlay security service.  It's about a year overdue from the last announcement, but the M60 is an impressive piece of iron:

Each blade in the M60 acts as a stand-alone IPS device, similar to TippingPoint's T-series appliances, in which network connectivity and IPS packet processing are done on the hardware. (The exception is with 10G interfaces; the M60 uses 3Com's 8800 dual-port 10G blades, which connect to TippingPoint IPS blades through the switch's backplane.)

The blades run 3Com's TippingPoint IPS device operating system and use the vendor's Digital Vaccine updating service, letting  the device identify the latest threat signatures and vulnerabilities.

This was one of the results of the Huawei joint venture with 3Com.  I believe that THIS is really what Brian Smith is talking about, not device sprinkling appliances.  It's  a switch.  It's an IPS.  That's bad, how?

What has me confused is that if Alan is so against hanging security services/functions OFF a switch, why did StillSecure do the deal with Extreme Networks in which the concept is to hang an appliance (the Sentriant AG) off the switch as an appliance instead of "inside" it like he suggests is the only way to effectively demonstrate the convergence of networking and security?

So, I totally get Brian Smith's comments (despite the fact that he's a competitor AND works for a switch vendor -- who, by the way, also OEM'd Crossbeam's X-Series Security Services Switches prior to their Tippingpoint acquisition!)

The model is valid.  Overlaying security as an intelligent service layer on top of the network is a great approach.  Ask me how I know. ;)

Chris

IDS is dead, NAC doesn't work...long live UTM? Welcome Back to the Vendor Cesspool, Mr. Stiennon...

I smell blood.  This will be a very fun next couple of months.  Why?

In case you haven't heard, Richard Stiennon has announced that after his provoking and inciteful rant (sorry, Mike) against Check Point, Ken Xie from Fortinet wooed him back to the darkside and he's going to join them as their newly-titled Chief Marketing Officer.  Timing is everything, eh?

The esteemed Mr. Stiennon is a really smart guy and I am honestly looking forward to seeing how and what he does @ Fortinet.  It will be thought-provoking for sure.

So much for the niceties...Richard's railed on me previously about how big honkin' UTM boxes aren't the answer to security but I reckon that's going to change -- or spin -- now that he works for a vendor that sells (amongst mostly SMB/SME solutions) big honkin' UTM boxes.

We really had a good time going at each other in regards to NAC and his Secure Network Fabric (SNF) positioning and it lead to a podcast debate on Martin McKeay's blog, also.  I am eager to see how, or if, Fortinet's strategy changes once Richard gets his hands on the positioning and messaging.

Fortinet really doesn't compete in the "...high-end enterprise, carrier and managed service provider" space, but their ATCA-based chassis products are certainly positioned to play there.  He's got his work cut out for him. 

I forecast that Fortinet's high-end ATCA-based product line will be the soapbox from atop which Richard continues to evangelize his SNF strategy -- but instead of "embedding" security in the switching fabric, it will be overlaid with big honkin' UTM boxes, despite his prior arguments to the contrary.  I further prognosticate that we'll see PR regarding relationships with switch vendors like what Shimmy @ StillSecure did with Extreme...

Either way, it's going to be entertaining.

Congrats on the job, Richard.  At least I don't have to listen to your "...I'd rather debate with independent analysts" comments anymore. ;)  Looking forward to our continued interaction.

Chris

Crossbeam To Exit Security Market -- Will Re-focus On Selling Pet Supplies On-line

Firstly, I really like debating elements with Ptacek.  He’s a really, really smart guy.  Somewhat misguided, but a really, really smart guy.  I'm honored that he picks on me.  Really. 

He picked on Bejtlich the other day.  Given this association, I believe I have solved the Poincaré conjecture which has something to do with math, intractability and doughnuts.  Mmmmm.  Doughnuts.

Here, he mentions in response to my post regarding my Chicago presentation, that Cisco will crush Crossbeam.  Privately he gave me a date and time, but I told him that I wouldn't repeat when because it might affect his Cisco stock value.

Secondly, I can only giggle about Thomas’ choice for his blog entry title ("Cisco can kill Crossbeam any time it wants...") relating how Cisco will assimilate us all…I remember that same Borg-like prediction about how Microsoft would crush the Linux movement and how no other OS would stand a chance.

I believe Thomas is still using a Mac today…

At any rate, I started with Crossbeam almost exactly a year ago.  The funny thing about crossing over from a security practitioner to working for a security vendor is that all your credibility goes out the window instantly.

I get this, it’s part of the game, but I refuse to bow to the notion that the last 15 years of my life and the credibility it has earned is erased by this singular event, so I go on assuming that my opinions count as they always have – like the paper they’re written on.

Almost always, I end up arguing with people who have either only been a vendor or an analyst and short of securing their home networks have never actually been a CISO of a company whose assets have monetary value with the word “billions” preceeding it.  I have.  I argue from that point and the beliefs that come from that perspective.  Yes, I am biased.  I was before I came to Crossbeam, too.

The one thing that makes it difficult to sort out addressing someone who is as long-winded as I am is figuring out which parts of the debate are religious, marketing, technical or dogma.

Thomas is obviously reacting to my post playing the role of Cisco’s VP of Marketing, despite his disclaimers to the opposite.  I will answer disguised as a cabaret dancer from Ohio.  I hope that’s not confusing.  If nothing I say makes sense, I’ll just ask you to rent the movie “Showgirls” and you’ll forget all about this security nonsense.

So I’ve read his retort to my post/presentation, and I’m going to respond to the things I think are worth responding to because a good chunk of his posting doesn’t really address my points – they defend Cisco’s misses.  Yet I digress…

Ptacek starts out all right, doing a good job of summarizing the sentiment of both my post and my presentation:

Chris’ argument has three salients:

• Cisco’s Self-Defending Network Architecture (the successor to SAFE) is just marketecture.
• Cisco hasn’t put its money where its mouth is on integration of security into its mainline platforms (the Cat and routers).
• Security belongs at a “service layer”, virtualized over the entire network, not as point-deployed boxes (IPS) or embedded into the infrastructure (IPS blade).

I really could just stop here because I’ve yet to find anyone (besides Thomas) who would actually disagree with any of those points, so why continue? ;)

But, he did, so I will…

1.    Is SDNA “marketecture”? Of course it is. SDNA is code for “sole-source network security from Cisco”. Sniping at SDNA’s credibility is as silly as sniping at the Cisco SAFE architecture in 2001: absolutely nobody designs networks according to these “schemes”. SDNA is a “why we did it” story that is retrofit onto Cisco’s evolving product lines to make it seem like they have strong management and a real vision.

Roger that.  SDNA = marketing.  Being opportunistic marketing-wise = vision.  Check.

But Chris’ argument isn’t about SDNA. It’s about whether enterprises should sole-source from Cisco, with around $1b in security sales, or consider vendors like Crossbeam that post sales less than 8% of that.

That’s right, my argument is that you shouldn’t sole-source your security solutions from a single vendor who claims competency in 15+ categories of security without demonstrating it, ever, except with a checkbook.

Also, just to double-check, Thomas, in Cisco math, a $200,000 Cat6500 switch with two FWSM blades is still $200,000 of “security sales,” right?   Uh-huh.  How about those “negative margin” deals…

That’s a fine argument to make, but if you’re going to build it on Cisco’s inability to run a real playbook, you can’t cherry pick Cisco’s weakest messages. SDNA may be meaningless. NAC isn’t. Even if it doesn’t work yet, it’s actionable and it’s changed the way people think about securing their network, and when Cisco buys the company that can really deliver on it for large enterprises, NAC is going to cause Crossbeam huge headaches.

Cherry-pick their weakest message?  SDNA is their message, Thomas!   DVVM and Quad-play is dependent upon this underlying message that “security is the network.”  I didn’t make this up, Cisco did.

You just contradicted yourself hugely.  In the first paragraph you said that “…absolutely nobody designs networks according to these “schemes”” but somehow that’s affected the way in which folks secure their networks!?  You’re right…they take a look at the Cisco method and realize it doesn’t work and look for other solutions.

Also, I just love the “…you just wait until Cisco buys something that actually works” sentiment!

By the way, Crossbeam doesn’t have to fear when Cisco gets NAC working (which is the most hysterical comment you’ve made,) because we can simply get a best-of-breed partners’ NAC application running on our platforms…no cash, no development, no fuss.  In fact, we are already in the process of doing that.

Furthermore, when you say NAC, you mean CNAC.  But which CNAC are you referring to?  The one that didn't completely pan-out (CSA) or the new-and-improved Clean Access?  You know, the same Clean Access that requires ANOTHER appliance to be added to the network to function and is purdy much a Cisco-only solution...

2.    If you’re an indie network security vendor with a pulse, the idea of Cisco embedding IPS and firewalls into every Cat switch and access router puts you in a cold sweat. Is Cisco full of shit about this plan? Reasonable people will disagree, but the answer will be “no”.

See, I don’t think they’re full of shit.  I just think they’re not a security company and aren’t executing on their vision in a manner consistent with the customers they serve outside of the SMB.  The Enterprise strategy is showing cracks and they are very distracted across an immense portfolio.  They're trying to re-group on the convergence front, but there's pressure there, too.  All the while, security plods on.

First, the existence proof: the ISR. Large enterprises buy them by the hundreds. It’s one of Cisco’s most successful products ever. And it’s a direct threat to the branch/satellite-office market that is the primary revenue multiplier for indie perimeter security vendors —- Crossbeam’s bread and butter.

The ISR is fantastic…and if you’re a branch/satellite-office company I’d suggest it’s a very good product – still only provides limited security functionality and that’s why Cisco sells ASA’s with them.

Also, if you’re suggesting that the SMB/Branch perimeter is Crossbeam’s “bread and butter” you are completely and absolutely incorrect.  90% of our revenue comes from Large enterprise data center consolidation and service provider/MSSP/mobile operator customers.  Your definition of the “perimeter” needs work as does your understanding of what we do...again.

Cisco does more than $10b a year in Cat switching alone; by revenue, their grip on that market is comparable to Microsoft’s lock on operating systems. All it takes for Cisco to launch completely integrated network security is a credible ASA blade for the Cat6k. How far out can that be? Enterprises already buy the Firewall Switch Module.

Actually, the ASA isn’t their answer to the aging FWSM, the ACE and VSA are…and it’s got a long way to go.   By the way, who said that I’m suggesting we’re out to crush Cisco?  Beating them where they do a lousy job is a very nice living by your own math above.  How far out?  You'll have to ask them.

The 6500 series is old in the tooth and if you read Gartner's recent 2006 MQ for Campus LAN, their darling Cisco takes some serious knocks.  That includes the security piece.  Gasp!

And finally there’s the obvious point to be made about NAC and Cisco Security Agent, the alien larvae Cisco is trying implant into host security. NAC is a lot of bad things, but “un-integrated” is not one of them.

You're right, but you forget that "un-integrated (?)" does not equal “functional.”  You’re also a couple of months late on this argument already…please see above.  I think your a little out-of-date on where Cisco is with CNAC...please see the report above for a very interesting look at the Gartner report.

Basically, every indie vendor has a talking point about how Cisco should just stick to the connectivity that they’re good at. This stuff all sounds good at first, but c’mon. Cisco doesn’t own connectivity because they make the best routers and switches. To claim that their routing (perimeter) and switching (internal) real estate doesn’t give them a dominant position in security is to claim that the perimeter and internal networks aren’t implicated in security. Delusional.

A dominant position or an advantage in hocking their wares because there’s some box that might be a platform to deploy it someday or today in pieces?  I’d say the latter.  Where is my bottle of Zoloft, anyway?

I agree, they haven’t done it yet, but I’ll make a statement that’s sure to get me yelled at: as soon as Cisco decides it’s ready, it can end companies like Crossbeam, Checkpoint, and SourceFire within 18 months. Isn’t not doing that, and running security as a totally seperate business unit, one of the big mistakes they made in the 90s?

Oh, OK.  They haven't because instead of feeding the hungry, bestowing Linksys DSL routers to everyone in Kentucky or donating to stop the killing in Darfur, they've instead decided to give  kindly by not destroying their competitors. 

Jesus, I had no idea!  Thanks for clearing that up.   

Security is now under Jayshree’s organization which is routing/switching, and I don't believe it has ever been a separate unit.  It should be.  That way if it doesn't pan out they can just scrap-heap it and say that it's a feature, not a market.

3.  Does it make sense to deploy security uniformly across the whole network, defending secretary desktops the same way you defend iSCSI servers or server-agent management consoles? No. Security should be focused on assets.

Hey, that's a great point.  I think I made it! Please tell me how they do that?

But exactly what does this have to do with network architecture? Read Chris’ slides and it seems to mean “the way to architect your network is to hang Cisco boxes off of a couple Crossbeams in your core”.

Not quite, but your extreme-isms are starting to have me think you should write for Al-Jazeera.   How about quoting what I actually talked about…you know, like build a fast, reliable, resilient and responsive network infrastructure and overlay security as a combination of security services which provides the absolute best-of-breed security in combination where you need it, when you need it and at a price tag where the risk justifies the cost.

But that’s what you meant, right? ;)

The points Thomas pins his venom on below are from a single slide in the preso which is basically a Letterman’s top-10 spoof.  Some of them are purposely meant to incite, others are humorous, some are leverage points for the rest of the discussion that the audience and I had.

I’ll respond to some of them because many of Thomas’ objections are out of context and some are just to silly to respond to.  If you really, really want a line-by-line, I’ll do it.  Y’all just let me know ;)

2.  When’s the last time a network guy could perform a byte-level forensic trace of a Botnet C&C channel or a security guy troubleshoot a nasty BGP route-reflector distribution problem?

I don’t know. You might try asking Dug Song at Arbor, Kirby Kuehl at Cisco, or any of the Team Cymru guys. When’s the last time a security guy bought a Cisco product? Hint: it happened 5 times while you read this sentence.

Ummmm…I was referring to the average security and network practitioner in a stove-piped Enterprise or service provider, not the rest of the crew from your Saturday afternoon flag-football squad ;)

These guys, like you, are not representative of the typical folks who have to actually use the stuff we’re talking about.

You know, customers.

  3.  Managing threats and vulnerabilities is not the same as managing risk; networks don’t understand the value of the data traversing it..how can they protect it accordingly?

Cisco is not an ethernet cable. “The network” is whatever your vendor says it is. In Crossbeam’s case, “the network” is Cisco and “security” is everything else, including Checkpoint and SourceFire, both of whom sell products that Cisco has pin-compatible substitutes for.

Do any of these companies “understand the data”? No, I agree, they don’t. Is “understanding the data” important? Then let’s suspend the conversation until Cisco buys Vontu and Crossbeam partners with Vericept.

Pin-compatible?   Label-compatible, perhaps.  I think this is exactly the divergence that’s at the crux of the debate here, as the “quality” of the individual security solutions on their own (appliance or embedded) versus how they work as part of an architecture is the issue.  That’s my point, but it’s not a bullet-in-a-list sort of answer.

Also, I don’t care about Cisco buying Vontu, but what makes you think that we’re not already talking (and haven’t been for some time) to an extrusion prevention/IP Leakage vendor like Vericept?   

Crossbeam doesn’t suffer from having to wait to acquire technology and then spend 18 months butchering it to get it to work within the existing platforms (or build yet another point-solution appliance.)  We do our research in advance and when the time is right – and the customers desire it – we bring a partner’s application(s) onto the platform.

   4.  Just because two things are branded with the same name doesn’t mean they can communicate or interoperate well; just ask my wife

How’s that SourceFire/Checkpoint CPMI integration coming then? You got ISS using Snort signatures yet, or vice versa? Does anyone do app-level integration well?

Nope, and we're not going to.  Neither will Cisco because they have no reason to if the entire network -- and all the security components within -- is theirs.  In fact, it's within their interests to not have this happen.  If it did, it would just make your arguments weaker.

I’m just dinging the message and the messenger.  Our “app-level integration” is approached from a different perspective that starts first with consolidation of functions, virtualization of transport, application and policy then with the capability to flexibly pass flows through combinations of these virtual security stacks managed by the discrete parties charged with their care.  Best of breed functions that can be added to in an open platform without the need for a bunch of point solutions.

In large networks, the people responsible for FW are different than those responsible for IDS, are different than those responsible for XML, etc.   They’re still very, very vertically-stovepiped.

We don’t need to boil the ocean and we don’t.  We still have work to do on providing the overall global view of how traffic moves and is affected through these stacks, but we’re not the one blowing smoke about how this supposedly all works today.

That would be your job ;)

6.  The dirty little secret of embedding security in the “network” is that it’s the same as doing it with point-appliances…a single vendor’s set of appliances

Yes, it’s true: if Cisco succeeds in embedding security into its mainline products, you are going to be using Cisco security products. Diversity and consumer choice are valid arguments against Cisco.

But there’s one way in which using embedded security demonstrably isn’t the same as using point products: you don’t have to deploy point products to do it.

I call bullshit.  If you look at the slides in my preso, I can count over 13 different “point solutions” that aren’t routers and switches which are today relied upon to deploy this supposed “embedded” security.  The only difference between Cisco’s approach to embedded security and the appliance model is that the “appliances” are all Cisco’s.

Just because they have a Cisco label on it doesn’t make it “embedded.”

  7.  Modeling the security of the self-defending network after the human immune system and suggesting that it’s the ultimate analog is a crappy idea; people die

      Yes. What I hate about Cisco’s solutions is that you have to let a few machines on your network get infected for them to generate antigens; also, when Cisco’s security features coagulate around injuries, YouTube gets really slow.

Puff, puff, pass.  Puff, puff, pass.  You're f-in up the rotation...man!

Please point me to a single customer in the world who has a self-defending network that functions like this.  Oh, that’s right, it’s the marketecture that you referred to in your first point and forgot that it doesn’t, actually, exist.  If YouTube being slow was the biggest problem businesses had today, you wouldn’t be employed either, T.

   8.  Security solely by acquisition does not make you a security company… just like acquiring lots of security “stuff” does not make you secure

You sure this is a good argument to make for a company that delivers 99% of its security value prop through partnerships with other companies?

Let’s ask the mean question: using product space names and market position (ie, “the #5 IPS vendor”), name some of the companies Crossbeam has turned down as partners? Cisco’s kind of picky about what it buys, you know.

It’s absolutely the right argument to make.  I guarantee you that the model of being customer-driven to take the best-in-breed security solutions from true security vendors and integrate it into a delivery architecture that is designed to do this rather than being force-fed into a retro-fit, works.  Today.

Oh, and #5 is a long way from #1, Mr. T.

"I pity the fool who mess wit Cisco.   Unnhnhnhnhh!  I want Balboa.  Sucka!"

Oh, I’d be more than glad to email you the list of 15-20 vendors over the last 6 months that we’ve said “no” to. 

You’re about to hit my threshold trip-limit on how much of our business model you claim inside knowledge to…especially since you’re batting zero at this point.

9.  Security in breadth is not the same thing as security in depth; “good enough” security is not good enough in the data center

What aspect of Cisco’s IPS is not “good enough” for the data center?

…the same one that loses to ISS, Sourcefire, and Enterasys every day.  Want to ask the same about DDoS?  I believe the answer there would be your own beloved Arbor.

People deploy Cisco’s solution usually in conjunction with other products or the same function.  I think I’ve said enough.

Did you run your original post through the Babelfish English → Cisco parser before you copy/pasted it here, or what?

10.  Securing everything, everywhere is not only unnecessary, it’s unachievable

It is if Cisco sells it at 10 points below cost in order to turn the entire network security market into a line-item feature for the Catalyst 6000.

So you admit that this is not about the efficacy of a solution but rather how much shit you have to give away for free to be called a market leader?

Actually, with the example above, Cisco now suggests you buy a completely separate 6509 into which you put all the security functions and turn it into a “security services switch” that is plugged into the “real” switching/routing fabric. 

Sound familiar?  It does to me.

I know it doesn’t sound that way, but I’m neither a fan of Cisco nor a skeptic about Chris. But his arguments don’t take Cisco seriously, and if we’re going to armchair quarterback the security industry, why be nice about that?

You’re right, it doesn’t.  I still love you, though. 

By the way, Lindstrom and I both looked at each other and laughed when we had lunch together at the show realizing that should you ever figure out we were in Chi-town and didn’t call you that you’d be grumpy.  (I had no idea you lived in Chicago so it was all Pete’s fault.)

/Hoff

On Martin McKeay's Podcast re: NAC/SNF

Our online MobCast featuring Martin McKeay, Mike Rothman, Richard Stiennon, Alan Shimel and I regarding our on-going debate regarding NAC and SNF was almost a DNF when we discovered that SkypeCast sucked beyond compare (we jumped to "regular skype") and then Martin's recording software decided to dedicate its compute cycles to the SETI project rather than record us.

Many thanks to the esteemed Mr. Stiennon who was luckily committing a felony by recording us all without disclosure. ;)  See, there's a good side to all that government training. ;)

At any rate, we had a lively debate that needed to go on for about an hour more because (surprise!) we didn't actually resolve anything -- other than the two analysts were late to the call (surprise #2) and the two vendors were loud and obnoxious (not really a surprise.)

It was a great session that got passionately elevated across multiple elements of the discussion.  What we really recognized was that the definition of and expectations from NAC are wildly differing across the board; from the analyst to the vendor to the customer.

Take a listen when Martin posts it and let us know if we should have a second session.  I believe it will show up here:

http://www.securityroundtable.com/

Chris

NAC Attack: Why NAC doesn't work and SN(i)F doesn't, either...alone

I have to admit that when I read Alan Shimel's blog entry whereby he calls out Richard Stiennon on his blog entries titled "Don't Bother with NAC" and "Network Admission Control is a Blind Alley," I started licking my chops as I couldn't wait to jump in and take some time to throw fuel on the fire.  Of course, Mike Rothman already did that, but my goal in life is to be more inflammatory than he is, so let the dousing begin!

I've actually been meaning to ask for clarification on some points from both of these fellas, so no better time than the present. 

Now, given the fact that I know all of the usual suspects in this debate, it's odd that I'm actually not siding with any of them.  In fact, I sit squarely in the middle because I think that in the same breath both Richard and Alan are as wrong as they are right.  Mike is always right (in his own mind) but rather than suggest there was a KO here, let's review the tape and analyze the count before we go to the scorecards for a decision.

This bout is under the jurisdiction of and sanctioned by the Nevada Gaming Commission and brought to you by FUD -- the offical supplier of facts on the Internet. ;)

Tale of the tape:

Richard Stiennon:

1. Richard Stiennon highlighted some of Ofir Arkin's NAC "weaknesses" presented at Black Hat and suggests that NAC is a waste of time based upon not only these technical deficiencies but also that the problems that NAC seeks to solve are already ameliorated by proper patching as machines "...that are patched do not get infected."
2. Somewhat confusingly he follows on with the statement based upon the previous statement that "The fear of the zero-day worm or virus has proved ungrounded. And besides, if it is zero-day, then having the latest DAT file from Symantec does you no good."
3. Richard suggests that integrating host-based and network-based security is a bad idea and that the right thing to do is based upon  "de-coupling network and host-based security. Rather than require them to work together let them work alone."
4. Ultimately he expects that the rest of the problems will be fixed with a paradigm which he has called Secure Network Fabric. 
5. Richard says the right solution is the concept he calls "Secure Network Fabric (SNF)" wherein "...network security solutions will not require switches, routers, laptops, servers, and vendors to work in concert with each other" but rather "...relies most heavily on a switched network architecture [which] usually involve[s] core switches as well as access switches."
6. SNF relies on the VLANs that "...would be used to provide granularity down to the device-level where needed. The switch enforces policy based on layer 2 and 3 information. It is directed by the NetFlow based behavior monitoring system.
7. Richard has talked about the need for integrating intelligent IDP (Intrusion Detection and Prevention) systems coupled with NBA/NBAD (Network Behavioral Analysis/Network Behavioral Anomaly Detection) and switching fabric for quite some time and this integration is key in SNF functionality.
   
   
8. Furthermore, Richard maintains that relying on the endpoint to report its health back to the network and the mechanisms designed to allow admission is a bad idea and unnecessary.
9. Richard maintains that there is a difference between "Admission Control" and "Access Control" and sums it up thusly: "To keep it simple just remember: Access Control, good. Admission Control, bad."

Alan Shimel:

1. Alan freely admits that there are some technical "issues" with NAC such as implementation concerns with DHCP, static IP addresses, spoofed MAC addresses, NAT, etc.
2. Alan points out that Richard did not mention that Ofir Arkin also suggests that utilizing a NAC solution based upon 802.1x is actually a robust solution.
3. Alan alludes to the fact that people deploy NAC for various reasons and (quoting from a prior article) "...an important point is that NAC is not really geared towards stopping the determined hacker, but rather the inadvertant polluter."  Hence I believe he's saying that 802.1x is the right NAC solution to use if you can as it solves both problems, but that if latter is not your reason for deploying NAC, then the other issues are not as important.
4. Alan points to the fact that many of Richard's references are quite dated (such as the comments describing the 2003 acquisition of TippingPoint by 3Com as "recent" and that ultimately SNF is a soapbox upon which Richard can preach his dislike of NAC based upon "...trusting the endpoint to report its health."
5. De-coupling network and host-based endpoint security is a bad idea, according to Alan, because you miss context and introduce/reinforce the information silos that exist today rather than allow for coordinated, consolidated and correlated security decisions to be made.
6. Alan wishes to purchase Pot (unless it's something better) from Richard and go for a long walk on the shore because Mr. Stiennon has "the good stuff" in his opinion since Richard intimates that patching and configuration management have worked well and that zero-day attacks are a non-entity.
7. Alan suggests that the technology "...we used to call behvior based IPS's" which will pass "...to the switch to enfore policy" is ultimately "another failed technology" and that the vendors Richard cites in his BAIPS example (Arbor, Mazu, etc.) are all "...struggling in search of a solution for the technology they have developed."
8. Alan maintains that the SNF "dream" lacks the ability to deliver any time soon because by de-coupling host and network security, you are hamstrung by the lack of "...context, analytics and network performance."
9. Finally, Alan is unclear on the difference between Network Access Control (good) and Network Admission Control (bad.)

So again, I maintain that they are both right and both wrong.  I am the Switzerland of NAC/SNF! 

I'll tell you why -- not in any particular order or with a particular slant...

(the bout has now turned from a boxing context to a three man Mixed-Martial-Arts Octagon cage-match!  I predict a first round submission via tap-out):

1. Firstly, endpoint and network security MUST be deployed together and ultimately communicate with one another to ultimately effect the most visible, transparent, collaborative and robust defense-in-depth security strategy available.  Nobody said it's a 50/50 percentage, but having one without the other is silly.  There are things on endpoints that you can't discover over a network.  Not having some intelligence about the endpoint means the network cannot possibly determine as accurately the "intent" of the packets spewing from it.
2. Network Admission Control solutions don't necessarily blindly trust the endpoint -- whether agent or agentless, the NAC controller takes not only what the host "reports" but also how it "responds" to active probes of its state.  While virtualization and covert rootkits have the capability to potentially hide from these probes, suggesting that an endpoint passes these tests does not mean that the endpoint is no longer subject to any other control on the network...
3. Once Network Admission Control is accomplished, Network Access Control can be applied (continuously) based upon policy and behavioral analysis/behavioral anomaly detection.
4. Patching doesn't work -- not because the verb is dysfunctional -- but because the people who are responsible for implementing it are.  So long as these systems are not completely automated, we're at risk.
5. Zero day exploits are not overblown -- they're getting more surgically targeted and the remediation cycles are too long.  Network-based solutions alone cannot protect against anomalies that are not protocol or exploit/vulnerability signature driven...if the traffic patterns are not abnormal, the flags are OK and the content seemingly benign going to something "normal," it *will* hit the target.
6. You'll be suprised just how immature many of the largest networks on this planet are in terms of segmentation via VLANs and internal security...FLAT, FLAT, FLAT.  Scary stuff.  If you think the network "understands" the data that is transported over it or can magically determine what is more important by asset/risk relevance, I too would like some of that stuff you're smoking.
7. Relying on the SNF concept wherein the "switch enforces policy based on layer 2 and 3 information," and "is directed by the NetFlow based behavior monitoring system" is wholly shortsighted.  Firstly layer 2/3 information is incredibly limited since most of the attacks today are application-level attacks and NOT L2/L3 and Netflow data (even v9) is grossly coarse and doesn't provide the context needed to effectively determine these sorts of incursions.  That's why NetFlow today is mostly used in DDoS activities -- because you see egregiously spiked usage and/or traffic patterns.  It's a colander not a sieve.
8. Most vendors today are indeed combining IDP functionality with NBA/D to give a much deeper and contextual awareness across the network.  More importantly, big players such as ISS and Cisco include endpoint security and NAC (both "versions") to more granularly define, isolate and ameliorate attacks.  It's not perfect, but it's getting better.
9. Advances in BA/NBA/NBAD are coming (they're here, actually) and it will produce profound new ways of managing context and actionable intelligence when combined with optimized compute and forwarding engines which are emerging at the same time.   They will begin, when paired with network-wide correlation tools, to solve the holy trinity of issues: context, analytics and performance.
10. Furthermore, companies such as ISS and StillSecure (Alan's company) have partnered with switch vendors to actually do just what Richard suggests in concept.  Interestingly enough, despite the new moniker, the SNF concept is not new -- Cisco's SDN (albeit without NAC) heavily leverages the concepts described above from an embedded security perspective and overlay security vendors such as ISS and Crossbeam also have solutions (in POC or available) in this area.
11. Let's be honest, just like the BA vendors Alan described, NAC is in just the same position -- "struggling in search of a solution for the technology they have developed."  There are many reasons for deploying NAC: Pre and Post-inspection/Quarantine/Remediation and there are numerous ways of doing it: agent-based/agentless/in-line/out-of-band... The scary thing is with so many vendors jumping in here and the 800 pound Gorilla (Cisco) even having trouble figuring it out, how long before NAC becomes a feature and not a market?  Spending a bunch of money on a solution (even without potential forklifts) to not "... stop the determined hacker, but rather the inadvertant polluter" seems a little odd to me.  Sure it's part of a well defined network strategy, but it ain't all that yet, either.
12. With Cisco's CSO saying things like "The concept of having devices join a network in which they are posture-assessed and given access to the network in a granular way is still in its infancy" and even StillSecure's CTO (Mitchell Ashley) saying "...but I think those interested in NAC today are really trying to avoid infection spread by an unsuspecting network user rather than a knowledgeable intruder" it's difficult to see how NAC can be considered a core element of a network security strategy WITHOUT something like SNF.

So, they're both right and both wrong.  Oh, and by the way, Enterprise and Provider-class UTM solutions are combining ALL of this in a unified security service layer... FW, IDP, Anti-X, NBA(D) and SNF-like foundations.

[Tap before it breaks, boys!]

We need NAC and we need SNF and I've got the answer:

1. Take some of Richard's "good stuff"
2. Puff, puff, pass
3. Combine some of Alan's NAC with Richard's SNF
4. Stir
5. Bake for 30 minutes and you have one F'N (good) SNAC
   (it's an anagram, get it!)

There you have it.

Chris