Illuminations

NAC deployments under scrutiny...

Lisa Vaas over at eWeek is reporting on a new NAC survey coming out of the Aberdeen Group. In Carol Baroudi's "Who's Got the NAC? Best Practices in Protecting Network Access" report (it's free if you discount the sponsor sending bugging you for the next few weeks), she surveys close to 400 NAC adopters and attempts to benchmark who is doing a good job of controlling access to their networks (while also reviewing some the processes and technologies they are using). It's interesting reading and reviewing the deployments rather than the technologies and vendors is a refreshing take on a NAC survey.

Here's the take away for me. Those who are considered Best in Class in the report have a strong focus on a holistic approach to NAC and prioritise the post-connect functionality and the need to persistently monitor and control endpoints and users in a meaningful way after they get on the network (and we're not just talking about doing an endpoint posture check every 10 minutes). They also believe that operational considerations and the end user experience are of paramount importance to success.

Here is what those Best in Class organization say are the most important things to expect out of a NAC solution:

- Prevents unauthorized users from accessing the network
- Causes minimal operational impact on users, help desk and network performance
- Supports/enforces policies specific to different user groups
- Logs all network access events for auditing
- Prevents unauthorized devices from accessing the network
- Centrally records all events
- Can be installed without directly impacting network performance
- Is transparent to the user
- Supports enforcement for remote users
- Can quarantine unhealthy machines without cross-infection
- Assesses endpoint security status

This certainly gels with what our customers are telling us as well. I think point number 2 is where most NAC solutions fall flat on their faces. Most vendors have given very little consideration to getting the solution into the network seamlessly and ensuring there is a transparent user experience. I'm proud to say that our customers have no such worries. If you'd like to read an impartial, blow by blow, daily account of the evaluation and operational deployment of a NAC product into a sizeable production network, head over to Justin Gerharter's blog at www.bumpinthewire.com

//Dom

Welcome Parveen....

So, I see Consentry have a new President and CEO. No announcement, just quietly slipped onto their website Management page. Does this mean that the fanfare and fireworks over their new round of funding had a bittersweet side (where did Tom go?)? Interesting to see that Parveen comes most recently from a fundamental security player (McAfee) and was the founder and CEO of IntruVert, an IDP player. I think they've realised that to be a credible secure switching or LAN security solution you do have to put the fundamentals into the security piece of the equation. Nevis made the investment early on and have maintained that with a cadre of Security educated PhD's and researchers who contribute to the security community on a daily basis, alongside a strong team of networking engineers. To realize the vision of security ubiquity in the network fabric you have to be able to talk the talk and walk the walk.

Welcome to the LAN Security market space Parveen. I look forward to meeting you and hearing your perspective on the evolution of enterprise networking and security.

//Dom

Is Secret Sharing for Convenience Really Keeping a Secret?

I grew up with the maxim “security by obscurity bad, real security good” ringing in my head.

That’s why I find it so hard to be amused when I hear arguments that obscurity can provide security if it is more “convenient.” And then I see products that actually embrace security-by-obscurity-for-convenience out there in the market – and being shipped by companies claiming to be security vendors.

This has come up recently in the context of captive portal login certificate warnings. The beauty of captive portal is that it uses a standard Web browser as a nice GUI for someone logging in. Since it talks to a more or less standard Web server, the way to secure passwords sent over the link is to use TLS. But to use TLS, the server needs a public key certificate, and browsers want (or, should want) to verify the names in these certificates and who issued them, mostly for Web commerce but in this case to protect against password sniffing or classic spoofing attacks.

Many products provide a throw-away temporary certificate for evaluation purposes. This almost always is a self-signed certificate so that customer’s passwords are at least encrypted using a new private key for that deployment. But this gives a browser warning about the certificate not having been issued by a known CA.

So some products try to avoid this major inconvenience by using HTTP as the default. Since this is clearly insecure and most customers will want to turn on TLS, these vendors oblige by shipping a “free” certificate. This way customers don’t get the nasty warning and will see the padlock (if they care), and on newer browsers don’t see red backgrounds in their URLs. End of story, security restored.

Unfortunately, it isn’t. These products get rid of the warning by using a vendor public domain name and baking the same certificate into their software. That means everybody has the same private key, too. How many of these customers actually click on the browser padlock and view the name in the certificate? Do you do this when you go to your bank or order on Amazon? Unfortunately, too many people aren’t in the habit.

I was taught that a secret shared with everyone is not a secret at all. If you’re going to provide a security mechanism, do it right – make it clear that what’s shipped by default is strictly for evaluation and let people put in their own real certificate.

That is, if they care about security in the security product they are purchasing. Isn’t that the whole point?

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.

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