Illuminations

The Most Important Piece of NAC

Tim Greene has written a nice Network World NAC newsletter article, "The most important piece of NAC". He has some good insights for customers deploying NAC, which I wanted to expand on. One of the major functions of NAC is to determine the end-point posture (anti-virus, anti-sypware, OS patches, Firewall setting, etc). This determination is typically done by the NAC agent through one of the following methods, with the various pros and cons of each approach as explained below:

1. Interacting with other client software directly as Tim and Joel Snyder have suggested in the article
   • Agent Type: Dissolvable or installable agent running on the end-point
   • Pros:
     • Very deterministic approach
   • Cons:
     • Need to establish partnership agreements with each vendor that provides an API
     • All AV/change-management vendors may not provide an API
2. Inspecting registry entries and/or files on the end-point
   • Agent: Dissolvable or installable agent running on the end-point
   • Pros:
     • No interaction/agreements with vendors required
     • Enables comprehensive vendor coverage
   • Cons:
     • Needs reverse engineering that can be tedious and time consuming
3. Inspecting registry entries and/or files remotely using WMI/Samba
   • Agent: Running on appliances based on Windows/Linux platforms respectively
   • Pros:
     • Truly clientless solution
   • Cons:
     • Requires administrative privileges
     • AV/change management vendors will not have APIs
     • Posture determination cannot be done for guests or contractors
     • Posture determination is very limited
4. Snooping network traffic to detect exchanges between AV clients and update servers
   • Agent: Running on appliances based on Windows/Linux platforms
   • Pros:
     • Truly clientless solution
   • Cons:
     • Posture determination is extremely limited

To summarize, the most practical solution is a combination of Methods 1 and 2. Any NAC solution that relies entirely on Methods 3 and 4 are not good solutions. In the next few posts we hope to explore this theme further, as well as how Microsoft's NAP fits into the scheme of things.

Amol Mahajani

Technorati Tags: Amol Mahajani Tim Greene Joel Snyder NAC

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

LAN Security - Revisited

Watching all the blogs and endless debates on pre-connect, post-connect, inline, OOB, NAC, NAP, etc. I wonder if we are really missing the point. So I thought for once lets not talk about out in-line v/s OOB, pre-connect v/s post-connect, NAC, NAP, etc. Instead, why don’t we just talk about LAN security?

So what does LAN security mean anyway? What it fundamentally comes down to is two things:

1. The services that the network offers, continue to stay up in presence of threats; and
2. The services can be accessed by only those users who have the right access privileges.

That inherently leads to really three facets that would comprise any LAN security solution:

1. Minimizing the threat envelope to the network. This is typically done by ensuring that whatever end system accesses the network, does not pose a threat to the network. Typically this is what constitutes the endpoint integrity check. However, from a LAN security perspective this is really about reducing the threat envelope to the network. This is not about making sure the endpoint itself is clean. Nor will this eliminate threats to the network and the services the network provides. Eventually this functionality will simply become an OS feature with the likes of NAP. Until then, intermediate solutions will continue to fill the gap.
2. Real time threat detection. Any threat to a network or the resources sitting on the network needs to be detected and eliminated in real time and on an on going basis. Both signature and anomaly based solutions working in conjunction provide this level of protection. Both are needed and any real time threat detection solution is incomplete without one or the other. At LAN speeds, I may add.
3. Network based enforcement of user’s access privileges. This is the identity based access control piece. With most enterprises now providing access to employees, guests, contractors, vendors, etc., the need to enforce “who is allowed access to what”, at the network level itself is critical. Regulatory and compliance issues add further demands in this direction. And the traditional methods of using vlans, etc. are simply proving inadequate. Flow based solutions, in fact application-aware flow based solutions are the order of the day. Once again at speeds that scale up to LAN environments.

So what does all this mean vis-a-vis, in-line, out of band, pre-connect, post-connect, etc. All it means is that when evaluating any LAN security solution, first you need to find one that has all the three components above. Anything less and your LAN stands severely exposed.

As I mentioned above, eventually I think item 1 will become a standard OS feature. Items 2 and 3 will become standard features on a switch port. In fact this is starting to happen, and such features have been available on a standard switch for well over a year now.

Shehzad T. Merchant

Technorati Tags: Shehzad Merchant NAC NAP LAN Security

How to Design a Secure Switch

What’s the best way to secure an internal network? When Nevis started three years ago with the goal of integrating switching and security, the big challenge was how to do it at all. You could adopt existing technologies such as stateful firewalls, IPS, and NBAD, but the important word here is stateful. Look at the traffic banging around a LAN sometime – random duplicated packets due to flooding, asymmetric routing (sometimes intentional, usually inadvertent), legacy L2 frames with proprietary framing taking liberties with 802.3, such as using the source MAC as an additional protocol field, spanning tree frames pouring out of access ports, things like that. Clearly you need to be at some kind of choke point. But most existing LANs have just evolved with little need for planning beyond capacity, thanks to Ethernet technology, so much so that choke points are hard to find and, in fact, are something to be avoided.

We also looked at the best practices of the day. I have to say that a real eye opener was Joel Snyder’s article back in 2003 on securing internal networks. The short answer was, unfortunately, you can’t get there from here. We then looked at some of the endpoint software solutions out there – despite the fact that we were told over and over that clients were an undesirable last resort – and many of these products simply took the same technology (stateful firewall, signature matching) and put it in the host network driver anyway. So, why not put this kind security at the access switch port? It’s a natural choke point, the point of user entry to the LAN (another crack in the perimeter, so to speak) allowing control over admission; you don’t have to trust that clients haven’t been tampered with; you can deflect attacks on the LAN itself such as FDB overruns; and you can centrally manage it all! Clearly this was the way to go. Why hadn’t someone thought of it before?

Well, there were some obvious answers. Access switches have become commodities, glorified punch-down blocks built from commodity ASICs available from multiple vendors, like Broadcom, competing on price and features, making them ever faster, bigger, and cheaper. But this also makes it hard to put in features that the vendors didn’t think to bake into their chips, like, security. You can put it in the control plane, even try to repurpose more powerful multi-processor ASICs as “security” planes, but this ultimately limits what you can do – LAN security is so tightly coupled with switching and inherently flow-based that it is a challenge to separate the two without compromising one or the other. You have to be able to track every packet if need be, and get packets through with minimal latency. Or you can use alternative data planes, like NPUs, but even if you could find a suitable one, it’s hard to match the system cost and performance.

Ultimately, we chose to design our own ASIC, taking the best ideas around, building on them, and adding our own innovations. It had to be able to do fast flow-based processing and be easy to upgrade with additional features. We made it fast and programmable, integrating features that facilitate doing switching at 10 Gig without compromising security, using accelerators for doing things like buffer management, in-line signature matching, hash lookups, and such, enabling it to quickly react to changing conditions during a connection. And we proudly shipped the product a year ago, the world’s first built-from-the-ground-up secure 48-port access switch - configured like a switch, not an appliance, and providing centrally managed, user-based access control policies with protection against malware.

I believe that we’ve played a pivotal role in the vision for secure switching by being the only company to purpose build a secure switching ASIC from the ground up.   Other companies have taken short cuts using more general purpose control plane processor architectures, but on the way they have sacrificed performance and functionality, and are missing features such as signature matching and encryption that are integral and critical parts of a secure architecture.

We’ve proven that Secure Switching can be done without compromising on either security or performance, so where do things go now?  Well, here we are, shipping our third software version and coming up with more and more ideas for better and faster solutions, including dreaming up next generation ASICs and accommodating new customer deployment scenarios, but my bottom line prediction is that, within twelve months or so, you will see the emergence of secure switches from major vendors and secure switching will have jumped across the proverbial chasm.

Joseph Tardo, Ph.D.

Technorati Tags: Joseph Tardo Joel Snyder

Built-in, Overlay or Something More Radical?

I like to keep up with what’s happening in the universities, and so I have a lot of research papers crossing my desk from time to time. Most don’t linger on their way to the circular file, at best making me nostalgic for graduate school days where R&D meant “relax and dream” (a phrase indelibly linked in my mind with Dave Cutler for some reason). But I digress. Recently a paper out of Stanford from last fall’s Usenix got my attention. At first glance I put it in the “interesting-but-impractical” category, it seeming to marry something like Radia Perlman’s rbridges with a “security plane” that supplies a policy decision for every connection. This policy server runs not distributed out on the switches, where conventional wisdom would put it, but on a central server where it can bottleneck everybody trying to use the network. Furthermore, it supplies a policy decision by giving each allowed connection a source route through the network and can’t possibly scale, much less support broadcast. But if people I respect like Nick McKeown and Dan Boneh weren’t embarrassed to put their names on it, it had to be worth a second read.

The grandly named “Secure Architecture for the Networked Enterprise” (SANE), aka ETHANE, actually makes a lot of sense in more ways than one. First of all, it is about time for a fresh new way of looking at LAN security. As I have said before and continue to say, policy is the problem, and SANE addresses policy head on. Secondly, looking at the ETHANE presentations and reading through the papers, a lot of thorny issues have been thought through (although some of the more difficult, rhyming with “forklift,” seem to be conveniently swept aside). But they claim to have a software prototype running on PCs, which is a promising start (personally I would have used multi-threaded programmable data plane processors and more caching, but you have to start with what you have). Finally, some of the advantages pointed out (hide topology from endpoints, single point of trust instead of the proliferation of trust in today’s retrofit solutions, addresses that can’t be spoofed) really resonate to a security guy.

This research represents the first good example I have seen of how to build security right into the network infrastructure, maybe even a breakthrough. I’ve seen lots of “overlay” proposals and products that try to leverage today’s switched infrastructure investments – put everyone in their own private VLAN and bring them up to some humongous security blade, use out-of-band NAC products that dynamically reconfigure port VLANs on switches, isolate classes of users with IPsec overlays, even the in-line transparent security bridges that companies like Nevis sell, which I personally believe are the best alternative available for today’s LANs – but none represent long-term strategies that really integrate security into the infrastructure. And everyone who has just paid for their switch upgrade wants to put off acknowledging the 800 pound forklift entering the room for as long as possible.

Eventually today’s NAC will evolve into a “secure network fabric,” as some people have already pointed out. Who knows, maybe in the future, networks will look a lot more like SANE than we are ready to think, and we’ll look back on today’s LANs as insecure dinosaurs.

Joseph Tardo, Ph.D.

Technorati Tags: Joseph Tardo Stanford ETHANE Nick McKeown Dan Boneh Radia Perlman NAC IPsec VLAN