Illuminations

More NAC confusion and FUD in the press....

Tim Greene's recent article "NAC may find its niche as a supplement" announces that in-line devices will not be the main choice for enterprises moving forward because of:

1) the number of boxes that you need to proliferate throughout the network for an in-line solution

2) the adoption of 802.1X in network switches since NAC first came along

3) the introduction of Microsoft NAP

Let me address these points with some degree of fact, rather than opinion and speculation.

1) We are an inline vendor of Identity Driven LAN Security solutions that include NAC as an element of the feature set. We have successfully deployed our solution in large global deployments that include fortune 500 companies and span >40,000 active users.  We have done this very cost effectively with fewer appliances than specified by OOB vendors in the same competitive bids.  Contrary to popular belief you can in fact put a Nevis in-line appliance in above disti or in the core, or better still use your existing switch refresh $$ to buy Nevis secure switches in the wiring closet which means you've done away with the additional cost of OOB software, hardware, licenses, etc. 

So the first point to make here is that OOB does not mean you can add one box to the network for all users.  In most cases network topologies will dictate that you need many OOB appliances and then the limitations on user count per appliance further impacts the equation.  The reality is that OOB is often more expensive and cumbersome to deploy.

The other point to consider is that enterprises are very often looking for more than just the pre-connect Network Admission Control that most OOB solutions provide, particualrly when they want to scale the solution to include employees as well as business partners, contractors and guests.  To get this functionality from an OOB solution I have to have a bunch of other supported elements (switches, IDS/IPS, Firewalls, etc) that I then have to hang together with complex interoperability, deployment, maintenance and policy issues.  I've said it before and I'll say it again.  The hidden, dirty little secret of the OOB approach is that reliance on VLANs and port based ACLs in switches for post connect access control enforcement means that what used to be a simple network topology change now has a new NAC policy dimension to complicate things.  Things are probably ok if you stick to the Guest/Employee VLAN model, but start to get more granular than that, and start wanting to add a little more granularity on the ACLs that are enforced, and all of a sudden you've got a full grown oak tree to prune where you thought you had a bonzai tree.  Group based L2-L7 policies, enforced independently of the network switched and routed infrastructure remove this dependency and complexity. 

2) For the rebuttal on the tired old 802.1X assertion please start by reading the great article that our own Gary Kinghorn just had published in Enterprise Networks and Servers.  Gary did a lot of research within the analyst community and with customers when writing this article and found that while the technology is there in the switches as Tim points out, implementing it has so many costs and pitfalls associated with it that very few people are implementing it in the short to medium term.  If it is a requirement for a NAC solution then I would argue that the vast majority of Enterprises, particularly in the mid tier, won't be rolling out that NAC solution any time soon.  I'd also refer you to a Nevis white paper for further discussion on how 802.1X compares, contrasts with, and can also be a part of, a Nevis Identity Driven LAN Security solution.  802.1X will have it's day, but the fact that the OpenSEA Alliance was founded should give you some indication of the problems that still have to be overcome.

3) We have advocated interoperability with Microsoft's NAP from the very early days and have shown our strong commitment by actually putting in the effort to do development work while others just talk to it.  Our feeling has always been that NAP will become the dominant Network Admission Control technology, which is why we provide a solution today that can interoperate with it.  We can also add tremendous value to the NAP framework rather than providing the significant overlap that OOB solutions give.  What do you do about non-windows or legacy endpoints for instance?  How will you ease the transition to a full corporate roll out of NAP while getting the protection you need in the short term?  How will you secure against network born threats?  How will you cloak network resources from sophisticated attackers in the network?  How will you ensure that your network is intelligent enough to recognise, authorize, prioritize and control the applications that use it?

Anyway, I have pontificated enough.  The simple message here is that there is another side to the story that Tim Greene published and it's not "the Dark Side" that's been portrayed.  Besides everyone knows that marketing is the Dark Side and that Darth Vader was the VP Marketing for the Empire. Don't they??

//Dom

Peer to Peer: Can't live with it; can't live without it

Who can survive without p2p today? P2P has enabled an explosion of sharing music, movies, software, etc. The Recording Industry Association of America's overwhelming threats of copyright lawsuits and fines have not been able to stall the growth of file sharing but rather have forced p2p to become more robust, stealthy, and sophisticated. Studies by Cachelogic and BigChampagne show that p2p file-sharing continues to grow. Due to the scalability and reliability properties of decentralized p2p architectures, Vudu is developing a movie on-demand system that is based on p2p. Unlike file sharing, Vudu has many studios signed up. P2P is also moving into the enterprise setting with p2p-based collaboration tools and p2p-based storage systems. A recent study shows that the p2p-based Skype outperforms MSN’s centralized approach. Among the ways in which Skype achieves improvement over MSN is its ability to burrow through firewalls and NATs. On the other hand, this same resilience to firewalls and NATs can be a security nightmare.

In a p2p network, there is no notion of a client or server. Every node can perform both functions and the aggregate of the end-hosts form the p2p network. In order to form this network, most of these p2p applications start up by scanning for other systems running the application. A robust p2p application scans intensely and persistently; looking exactly like malware. State-of-the-art scan anomaly detectors rely on the evidence that the scanners do not have knowledge about the network topology and system configuration; hence they are more likely to make failures than successes. However, these techniques will detect p2p scans as a malicious scan. The detectors need intelligence to make a distinction between benign application scans and malicious scans. The traditional detectors can fix the problem of p2p false positives by tuning the thresholds. However, p2p applications such as Skype can scan up to a few hundred hosts in a short time interval. Keeping thresholds high enough to support this behavior will undoubtedly result in false negatives. The solution to this problem is to identify p2p application scans and treat them differently.

Signature-based application recognition will not solve the problem of false positives with scan detectors. For applications such as Skype, the signature only matches after the host connects to another peer successfully; that is, the signature can only be matched after the scan, at which point the alarm is already raised (unless the detector is delayed, which dramatically limits the detector's effectiveness). A reasonable p2p application will encrypt all communication, and hence, it limits the signature-match capabilities. In order to navigate dynamic access conditions (e.g., when the host is mobile), the p2p application tries a wide variety of ports and protocols. This makes it hard to rely on port-protocol pairs for detection. Regardless of the difficulties, Nevis has behavioral anomaly based solutions to address this problem.

P2P problems don’t stop with false alarm mitigation. P2P networks may span millions of hosts, and enterprise p2p systems may span critical systems. Thus, a worm that spreads over a p2p network could be highly effective. Stopping such worms is also possible with p2p-aware detectors. P2P is yet another application. Once identified as a p2p application, anomaly detection can be performed in the same way it is done with any other application. Another problem with p2p applications is that botnets may pose as p2p networks, complicating their identification.

P2P is here to stay, but while it poses security challenges, solutions exist.

Khushboo Shah, Ph.D.

Technorati Tags: Khushboo Shah Cachelogic BigChampagne Vudu Labs Skype P2P