"The online business magazine at the heart of international business management news..."
New Account

The Magazine

Issue 10

E-magazine
  • Previous Issues

Blog

Spencer Green
Chairman, GDS International

Sales and the 'Talent Magnet'

A lot is written about being a ‘Talent Magnet’, either as a company, or as President. It’s all good practice – listen, mentor, reward, provide clear goals and career maps. Good practice for the employer, but what about the employee?
24 May 2011

Is NAC a Feature or a Solution?(And if a Solution, to what Problem?)

Nevis Networks | www.IWantTheSolution.com

No Comments

NAC has been widely hailed as critical security technology to authorize access to internal networks and ensure endpoint compliance. A recent IDC forecast indicated that the market for NAC products would grow to $3.2 billion by 2010, up from $526 million in 2005. Forrester Research indicates that nearly half of all organizations have plans to deploy NAC or NAC-related projects, while firms stated the need for enhanced access control across all mediums: wireless, wired, and remote access. The list of major players that are enthusiastically promoting NAC includes Cisco, Microsoft, Juniper, and Symantec, to name a few.
Along the way to fulfilling its promise, though, NAC has already encountered some bumps along the way. In truth, there are relatively few successful NAC deployments because products from major vendors are incomplete causing customers to wait, and there are competing standards again causing customers to wait for clear direction. Perhaps most telling, Forrester Research issued a report in March, 2007 that declared “NAC as we know it will fail”. Similarly, a recent Infonetics Research study stated that two-thirds of NAC budgets in 2006 were actually spent on 802.1X-enabled switches, an alternative approach to user and machine authentication and access control, rather than NAC-specific products.

As many technologies initially are, NAC was hyped as a solution to a poorly defined problem. As a result, early adopters had difficulty realizing tangible benefits in real-world environments. As the Infonetics report stated in June, 2007, “One of the major problems facing the NAC market right now is that there isn’t a consensus on what NAC really is.” As a result, virtually any network security infrastructure vendor moved into the market and touted a new approach to NAC. This is despite the fact that there are at least two main vendor groups, led by Cisco and the combined Microsoft/TNC alliance, that are trying to create a common definition of NAC technology along with product interoperability standards.

Demonstrating the lack of consensus of what NAC really is, there is not even universal agreement on what the acronym “NAC” really stands for. Originally coined by Cisco as “Network Admission Control”, it has generally evolved to include more services than just network admission, and has been recast as “Network Access Control”, although both are still used by various vendors and industry analysts alike. What makes a product an access control solution and not an admission control solution is subject to debate.

NAC, whatever it is or becomes, will only achieve wide market acceptance when it solves real-world customer problems with tangible return on investment. If customers can’t apply NAC to their own identified problems, they simply won’t adopt it. Rather than offering up another definition of NAC, or prognosis for what it needs to succeed, it’s important to step back and provide a little deeper analysis of what problems customers are facing, before building a set of solution requirements to address a commonly identified problem.

Every customer environment is unique, but in general, according to IDC, “the enterprise network is changing, and IT executives and staff are being worn down by the security demands incurred by the influx of unmanaged endpoint devices bombarding their corporate networks.” Forrester Research generalizes the problem a bit further by saying that organizations need to better manage the newly emerging risks of endpoints attaching to the network.

Networks were initially designed around a trust model (assumptions that security staff make about systems and users in order to build appropriate solutions) that assumed internal users and systems were “trusted”, and internal networks could be designed for performance with little or no inherent security in the network. Any security that existed was typically placed on endpoints themselves, or by segmenting the LAN using coarse policies to implement who could access what resources.

Today, networks have to be designed for a different trust model. Corporate LANs have to accommodate guests, contractors, external partners, employee-owned systems, as well as mobile and remote users. Dealing with untrusted users and unmanaged endpoints connecting to the internal LAN is causing a new wave of headaches that didn’t exist before. In response, NAC arrived to ensure that only compliant endpoints and authorized users connected to the network.

However, in retrospect, the problem is more complicated than initial network admission checks. Even “trusted” users can turn malicious. Even non-malicious users sometimes do stupid things. Even “compliant” systems can be subverted by stealthy malware that self-propagates after they have been admitted to the network. Enterprises are also interested in tracking users after they have been admitted to the network to demonstrate that their activity is compliant with intended security policies.

To summarize the challenge facing network security staff, managing the risk of untrusted users and unmanaged endpoints connecting to the internal network is really a problem of policy enforcement and risk management. How can the stated or intended security and access policies of the organization be enforced on systems the organization doesn’t own, and on users the organization doesn’t know, while allowing unfettered access appropriate for business processes and productivity?

Armed with a working problem definition, we need to give it a name for further reference and clarity. In this context it’s appropriate to call it the “dissolving perimeter problem”. “Endpoint risk management problem” would work as well. It’s also beneficial to list out some fundamental requirements that an appropriate solution would necessarily entail. After that we’ll compare our requirements list to NAC functionality to see exactly how it stacks up. First, the requirements:

  • Pre- and post-connect monitoring and control – As we have described, to completely mitigate the risks of a dissolving perimeter, more checks and controls are required than just a single check at network logon time. Persistent endpoint posture checking is required post-login, as well as a range of other access constraints, while the user is connected to the network. The industry distinguishes this functionality as “post-connect” monitoring and control, in comparison to the pre-admission checks initially contemplated by NAC.
  • Identity-based policy enforcement – If the dissolving perimeter problem is fundamentally a policy enforcement issue, it follows that the ideal solution should be able to reflect and enforce policies as they are designed and developed by the organization. Such policies should be based on the user’s identity as well as role and group affiliations. Security policies that arise from risk management and compliance initiatives, almost universally describe access privileges to applications and data in terms of roles. Human Resources can access personnel data. Engineers can access the design system. Networking infrastructure has historically had no notion of user identity and it has been impossible to map identity-based policies into switching and routing decisions.
  • An clientless design, with policies enforced in the network – It is a requirement that a solution enforce policies on unmanaged endpoints, meaning that you can not expect the system to be running any particular software or client in order to be scanned, monitored and controlled. The guests coming into your conference room will not be obligated to have something pre-installed. When connecting to the network, the guest may have a dissolvable agent briefly appear while connected, but nothing prior to the admission check. Similarly, the point of enforcement needs to be in the network, not on the endpoint. The endpoint is, after all, untrusted at this point, and can’t be relied upon to enforce its own access policies.
  • In-line architecture – If the policy is to be enforced in the network, it must be done so in real-time, and hence, it is a requirement that the solution reside in-line with the live network traffic. The solution must be able to drop packets when it detects an unauthorized access attempt or rapidly spreading malware. By issuing an alert or relying on another network security device to effect the remediation, it would be impossible to thwart the attack until long after it had passed. Examples of in-line devices include network switches, network appliances, and even firewalls and intrusion prevention systems which sit in the flow of packets.
  • High-performance – If operating on the live flow of network traffic, it quickly follows that performance is a critical factor of our policy enforcement system, ensuring that policy decisions are analyzed and made without slowing down mission critical data or providing a bottleneck to network throughput. In general, the solution must operate at LAN speeds, 10 Gbps, or the solution is not viable.

We have just described a first-level set of requirements for a solution to address the dissolving perimeter problem. In order to assess the suitability of NAC products, we will compare commonly accepted NAC functionality with our list of requirements.

  • Pre- and post-connect monitoring and controls - Initially, NAC was designed as a pre-connect only technology, to address only the decision of whether the user and system should be allowed onto the network. Many of the leading NAC vendors, and certainly the NAC standards initiatives still focus primarily or exclusively on this aspect of the problem. Many NAC vendors have responded by incorporating post-connect access control features into their products, and while this has generally improved the situation, the diversity of post-connect features and differing views on this issue has confused customers more. A common criticism of NAC is that it provides “all or nothing” access, meaning that once you get admitted onto the network, you can access everything thereafter, whereas security policies require explicit access of individuals or groups to specific servers and applications.
  • Identity-based policy enforcement – Probably the most exciting aspect of NAC was its ability to capture user identity as they logged onto the network and to associate them with an endpoint. While the network traditionally had little notion of user identity, user visibility became possible for the first time. Unfortunately, NAC’s primary focus on pre-connect controls leaves many products with the inability to leverage that user identity to make dynamic post-connect policy decisions. Since these post-connect policies are generally the longest lived and susceptible to change, pure NAC alone can’t be considered a full-featured policy enforcement system.
  • An agentless design, with policies enforced in the network – This is another area of great differentiation between NAC products. Some are agentless and others have a choice of persistent or agentless designs. Many, however, are focused on the desktop and expect the endpoint to have a whole suite of security services including host-based IDS, a NAC client, in addition to personal firewalls, anti-virus and anti-spam software. The expectation from many leading security analysts is that many of these services have to migrate off the endpoint and into the network for the reasons we discussed above.
  • In-line architecture – While a few NAC products sit in-line, of the ones that claim to offer some post-connect features, the vast majority of the products are out-of-band, limiting the role they can play in real-time visibility, control and remediation.
  • High-performance – Performance for even the in-line appliances can vary widely under various conditions and is often dependent on which security services are enabled. For this reason, enterprises should carry out their own analysis to see if a proposed solution will meet their needs.

Conclusion
The discrepancy between the solution requirements for the dissolving perimeter problem and common NAC functionality explains the disappointing results of early NAC deployments to date. NAC is clearly a necessary but insufficient feature in today’s network security designs, and can be described as a component of a more complete LAN security solution that meets the complete set of requirements outlined above.
In addressing the dissolving perimeter problem, we have described a fundamentally new approach to network security design. Fundamental security services will migrate into the network. The network fabric will be secure from all endpoints, with less emphasis on a secure network perimeter. The network will become “identity-aware” with a new generation of “secure switch” being the enforcement point for security access policies throughout the organization, greatly simplifying administration and management of the network.


More like this...

Disclaimer: All comments posted in a personal capacity
POST A COMMENT
In order to post a comment you need to be regsitered and signed in.
Register | Sign in
No Comments Have Been Submitted
Disclaimer: All comments posted in a personal capacity