Illuminations

Re: IP Address to User??

Chris Harrington over at Infosecpodcast blog wrote an interesting piece today called IP Address to User??  Unfortunately Chris has disabled comments on his blog, so I thought I'd take up the topic here on our blog.  Chris bemoans the fact that incident response in the enterprise today is still a long and laborious task.  IPS and Firewall solutions usually provide you an IP address at best when an incident occurs, and getting from there to an actual username so you can take action is a pretty rocky and time consuming road.  I'd like to bring some joy into Chris's life and let him know that there is an answer to his troubles and it's called LAN Security. 

By integrating NAC, identity-based stateful firewalling, full IPS capability, event correlation and monitoring into a single solution, LAN Security appliances and secure switches are able to crush the incident investigation time from hours to a little less than a second.  Yes folks, I said 1 second.  I know, I'm a marketing guy (I started life as an engineer before moving to the Dark Side, so I'm not all bad), so you're thinking this is all spin, but we have demo'ed this capability publicly at many trade shows and more importantly we have many customers who are using this today in large networks (think 10,000's users).  Resolution of the incident can also be in the seconds if you simply want to quarantine that user and endpoint, but might take a few more minutes if you want to remediate them.

None of this requires a NAC agent, in fact you can turn off the pre-connect NAC scans altogether and you're still protected because the identity based access control, IPS, event correlation and monitoring engines sit in the network monitoring each and every user flow and tie them to identity.  DHCP leases are not a problem, this is all real time functionality, and the type of troubleshooting and forensics data available is mind blowing.  One of the favorite tools that customers love is something we jokingly call "google for security".  Type in a username, IP or MAC address and you'll get an entire history of incidents, services and resources, applications, etc for that entity along with what they are doing right this minute.  Oh, and you can also feed syslog to your existing consoles if you like, so no more flipping.

So, Chris, I sympathize with your predicament and understand the pain you are feeling, but there is an elegant and simple solution.  You just have to believe and all your dreams can come true (it just takes 13 years :-))

//Dom

UPDATE: Chris had a glitch with a plugin and comments are now enabled again.

NY, NY. So good they named it NAC

We were at the Network Computing NAC Battleground Forum this week in NY.  When I say we, I mean pretty much any vendor who has the term NAC anywhere in their marketing collateral, plus nearly a hundred customer side folks.  Here are a few highlights and observations of the event:

1) 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.  I think the day that Cisco changed "Admission" to "Access" in the NAC acronym was a dark day for the industry.  That single act flung the floodgates of marketing spin and disinformation open.  We now have far too many companies with no meaningful post-connect capability or depth of security, shouting from the rooftops about how secure they will make your network because they can drop you in a VLAN.  People, people, people, let the madness stop.  Using a VLAN for security is the equivalent of caging a tiger with drinking straws.  But it's worse.  Because of the time and complexity involved in sticking straws together, and the complexity of the tiger's needs (he needs to eat, he needs to swim, he needs to see the vet, he needs to sleep, he needs to sit in a tree, etc), you have to build an enormous enclosure and put him in with all the prey animals, zoo keepers, visitors, etc.  Where is this analogy going?!?!  Anyway, the main point here is that if someone has multiple, or changing, policy needs, do you create an individual VLAN and keep on doing that for 10,000's of users?  I think not!  Complexity is the mother of opportunity for the malicious attacker, so the only way to solve this problem is to simplify, simplify, simplify.  Use a technology that uses persistent identity, application intelligence and ties into existing identity based policy stores.

2) Comedy comment of the day - "Maybe SOX compliance should be extended to Marketing".  Funny for two reasons; firstly it's a great concept and speaks to my first point; secondly because the guy who delivered it was among the worst offenders of the day in spinning his solution.  Here is a company that spoke on the Out of Band panel and then spent all their time impressing upon everyone that they had integrated IPS capability (I'm sorry, but by it's very definition isn't an IPS an in-line device?).

3) Bizarre moment of the day - A panelist (who shall remain nameless) on our in-line solutions panel having a brain fart and calling time on a competitor's (no free advertising here) presentation while she was in mid-sentence (that's why we have moderators isn't it?). Not a classy or necessary move, according to about 15 people I spoke with afterwards.

4) 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.

5) Stand out moment of the day - Jeremy Hobbs, CIO at Upper Canada District School Board, describing how he initially deployed a Nevis solution for 40,000+ users for security, but has also found significant and tangible ROI to be in the new business initiatives and working practices it has enabled.

Overall a useful event that gave customers the chance to get educated and get questions answered all in a single day.

//Dom Wilde

Port Puppets Please Stand Up

I generally stay out of the line of fire when there’s a religious war raging. I was going to stay out of this one, too, but the temptation is just too much (and the flesh is weak, etc).

I admit it - I’m one of those “port puppets” that Chris Hoff refers to. I kind of like the term, it has cachet to it, and might even look good on a T-shirt.

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?

The odd thing is, just like in real life, everybody’s right and everybody’s wrong, but nobody’s completely right and nobody’s completely wrong. Taking an actual real life analogy, you wouldn’t park your car in a dodgy neighborhood without worrying whether the door locks and alarm were enough to prevent a breakin. You’d feel a bit more secure with something more happening on the street, say, a cop walking his beat, or the car in a lot or garage with an attendant. Similarly, you wouldn’t tolerate burglars coming up and routinely rattling all your windows and doors looking for the one you forgot to latch. No, you would lock the doors, maybe get an alarm system, and call 911 if it happened. 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.

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?

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.

Joseph Tardo, Ph.D.

Technorati Tags: Joseph Tardo Rational Security

Who's watching the watchers??

Ted Schlein from Kleiner Perkins is obviously a smart guy (I tend to go with the theory that people who serially invest in successful companies know what they are talking about, everyone else just got lucky).  He gives an interview in NWW today asserting that the way of the future in security is to focus on the client.  Ted makes some good arguments, and I agree that there are some things that are best handled with a client if you have that luxury (blocking USB thumb drives for instance), but I have to call BS on a couple of points. 

The first is that Ted conveniently avoids the issue (or is it selective recall) that if you put security in userland (i.e. client software), it inevitably becomes part of the problem.  It is software written by humans after all, and therefore will have vulnerabilities.  The interesting part for me is that Ted started life writing software for Symantec, specifically their anti-virus product.  In recent history there have been at least two incidents where vulnerabilities in the Enterprise Edition of Symantec AV have been the focus of attacks.  In one instance an endpoint could be completely taken over, and in the other RINBOT targets Symantec software.  So, if Ted is right and the future is all about the client, who's watching the watchmen?  Surely if there is one thing we have learned over the past 20 years, it's that we need layers of security.

The second point I have issue with is that Ted asserts that security focus needs to be on the endpoint.  Well, actually that's not the issue, I'm in violent agreement with him there.  But he goes on to say there is no value in blocking the roads (i.e. the network paths), that's where I have an issue.  It strikes me that Ted may not be up to speed on the concept of LAN Security.  I think he still thinks of network security as Firewalls and IPS devices high in the network.  In that case the value in securing the endpoint is minimal, but with LAN Security devices like the Secure Switches and Appliances that we provide, we have focused on the endpoint and integrated multiple identity aware security technologies (NAC, stateful firewall, application layer gateways, Layer 2 security, IPS signature matching, anomaly detection, etc).  All of these technologies can operate in unison, to improve both accuracy and security, at 10's of Gigabits/sec right down to the port in the wiring closet, giving you, in effect, a personal network security agent for every user on the network, without putting it in userland.  Do we think this supercedes the need for client software?  No, not all, but it certainly makes things a hell of a lot more secure and gives you the confidence that someone is watching the watchers

//Dom Wilde

The great NAP/TNC vs. C-NAC debate

As Alan Shimel points out on his blog, the great Microsoft NAP vs. Cisco NAC debate just took an interesting turn, with Steve Hanna (in this instance representing TNC rather than his paymasters at Juniper) weighing in as to why there are only two horses left in the NAC race.  Of course, NAC, in this instance, only refers to the pre-connect posture check, so I'm not sure these horses have reached the starting gate yet, but that's just me...

Dom Wilde

Cloak and Shield – Star Trek or Network Security?

Star Trek always had some cool concepts. One of the things that always caught my fancy was the totally cool concept of cloaking. If you can’t see the ship or feel its presence close by, it is significantly harder to mount an attack on it. Years later, that same idea resurfaces as a strong paradigm for securing mission critical resources on the network. One of the critical things that any IT administrator worries about is how to secure servers that host confidential information, mission critical applications as well as services. In a world where domain users, along with guests, contractors, and vendors, all start accessing the corporate network via a myriad set of devices including desktops, handhelds, and mobile devices. The internal corporate network has become a free for all. As long as you can just get on to the network, you can go all kinds of places. “Where no user has gone before,” I might add in keeping with the Star Trek theme. And what that leads to is all kinds of opportunities to access information and mount attacks against the critical resources on your network. The analogy one could make is that you if can see the starship, you can mount an attack on it. Eventually with a sustained attack, the shields will go down.

So just how do we “cloak” the resource? I believe that feature can be implemented within the network fabric itself. If the role of a user prevents the user from having access to a certain server, the network should enforce that by preventing any traffic between the user and the protected resources from getting through. In effect, this “cloaks” the protected resources from the user since the user will not even know that the resource exists. Pings, traceroutes and other scanning tools will all fail to detect the resource as the network enforces the policy by dropping all such packets. This also, in effect, forms a “shield” around the protected resource since any network-based attacks mounted against the resource will get thwarted in the network itself. The key here is that this is all identity driven. If a resource is “cloaked” from one user, it can just as easily be made available to another user that should have access to it. Essentially, "identity-based cloaking" – now there’s one for the Romulans. Another key aspect of this is that the enforcement should be done close to the user itself. I.e., the threat should be thwarted close to the source. The deeper in the network that this control resides, the larger the portion of the network that gets exposed. To put it another way, why allow the thief to get to the locked bedroom door if you can lock the front door itself?

I also believe that putting this kind of control within the network requires a new breed of network switches. Ones that are stateful, fully flow-based, identity-aware, and have the capability to detect and prevent intrusion attempts. All at speeds that can scale to LAN environments and at price points that enable effective deployment of such a comprehensive solution across the network. I think it is just a matter of time before this becomes the accepted paradigm.

Shehzad Merchant

Technorati Tags: Shehzad Merchant Star Trek