Network Node Validators

Everyone Wants A Piece

A dizzying number of vendors claim to own some piece of the future network-access control puzzle: Desktop firewall, legacy routing and switching, antivirus and vulnerability-assessment companies have piled on, and a slew of start-ups have launched new appliances. Some people even toss Microsoft, with its NAP (network-access protection) plans, into the mix, and though we disagree with that, NAP will have its place.

To be fair, given the scope and nature of the problem, many vendors making claims have valid roles to play; the rogue- and noncompliant-device headache requires both host and network components. Host pieces provide visibility you can't get from the network without login credentials, and the network must have some "smarts" to react when a bad host won't play by the rules. There's no single solution to this problem, and don't let anyone tell you otherwise.

Plenty of technology approaches will help. However, we focused on those that will be baked into existing infrastructure devices. This "embedded" approach represents the move away from standalone security products to existing IT products that use security features as differentiating factors--a trend we predicted: See "The Inevitable Commoditization of Security".In one corner, we've got Cisco Systems pushing its NAC (Network Admission Control) technology, which has less to do with a specific product and everything to do with a framework of protocols, services and next-generation access-control features.

In the other corner we've got dozens of competitors, all with different approaches but seemingly unified on one point: They're critical of Cisco's NAC. This shouldn't surprise anyone: The 8,000-pound gorilla is going to be a target. And to the naysayers' credit, we found some criticisms are valid. Cisco's NAC uses proprietary protocols. Cisco's NAC does depend on agent cooperation. Cisco's NAC doesn't run on all legacy switching platforms.

NETWORK ACCESS CONTROL
Immersion Center

NEWS | REVIEWS | BLOGS | FORUMS TUTORIALS | STRATEGY | MORE

But other criticisms are invalid, and often downright false. In fact, we were surprised to discover how much misinformation is out there about Cisco and NAC. For example, you don't have to replace all your Cisco equipment (only certain devices); you don't have to run the Cisco Secure Agent IPS agent (you can use the Cisco Trust Agent, which is free); Cisco's protocols aren't all proprietary (Cisco says it's in the process of releasing many of them into standards bodies and is distributing the specifications to third parties). The list goes on. That's not to say Cisco's approach is flawless. Far from it, and we'll show you where NAC struggles later in this article.

Finally, in talking with major network infrastructure players like Enterasys Networks, Extreme Networks and Foundry Networks, it's clear they recognize security must play a bigger role in their futures. Most have partnered with Sygate (now Symantec) to deliver part of the posture-and-identity setup; this has let them to compete on some levels with Cisco's NAC (see "The Sygate Curveball"). They're also working on integrating other legacy security technology (IDS, network traffic anomaly detection, denial of service detection and so on) into their existing gear, which will help in certain cases. But Juniper, thanks to a clever repurposing and expansion of its SSL VPN technology, is the only legacy infrastructure player besides Cisco that's really innovating in this arena. Is that to say you shouldn't consider other vendors? Certainly not, but we think they're going to have a rougher row to hoe because Cisco is pushing much of its new technology out the door for free.

After spending months with beta technology from these vendors and attempting to understand a dizzying array of features, protocols, design considerations and use cases, we're convinced there isn't a "one size fits all" approach in this technology. Use cases specific to your organization should be the primary consideration factor (see "Name Your Use Case", below left).

Organizations that need a quick path to mitigating the threat of traffic from rogue nodes entering their data centers, for example, are likely to gravitate to Juniper's Unified Access Control (UAC) suite; it's easier to deploy and less intrusive than many alternatives. Provided you're comfortable putting access-control devices in front of your data centers, Juniper's lightweight approach will be attractive, especially to companies that aren't looking to make major infrastructure changes or upgrades.

In comparison, organizations that are more concerned about client-to-client-based attacks and clamping down so rogue nodes don't ever set foot on the network in the first place--an area Juniper's model doesn't address well--should look at Cisco's approach--if they have the time and patience. A full Cisco NAC implementation is a complicated, intrusive process, but it's also comprehensive; NAC can address significantly more use cases than anything else we've seen.

Finally, ConSentry's LANShield offers an extremely lightweight (no agents!) method of mapping relationships between authenticated users and Layer 7 network applications, and performing some basic enforcement tasks. LANShield might one day be a good match for organizations that have only those needs. But it's immature at this point and has a long way to go before it can tackle a significant subset of the challenges that, say, Cisco's NAC addresses.

Before evaluating each approach, it's important to understand the components used in these NNV and enforcement technologies, and to keep in mind the complications surrounding specific use cases. We went over the high-level node-validation components in "But Will It Work?," page 34, and we'll continue to use the agent, authorization server and enforcement point terminology. Expanding on that list, the concept of a managed versus an unmanaged node, or "asset," is worth noting. The managed designation denotes, as in the network-management world, a device you have administrative access to or control over, while an unmanaged asset typically is something on the network that is up and running, over which you don't have easy--or any--administrative control.

In the node-validation world, a managed asset is something supported with an agent, while an unmanaged node or asset is unsupported by the agent technology, for example, a Mac OS X client in a network that only has Windows agents, or is not actively running an agent.

Also noteworthy is how all these approaches tie back to existing directory and user stores. Most approaches rely on RADIUS as an underlying communications channel to talk to back-end directory services. This is critical: No sane organization will want to maintain user and group mappings in yet another location. This communication is established by the authorization and authentication server (Cisco Secure Access Control Server in the Cisco model, Juniper Infranet Controller in its model) after it receives communications from endpoint agents. Authorization servers act almost like proxies, in a sense, but do so by translating and relaying protocols, sometimes in multiple stages. In Cisco's Layer 2 NAC model, for example, the agent passes posture information to the switch over 802.1x frames; the switch then relays the data payload from that communication to the Cisco Secure ACS server (the authorization component) over RADIUS; the Secure ACS server might then make additional queries using LDAP or HCAP (Host Credential Authorization Protocol) to additional back-end, third-party servers. Cisco's Layer 3 NAC uses a similar model, but forwards posture information to the routers using EAP (Extensible Authorization Protocol) over UDP. Keep in mind that for all this to work flawlessly, all components must be up, running, available and communicating. Fun, huh? Although we didn't have any problems in our tests, organizations must gain technical expertise in multiple new areas to support this technology.

When all's said and done, Juniper and Cisco share two architectural musts: First, if the authentication and authorization communication pathways and servers aren't available, you'll face real problems; placement and redundancy of the authorization components is critical. Without access to authorization servers the entire model breaks. Second, first-level support teams must see into the infrastructure for troubleshooting. In comparison, the model that ConSentry uses, while less functional, dodges the availability bullet in that it doesn't rely on external authentication stores to grant or deny access; it simply pulls credentials off the wire and makes decisions based on its rule sets. Once again, use-case considerations are critical.

Cisco has announced Phase II of its NAC technology, which brings NNV functionality to its switching line, and we were fortunate to be able to evaluate a number of the components before they rolled out. Cisco's initiative touches dozens of product lines, and consists of new functionality in switches, routers, authentication servers and host agents. We found Cisco further along than the other vendors--it's shipping its second generation of the technology this month, it has enforcement capabilities in both its routing and switching product lines, and it has more than a dozen partners shipping NAC-enabled products.Cisco shipped us a rack full of NAC-enabled gear that included Cisco Catalyst 2950, 3560, 3750, 4948 and 6503 switches; the MARS SIM appliance; a dozen VMware server images; a Qualys QualysGuard vulnerability scanning appliance; and the Cisco Clean Access product suite. It was important to look at a wide range of products--there are a lot of pieces, and many of them address different needs. For example, Layer 2 NAC-enabled switches can help keep rogue nodes from getting any type of foothold on the network, while Layer 3 NAC-enabled routers might be used to validate the identity of individual users operating through remote locations.

When our Cisco contact told us that "NAC is more of an initiative than a product," our cliché alarms went off--we typically group initiative with solution, resonation and traction. But after looking at its devices and wrapping our heads around a hefty number of new protocols, we're somewhat convinced: NAC is comprehensive, and with that breadth comes much complexity.

For starters, Cisco has developed a gallon of alphabet soup's worth of new protocols to allow communication among devices: GAME (Generic Authorized Message Exchange) for tasks like triggering network scanning events; HCAP for passing contextual information; EAP over UDP and 802.1x for allowing the Cisco Trust Agent (the agent component) to communicate posture to devices; and the list goes on. These foundations must be in place if there's any hope of this admission-control dream taking hold in cross-platform, cross-vendor environments.

At the same time, protocols that haven't gone through IETF or IEEE standards processes tend to make IT people nervous, and Cisco's competition was quick to point out the lack of standards. We pressed the vendor on the use of "proprietary protocols," and got an earful.

"We have stated since the introduction of NAC that we would work in the open forum to standardize all the protocols relating to NAC," said Russell Rice, director of marketing at Cisco. "We are working with other vendors to begin this process in the IETF in 2006." Time will tell if Cisco holds true to its word. We'll keep an eye on it.

With Phase II of the Cisco NAC push, Cisco has brought much of the NAC functionality to Layer 2 devices; upgraded the Cisco Secure ACS server to version 4.0; and updated the Cisco Trust Agent to 2.0, which now includes 802.1x wired support, a Red Hat Linux port and the ability to author your own posture checks. Many Cisco switching lines now can use the Cisco Trust Agent to pass identity and posture information up to the network at a switch level, and allow a NAC-enabled infrastructure to take actions accordingly (see "NAC Switch Support," left).

For example, suppose you're facing a new Windows vulnerability that has a high chance of being "wormable," and you're unsure whether all your users will be patched in time. You might create a policy that looks for the presence of a specific patch, and grant nodes full access to the network only if they have that patch deployed. You might simultaneously place all nonpatched nodes onto a remediation network, or allow those nodes to go only to www.windowsupdate. com. Before Phase II, only part of this functionality was available using Layer 3 NAC, and only on routers.

We tested some Layer 2 functionality by creating a policy in the Secure ACS server that looked for a specific version of a DLL, and placed the node into our quarantine VLAN if the file wasn't present. It should be noted that there's some important context information needed for this task to work: We had to specify the exact file or registry key we wanted to look for. This specificity isn't a problem if you're looking for one or two things, but simply saying, "Must have updated antivirus file," or "Must have latest IE patch" is more problematic. Many organizations won't have the necessary file checksums and registry keys for every patch or update they want to require. To gain a holistic posture-checking ability, Cisco requires integration with a NAC-enabled patch-management system, such as Bigfix or Patchlink, or the more self-contained Cisco Clean Access (CCA) products.

CCA, which joined Cisco's portfolio through its Perfigo acquisition in late 2004, delivers Layer 3 NAC-like functionality but does so using an inline appliance that has its own agents, authorization mechanism and management infrastructure. We tested CCA briefly by setting up a CCA appliance inline in a remote-access model, and much like its Juniper counterpart, the device temporarily blocked our PC, forced us to deploy an agent and then queried our node for a number of posture requirements we had defined.Unlike the base NAC offering, CCA has a subscription service that pushes down security context data, such as file names and software update versions, including antivirus builds, so that policy decisions can be configured easily. CCA gave us an immediate, relatively easy way to create and enforce "Must have x patch" or "Must have x antivirus image file" policies without forcing us to hunt down technical details. CCA also can instruct its agents to run certain patches or software packages, making remediation efforts simpler. These features are standard in CCA.

In contrast, the combination of a standard NAC-enabled router or switch, the free Cisco Trust Agent and the Cisco Secure ACS server gives organizations a powerful framework, but moving that framework to something that has a clear, tangible result takes some manual work or integration with third-party products.

Confused yet? So were we. Cisco will tell you that it has two different offerings--NAC and CCA--for different organizational needs, but we think this is a case of postponed digestion: CCA is an acquired technology, and Cisco hasn't had time to integrate it yet. This isn't surprising, considering it's been less than a year since that acquisition took place. It'll be interesting to see whether Cisco brings the context data to the base NAC offering and collapses the two technology lines into a common platform. That question also raises all sorts of business issues for Cisco: Will such a move cannibalize CCA's revenue stream? Will that upset other partners? Or is this a nonissue? We'd like to see the standard NAC offering inherit CCA's functionality, but until these two are truly integrated and combined into one product suite (with one agent model), this part of Cisco's offering is going to appear fragmented.

Cisco has a few other challenges, too. The alerting and troubleshooting interface in Secure ACS is abysmal, and we couldn't find an easy way to provide better visibility to non-network folks, like the helpdesk, that would let them easily troubleshoot admission problems. Cisco's acquisition of Protego, a lightweight SIM of sorts, helps provide basic reporting for events, but Protego's more a reporting and monitoring engine than a troubleshooting console.

Cross-platform support for agents is also a challenge. Cisco claims Mac OS X support is due out in 2006, and Linux support should be shipping by the time you read this, but at the time of our testing the CTA was a Windows-only agent. In addition, Apple doesn't seem to want to include a method for easily prompting the user for 802.1x credentials interactively, so part of the challenge for Cisco--and all NNV vendors, for that matter--will be convincing Apple to start playing nice on the 802.1x front. To Cisco's credit, it has begun using conventional vulnerability-assessment-scanning technology to help deal with "unmanaged" assets and nodes that do not (or cannot) run agents. For example, we instructed the QualysGuard appliance through the Secure ACS server to launch vulnerability scans against agentless nodes. Using the GAME protocol, the Secure ACS server exchanged information with the Qualys server and made authorization actions based on the data that came back from the scan. Of course, network-based vulnerability scanning is still limited in what it can accomplish, but it's better than trying to make admission decisions based on nothing at all!The ACS user interface, however, is confusing. It's one step up from a command-line interface, and at some points, we almost would have preferred a command line. Cisco is clearly struggling with how to organize all this information, and we'll admit it's a hard problem--we don't envy Cisco's position. But if Apple can slap a slick UI onto a Unix OS, Cisco should be able to piece together some magic for a single software package. We hope Cisco wises up and ditches the raw HTML interface; there's a reason we don't manage our Microsoft AD infrastructure using a Web browser--HTML can only go so far.

Finally, though not necessarily a problem, doing your prep work before diving into NAC is critical. Where will the Cisco Secure ACS servers be housed? How many of them, and at how many sites? NAC software builds for devices and CTA agents are free, but Cisco's Secure ACS software starts at $8,995 per server or $12,995 for an appliance. Also, is there an existing global quarantine VLAN in place, or must one be created and deployed? Once a node is quarantined or denied access, what operational procedures are in place to handle that event, and is there a process to provide that alerting and reporting? Cisco is on the right path, but it's got some work to do before NAC becomes operationally friendly.

Cisco Network Admission Control. Cisco Systems, (800) 553-6387, (408) 526-4000. www.cisco.com

Juniper's approach to the NNV conundrum can be summed up in two words: Simple and straightforward. There isn't as much to Juniper's UAC as there is to Cisco's NAC, though that's not to say it won't be effective for the use cases it's going after. In fact, quite the opposite--in some organizations Juniper UAC has a better chance of being successfully adopted than NAC simply because it is less complex. Much like Cisco's NAC, Juniper's UAC technology is heavily based on marrying one's identity with a system's posture. However, Juniper's approach is more "choke-point" oriented in that it relies not on existing infrastructure like routers and switches, but instead on the strategic placement of high-speed, enhanced firewall devices.

Juniper's model is based on the repurposing and further development of two of its core technologies: host-checking components from its original SSL VPN agent and the supporting validation framework, and its industry-leading enterprise firewall line. At the heart of the system are the agent and IC (Infranet Controller) components. The IC is the authorization component, which plays a similar role to Cisco's Secure ACS server in the NAC model. The IC takes data from the endpoint agents, makes decisions based on predefined policies, then instructs the IE (Infranet Enforcer, the enforcement component) to take appropriate actions. The IE is the enforcement device placed out on the network in critical choke-points. For example, if an IE were placed upstream from a bunch of edge switches populated by end-user segments, an enforcement strategy could be devised where the IE restricted (using conventional NetScreen ACLs) node access based on the results of endpoint-validation mechanisms through the IC. This approach obviously doesn't address end user node-to-node-based attacks, but it can prevent problems from spreading outside of user segments and compartmentalized networks.

For our tests, Juniper shipped us one IC and an upgraded ISG-2000 firewall that was used as our IE. Although it may seem like a simplistic way of looking at things, our Juniper gear occupied only two rack slots, about 5U. This made us happy. No complex authorization servers, no Windows server buildouts, no cross-party communication channels. The IC can push agents down to clients using browser-based delivery.

Out of the box it took us less than 30 minutes to get the IE and IC up and running. The installation process was easy. The only pain was messing around with certificates--we had to generate them, then deploy them on both the IC and IE components. As SSL grows in popularity, management challenges stemming from increased reliance on PKI/certificates are inevitable; we can't fault Juniper for this--it simply goes with the territory.

We placed our IE in front of a network we wanted to verify access to, and after the IC and IE were communicating we set up some basic rules that enforced validated access. The agent can be downloaded over a Web browser from the IC, and after installation the agent relayed posture information back to the IC for authorization. From there, the IC communicated with the IE on an encrypted channel, and essentially reprogrammed the IE's rule set to allow our IP address access to the protected network. In our test environment, the whole scenario was straightforward.

Juniper's node-validation components are more comprehensive than the base Cisco NAC offerings. From the IC we could easily define policies based on node health, such as patch levels and antivirus versions. Cisco's Clean Access platform allows similar functionality, but it cannot instruct other parts of the infrastructure to make additional adjustments; CCA relies on its own appliances to perform access-control tasks. It's the one-two punch of having an agent and intelligent authorization server, with a multi-Gbps traffic-enforcement engine, that gives Juniper a real advantage over much of its competition. Few firewall vendors have achieved this level of integration, and we don't know of any that can approach the 10-Gbps barrier and still retain integration. With the new 10-Gbps modules for the NetScreen 5000 series firewalls, Juniper is now shipping a device that it has rated at 30 Gbps, making the potential for data center deployments a reality.The agent itself is also well-designed; it can query a wide range of components (files, registry settings, running processes) and optionally can be configured not to run under an administrator context. Juniper has figured out how to bring SUDO-like functionality (click here if you're not familiar with *nix's sudo) to an agent model--that really impressed us. Using a single-purpose service agent that offers an API, Juniper has an agent update mechanism that doesn't add another network-accessible listening process to the endpoint, which in turn doesn't increase the endpoint's external attack profile. By invoking the update agent, the Juniper agent can be upgraded without admin rights. Simple, but clever. If only other agent vendors would follow suit.

Pricing for the Juniper system depends on the number of concurrent endpoints that need protection. The IC 4000 supports from 100 to 3,000 simultaneous endpoints, and pricing ranges from $25,000 to $160,000. The IC 6000 supports from 250 to 25,000 simultaneous endpoints, and pricing ranges from $60,000 to $390,000. Both models support clustering.

The downside? Organizations must be comfortable with a choke-point model, and Juniper's approach addresses only some use cases. For example, Juniper's model will not comprehensively prevent node-to-node attacks; to mitigate that threat scenario you must block the node before it gets past the switch port. In addition, Juniper doesn't have the framework to support or communicate with other vendors; the IC and IE are designed to communicate only with Juniper products right now. But to its credit, this simplicity is what allows Juniper Infranet to deliver a lot of functionality from the get-go.

Juniper Unified Access Control Suite. Juniper Networks, (866) 298-6428, (408) 745-2000. www.juniper.net

Start-up ConSentry Networks has taken a conceptually simple yet innovative approach to NNV by introducing an inline device that sits above the switching infrastructure's "edge" layer and inspects traffic on its way up to the network core. While still in its infancy, the ConSentry LANShield is a purpose-built appliance that leverages FPGAs (Field-Programmable Gate Arrays), as many as two dozen fiber or copper ports that can support inline bridge or mirror modes, and a "128 core" processor MIPS architecture. Put another way, the unit has serious CPU horsepower. ConSentry says it can monitor and forward traffic with Layer 7 intelligence at 10 Gbps. Currently, however, the product is more IDS/IPS-like in its capabilities, with the only implemented twist being the ability to understand actual users and not simply IP addresses.ConSentry's implementation is even simpler than Juniper's in that it has only one operational component: an inline appliance. The appliance and its supporting management console (a Windows system running a Java app) are the only necessary components--we didn't even need agents! However, with that simplicity comes less functionality; ConSentry's approach will be best suited for organizations that want to map users to applications and perform some basic inline blocking using firewall-like rule sets.

We've had an early unit in our lab for a few months now, and after some initial troubles involving an older hub, we finally got it deployed and working. Right off the bat the unit started acquiring all sorts of network data, including traffic levels, protocols being used, authenticated users on that segment and more. A unique aspect of the product is that it goes through steps to try to tie users to specific applications. It does this by passing traffic through various protocol engines that look for authentication strings. For example, when we logged into the Windows domain from one of our workstations, the device intercepted our NTLM authentication credentials and interpreted our login ID (just the user name, not the password). From that point on, it knew that the node at 10.1.1.105 was gshipley's machine, and when viewing packet and event logs this ID was clearly displayed. Although the approach sounds--and arguably is--simple, anyone who's managed a firewall or IDS knows that today's products continue to struggle with bringing these pieces of data together.

So does this approach help with node validation? Only partially. The LANShield isn't designed to force endpoints to authenticate; it could theoretically be built out to include better posture analysis, but it doesn't offer that functionality. In its current form it does little more than tie applications to user names and provide some application-level blocking capabilities--for example, don't allow x to use IM. It's definitely useful, but mapping your specific use cases will be critical to mining its true value. It's also a bit pricey right now--MSRP for the 24-port unit we tested (supports 12 segments) was $27,995. We look forward to seeing what the company develops on the software side of the product, but in its current form it addresses only a small subset of scenarios.

LANShield CS2400. ConSentry Networks, (866) 841-9100. www.consentry.com

After living with NNV technology for a few months, it's apparent that the problems it addresses are compelling--it's our best hope of regaining much-needed control and visibility in today's enterprise environments. We think adoption of these methods, or methods similar to these NNV techniques, will become de rigueur. And with parts of the technology getting "rolled into" many of the standard products we're already buying, it's time to at least start investigating the functionality. Wise IT organizations will be getting their heads around how NNV will affect them operationally sooner rather than later.The technology also forces buyers to ask some hard procurement questions in the short term, even if their companies aren't taking the plunge yet. Cisco is bringing this debate to our doorsteps today: Neohapsis' Chicago facility recently started upgrading its lab to 10 Gigabit Ethernet and its production environment to 1-Gbps Ethernet. Part of that upgrade involved replacing older edge switches. When we started pricing out stock 10/100/1,000 copper Ethernet switches, it was hard to beat Hewlett-Packard's ProCurve series; these boxes had the standard features we wanted (SSH console access, SNMPv3, 802.1x support), and the street price was half that of equivalent Cisco units.

However, three months after purchasing the ProCurves and spending weeks playing around with NAC-enabled Cisco switches, we found ourselves asking, Should we have sprung for the Cisco NAC gear? Even if we're not ready for NAC yet, having the option to turn it on when we are ready is a comforting thought. What's that comfort worth? We're still debating. For better or worse, we suspect that's exactly what Cisco wants us to be asking. Still, regardless of motive, it's a question that needs to be considered. We likely won't be the only ones scratching our heads and checking for budget wiggle room.

Ultimately, each organization must make its own call on when, how and where to implement NNV and enforcement, and there is still a healthy amount of maturing that needs to happen. For those who want to move soon, there's a good range of options out there to accommodate varying design requirements. But one thing is for darn sure: We need to be doing NNV, and the sooner we get it going, the more control we'll regain.

Greg Shipley is the CTO of Neohapsis, an information security consultancy and enterprise IT product-testing lab. Write to him at [email protected].

When we first started investigating NNV (network node validation) efforts, we assumed this was an infrastructure-only game. We knew there'd be host-level components for helping assess an endpoint's health, but we figured the bulk of the "smarts" would be baked into the infrastructure devices.We were only partially correct. Infrastructure gear must support protocols like 802.1x and enforcement mechanisms, but much NNV decision-making is done elsewhere. After spending some time with racks full of this next-generation gear, we realized this new combination of 802.1x- and RADIUS-based re-encapsulation isn't necessarily vendor-specific. The technique winds up, from a design perspective, pushing the intelligence off onto two other points: the endpoint agent and the upstream "authorization" component.

Sygate, which was recently acquired by security consolidator Symantec, has been in the endpoint-protection business for its entire existence. Although its endpoint-management technology is some of the most mature on the market, boasting customer deployments of more than 100,000 internal nodes, the company recently started shipping RADIUS-enabled authorization servers, dubbed Sygate NAC (for, in this case, network access control) that could deliver a lot of the functionality found in, say, Phase II of Cisco's NAC initiative. Plus, using the RADIUS-802.1x combination, Sygate has successfully implemented the basic VLAN assignment and quarantining approaches found on a multitude of switching platforms, including those from Enterasys, Extreme Networks and Foundry Networks, making Sygate NAC cross-vendor-friendly. Unfortunately, Sygate's product lacks Linux or Mac OS X client agents, which puts it in the same boat as the other initiatives in the shortcomings department.

Unfortunately, we were unable to test Sygate's suite in action, but we hope to do so in the coming months. Regardless, it will be interesting to see how Symantec integrates this technology, and what type of role it will play in offering comprehensive alternatives to Juniper's Unified Access Control Suite or Cisco's NAC.