NAC THE EVOLUTION OF NAC AND THE AGE OF COMPLETE NAC Prepared by: Alan Shimel Chief Strategy Officer StillSecure® May 2007 Copyright © 2002-2007 StillSecure®. All rights reserved. White paper1 of 7 Table of Contents Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 The Appeal of NAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 A Brief History of NAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 The Age of Complete NAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Pre-Connect NAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Rich and deep testing ability . . . . . . . . . . . . . . . . . . . . . . . . .3 Agents, clients, and agentless-clientless testing . . . . . . . . . . .3 Enforcing Pre-Connect NAC . . . . . . . . . . . . . . . . . . . . . . . . . .4 Post-Connect NAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Post-Connect Technologies . . . . . . . . . . . . . . . . . . . . . . . . . .4 Post-Connect Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 ID-Based NAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 ID-based policy control . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 ID-based access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Non-Windows OS Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Traditional Computing Devices . . . . . . . . . . . . . . . . . . . . . . . .5 Non-traditional device coverage . . . . . . . . . . . . . . . . . . . . . . .6 Remediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 Enforcement Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 Inline enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 802.1x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Cisco NAC and TCG/TNC . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 About the author As Chief Strategy Officer, Alan Shimel is responsible for guiding StillSecure® on its mission to bring innovative and effective networking and security solutions to the marketplace. Mr. Shimel has become an often-cited personality in the security community. Through his blog www.ashimmy.typepad.com and weekly podcast www.clickcaster.com/ss , his commentary on the state of security and the marketplace is closely followed within the industry. Additionally, Mr. Shimel is active in the open source community, serving as a director of the Open Source Snort Rules Consortium (OSSRC) and founding the OS2A. He is a soughtaffte speaker at industry conferences and events. Mr. Shimel was most recently SVP of Sales and Business Development of Cachier®, a manufacturer of network acceleration appliances. Prior to that, Mr. Shimel was VP of Business Copyright © 2002-2007 StillSecure®. All rights reserved. Development of Interliant® and, in a little more than 3 years, was instrumental in forging relationships and strategic partnerships with such industry players as Dell® Computer, Verisign®, Microsoft®, IBM®, Cisco® and EMC®. He was also a key team member as Interliant acquired 27 companies and completed a successful IPO. A pioneer in the Internet industry, Mr. Shimel was one of the founders of Tri Star Web®, a NYC-based, early participant in Web hosting. After building Tri Star Web to a multi-million dollar revenue run rate, he sold it to Sage Networks®, which later became Interliant. Mr. Shimel is a graduate of St. Johns University with a Bachelor of Arts in Government and Politics, and holds a JD degree from NY Law School. INTRODUCTION THE APPEAL OF NAC No other technology in information security has generated as much interest, discussion, or requests during the past two years as network access control (or NAC). There are multiple reasons why NAC has become the latest solution in keeping our enterprises secure. The first is that the concept behind NAC is simple to grasp. If a device does not meet the appropriate access policy, it should not be allowed access, or only have access to a limited portion of the netwoork Another reason for the appeal of NAC is the realization that after years of hardening the perimeter, a greater risk to our security comes from the insider threat. This insider threat can be from users of company owned devices, or from guests using non-company owned endpoints. The third appeal of NAC is the ability to use the network to intelligently protect itself from harm. Of course, a netwoor that protects itself often requires significant upgrades or modificattions which in some cases may outweigh the benefits of deployiin NAC. A BRIEF HISTORY OF NAC NAC first appeared on the market over three years ago with early entrants such as StillSecure’s Safe Access. The market, and even the name NAC, began to gather significant momentum during this time, along with Cisco’s announcement of network admission control and the self-defending network initiative. Shortly after, Microsoft announced their own initiative and framework called network access protection, or NAP. The Trusted Computing Group also revealed their Trusted Network Connect open standard for NAC functionality. Gartner was one of the first entities to use the term NAC to mean network access control, which has since caught on and refers today to a wide range of access control technologies. (For an in-depth review of the three NAC frameworks, please see our whitepaper on NAC standards.) The timing of this coincided with, and capitalized on, the realizations driving the appeal of NAC, creating a rush of solutions to solve these network access issues. These different aspects of NAC all coming to market has served to create a somewhat muddled picture of what NAC does and how it works. Combined with other options around NAC, (automated remediation versus self-remediation, inline NAC versus out-of-band NAC, and appliance versus network based) has caused confusion and made it difficult for customers to clearly choose the solution that will best solve their problems. THE AGE OF COMPLETE NAC These disparate approaches to NAC have competed in the marketpllac for dominance. Even though pre-connect NAC solutions like Safe Access have consistently been shown as a first priority for a NAC solution by customers, other types of NAC are also desirable if possible. As a result, many providers of post-connect or identitybaase NAC have added some capabilities to perform at least cursorr pre-connect NAC checks (which include checks for the presence of anti-virus and the latest windows hotfixes). However, no single NAC vendor has been able to bring a best-of-breed product that encompasses the entire spectrum of NAC functionality into one solution. As the NAC market has matured, it is clear that the markke and customers are demanding this “Complete NAC”. They are not willing to be mollified by cobbling together two or three differeen solutions, or willing to accept less than adequate functionality across the board. 2 of 7 Copyright © 2002-2007 StillSecure®. All rights reserved. Device posture Behavior Complete NACWho you are What does that mean Type of device Policy Anomaly-based Signature/behavior-based Who you are Pre-connect NAC Post-connect NAC Identity-based NACStillSecure finds itself uniquely qualified to fulfill this market request. Unlike other NAC vendors whose expertise was in one focus area of the technology or another, StillSecure has had products and significant R&D activity in all of these areas for some time. The StillSecure suite of solutions, which covers a wide range of security and network expertise, and products, provides everything needed to deliver Complete NAC to customers. A broad, deep, and flexible pre-connect testing and enforcement capability, such as that provided by Safe Access, is the rock upon which Complete NAC is based. Built upon this are vital features such as: • Reliable and effective post-connect monitoring and inspection of traffic that will detect potential policy violations and offer a range of responses • Assignment to access policies and specific health checks based upon on user and device • Limiting network access based upon identity and device. • Support for the major NAC frameworks and standards to leverage investment in existing and future infrastructure • Identification of and the ability to test and enforce non-Windows OS devices • Flexibility in enforcement options, both inline and out-ofbaan deployment alternatives, automated and selfremeddiatio capability and scalable, redundant design The remainder of the paper will look at each of these elements of Complete NAC in greater detail. PRE-CONNECT NAC RICH AND DEEP TESTING ABILITY Pre-connect tests can include the presence and configuration of personal firewalls and anti-spyware including: when a sweep was last run, the presence or absence of user configurable applications and services, P2P applications, potentially dangerous communication programs, worms, trojans, viruses, macro settings, browser and security settings, etc. There is no reason, with the capability of today’s NAC solutions that any administrator should have to settle for just anti-virus and hotfix testing anymore. In order to facilitate a rich pre-connect test policy, it is imperative that these tests be performed quickly, especially at peak load times. This is exactly why repurposed technologies do not afford deep pre-connect tests. Safe Access’s purpose built NAC test engine was designed to complete hundreds of tests on a given device in under 12 seconds, and test thousands of devices simultaneously. Be wary of NAC solutions that perform cursory tests during the pre-connect phase and then perform more extensive scanning after a device is on the network. Once a device has been granted access it is often too late to stop any damage that may occur. AGENTS, CLIENTS, AND AGENTLESS-CLIENTLESS TESTING One factor with pre-connect NAC is how the tests are performed. There is the matter of whether a permanent agent is required for testing. Also to consider is if a dynamically delivered, perishable client can be sent to perform testing and not remain on the device when it leaves the network. Another possibility is to perform testiin without the presence of any client or agent. Before looking at each of these alternatives, real world experience shows that all three of these options are required at some time for the majority of NAC deployments. There is no single right or wrong testing method. Agent-based testing offers the ability to rapidly test a wide range of settings and policies. With the agent already installed there are no issues with credentials. The concern with agents is they generalll need to be present before the device logs on. Therefore, they are best suited for managed devices where you can install the softwaare 3 of 7 Copyright © 2002-2007 StillSecure®. All rights reserved.Dynamically delivered agents or clients come in two flavors. One is the dynamic, persistent agent which is a regular agent delivered via a web download. The other, more prevalent dynamically delivered agent, is the non-persistent or disposable agent. These disposable agents are used once, and usually downloaded via ActiveX (Windows only) or Java. In order to install some credentials, admin type rights may be required. Another factor to consider here is the footprint. How long will it take to download and install? How often is the device going to log on to this network? Do you need to set up a user account to accept and install the agent? These are all questions that need to be asked to help determine if the dynamiic non-persistent agent is right for a given situation. True agentless-clientless testing can only be accomplished in a few ways. The easiest, but unfortunately, the least desirable NAC perfoorm a typical vulnerability scan a la Nessus or some other vulnerabiilit scanner. The concerns here are the time it takes to scan, and what you are scanning for. Usually network access control policies go beyond just looking for a specific vulnerability. A “local” check requiring credentials is required. Again scanning speed and time can be a factor. Another approach that works with certain operating systems is using Windows’ own protocols to log on to the device (credentials are still needed). This can be a much quicker process using a purpose built NAC testing engine such as Safe Access. The bottom line is even though agentless-clientless testing is alluring; it is often not the right method for some situatioons A combination of all three testing methods is optimal. Instead of choosing one or another, a prioritization of a first choice, and if that doesn’t work, second choice, etc., offers the most flexibility. This is exactly the option Safe Access affords. ENFORCING PRE-CONNECT NAC Perhaps more so than at other stages of NAC, the pre-connect enforcement decision can be the most complex. The question is how much do you want to change your existing environment? And, is there a trade off by choosing an option that involved less change? Later on in this paper we will more fully discuss NAC enforcement technologies. Pre-connect specific challenges revolve around the device not already being on the network. Some of the technologies for pre-connect enforcement are inline, 802.1x, DHCP, or any of the three frameworks. POST-CONNECT NAC POST-CONNECT TECHNOLOGIES There are several technologies that are currently being deployed as part of post-connect NAC. Usually, a NAC vendor’s previous experieenc is utilized to provide this functionality. Some of the technoloogie deployed are: Signature-based intrusion detection/prevention – Utilizing traditionaa IDS/IPS technology, alerts, and quarantine instructions that can be sent from an IDS/IPS sensor to the NAC enforcement server. If used, inline traditional IPS blocking techniques can also be utilized in conjunction with quarantine. IDS detection and alerts to 4 of 7 enforcement usually allow for an out-of-band deployment. Network Anomaly and Behavior Detectors NABD – Much like IDS, except relying on anomaly and behavior detection rather than signatuures When malicious traffic is detected, alerts can be sent to the NAC enforcement to quarantine offending devices. Vulnerability Scanners – Using Nessus or other vulnerability scanniin and sometimes a GAME API, traditional vulnerability scans and policies can be executed against devices on the network. Devices that return vulnerabilities or policy failures can then be quarantined. Because devices are already on the network, speed of testing is not as critical. Sometime it is used when other NAC testiin is not successful for unsupported OS and devices. Periodic Pre-Connect Re-testing – A minimal post-connect strategy employs the pre-connect testing to periodically retest devices and ensure they are still compliant with policy. This will not monitor activity, but does provide some post-connect protection. These technologies are not mutually exclusive. Regardless of which one you choose, the idea is that after a device is allowed on the network, it can still be tested, required to maintain compliance with access policies, or quarantined and/or removed from the netwoork Post-connect functionality is usually a secondary priority after pre-connect testing; however it is an important part of the Complete NAC equation. An important Complete NAC concern is using a second vendor’s solution in order to provide both pre and post connect functionalitty Many Pre-Connect NAC solution providers and Post-Connect Vulnerability Scanner NAC solutions are partnering with IDS/IPS and NABD vendors to accept alerts from these packet inspection technologies. Depending on the way the two vendors interact can have drastic effects on future functionality of this two vendor systeem Having one vendor who can supply the complete NAC equatiio is far less risky. Just because the post-connect functionality is now part of NAC does not mean that the difficulties inherent in the technology prior to it being part of NAC (false positives for instance in NABD and IDS) have been eliminated. You should look for a post-connect solution that is optimized against this, so that devices are not quaranttine needlessly. POST-CONNECT ENFORCEMENT Post-connect enforcement offers several options. One is to use the inherent NAC enforcement methods (inline layer 2, 802.1x, DHCP, 802.1Q trunking, etc.). Another method that is used by several vendors, but is frowned upon by the security industry, is ARP poisoning or twiddling. This method lends itself to easy evasiion DHCP can also be evaded, but with new capabilities built into some Ethernet switches, it is not as easy. If your post-connect NAC uses IPS technology you can also use traditional IPS blocking as a means of enforcement. Giving the administrators the ability to both block malicious traffic and quarantine the device where the traffic originated from is an optimal solution. Copyright © 2002-2007 StillSecure®. All rights reserved.Again, your enforcement options will depend on the post-connect technology deployed. ID-BASED NAC A third key element of a complete NAC solution is identity-based NAC. ID-based NAC has two elements. ID-BASED POLICY CONTROL In this element, what policy the device is checked against is determiine by the identity of the user. Typically upon logging into the network, the users’ credentials are matched to the AD/LDAP group structure. Then pre-defined policies for different groups and identities would be applied to the device. This assumes that some sort of directory technology is in place. Other issues arise around sign in. How is the NAC solution able to see the group the user is assigned to? Some NAC solutions will take a user’s identity and bind that to a MAC address from a machine. If the user changes machines, this could be a problem. Polling the AD/LDAP on signoo for group assignment and then assigning test policy based upon this, seems to be preferred way of accomplishing ID-based policy control ID-BASED ACCESS CONTROL ID-based access control has two aspects. One is that based on who you are, your device has to comply with a specific access policc and configuration test. The second and more powerful ID-based access control will limit what resources you can access on the netwoork With ID-based access control, users are assigned access to only the resources they are given permission to use on the netwoork In this way, a sales person can access a CRM application, but perhaps not the financial servers. This access based identity control is also accomplished by taking the person’s group identity out of AD or LDAP. They can then be assigned to a pre-configurre VLAN. These VLANs could be configured on the fly, which allow for easier changes of access levels. A limiting factor is how you accomplish this on a network that is not VLAN or 802.1x capable. You could use SNMP, but you run into SNMP security issues. SNMP also requires custom scripting for each switch on the network. You could also pre-configure ACLs. However, this is also a labor intensiiv method. Another way that this is accomplished is by sending everything through a proxy server that enforces ID access. This can work, but scalability can become an issue. Many of the bump in the wire or inline NAC solutions accomplish this by using an inline firewall built into their device. Again, building firewall rules for every device accessing the network can become a resource issue at the box. Hence, any individual box can only handle a relativvel small amount (1000 to 2000) of users. Many ID-based access control solutions have their roots in the SSL VPN space and in the identity management space. They have become an important piece of the NAC story. NON-WINDOWS OS SUPPORT The first generation NAC solutions were geared toward Windows devices. This is not surprising since they make up the overwhelmiin majority of computing devices accessing the network today. As the expectations of the NAC customer grows, and the market matures, we are seeing the need for NAC support beyond Windows devices. NAC solutions that utilize Nessus and classic vulnerability scanning generally have the ability to test, at least at some level, non-Windows OS. They may not be able to perform the local checks that could be necessary for a complete and comprehensive NAC type check in a reasonable time. Also, post-connect NAC does not need to test a particular device, as it is looking for malicious traffic and will quarantine based upon that regardless of type of device. This is not truly testing non-Windows devices either. Non-Windows devices can be grouped into traditional computing devices and next generation computing devices. Each group presennt its own challenges. TRADITIONAL COMPUTING DEVICES After Windows OS devices the next logical group of devices for NAC to test and regulate are non-Windows OS computers. This usually means Apple Macintosh and then Linux computers, folloowe by Unix devices. Macs present some unique challenges. What do you test for on a Mac? Many Mac users do not run any anti-virus, and patches are relatively rare. You could check for the presence or absence of applications and/or services. The next challenge with Mac is, what can you do with an agent versus what can you do without an agent? Can you have dynamically delivered agents on a Mac? Optimally, one would want the same choice and flexibility in testiin methods with a Mac that you have with Windows devices. To test agentlessly you can use Nessus type vulnerability checks or you can log onto the Mac, assuming that SSH or some similar type of protocol was available. Without SSH type functionality can you do local checks without an agent. For Mac, an agent would be the primary method of testing. Another item to think about Mac NAC is 802.1x mode. What supplicant comes with the Mac? Is it adequate? Equally troublesoom is a dynamically delivered agent. Obviously an ActiveX download won’t work on a Mac. Even a Java download may not be easy to accomplish depending on the settings on the device. Linux and Unix devices present many of the same challenges that the Mac does. The added complexity involves all of the different flavors of Linux and Unix and the individual differences between them. An agent for Red Hat may not work on Suse Linux, and a Solaris agent may not work on AIX. Of course all of this may not be important to a NAC customer if they are not interested in testing devices with these disparate operating systems. It is prudent to understand the make-up of devices accessing your network now, and what you expect in the future NON-TRADITIONAL DEVICE COVERAGE One of the biggest changes happening to the networks of today is 5 of7 Copyright © 2002-2007 StillSecure®. All rights reserved.the wide variety of devices that are accessing them. No longer is everything on the network a laptop or desktop. Networked devices go beyond printers and fax machines to include VoIP equipment, PDAs, Blackberries, smart phones, game consoles, etc. Though not as acute right now, each of these devices can present unique security challenges from the point of view of introducing malicious traffic into the network or themselves being targets of attack. These non-traditional devices do not represent a major threat to the network currently. However, any NAC customer should make sure their NAC vendor has protection for these types of devices on the roadmap. 2008 will probably see more coverage in pre-conneec NAC for these types of devices. For the present, post-conneec NAC coverage for non-traditional devices offer some level of protection from them. REMEDIATION Remediation is another important aspect of NAC. Originally an afterthought at best, remediation is in many cases the finishing touch on NAC. Early NAC products and many NAC solutions only offer so called self-remediation. Better NAC solutions offer integratiio with existing patch management solutions and some NAC solutions can push and apply a patch themselves. Many organizatiion have already made an investment in patch management prior to deploying NAC. Experience has shown that self-remediation can be a major source of help desk calls. Many network users are not IT savvy enough to apply updates and patches themselves. Even when pointed to the correct download location, downloading and applying a patch is beyond their comfort level. So, what is best for remediation in NAC deployments? A tight integration with an existing patch solution is probably the best way to implement remediation in a NAC environment. A NAC solution having its own patch ability would most likely be duplicative of existing patch systems and may give rise to conflicts. It is importaan that remediation policies and process be well thought out and implanted in any successful NAC solution. ENFORCEMENT OPTIONS When discussing enforcement options for NAC, flexibility is key. With the wide disparity in network topography and different options in enforcing access control policies, no one solution for enforcement will be right for everyone. A complete NAC solution should offer a wide enough range of enforcement options to allow you to choose which is best for your situation. The most advanced NAC solutions will allow you to mix and match different enforcemeen options in the same NAC installation. Some of the different NAC solutions are: INLINE ENFORCEMENT Generally a layer 2 solution, inline enforcement acts as a layer 2 bridge through which all traffic passes. It is used by the bump in the wire solutions, as well as in some remote access scenarios. DHCP In this oft maligned method of enforcement, the NAC solution inserts itself during the assigning of a DHCP-based IP address to the endpoint. The knock against this NAC is that static IPs or spoofed IP addresses can avoid enforcement. Some DHCP servers have defenses against this type of avoidance. The problem is fundamenntall an issue with DHCP, not necessarily NAC itself. Also, several switch vendors have capabilities to thwart spoofed or static IP attempts to avoid this type of NAC. Though not a perfect way of performing network access control, DHCP-based enforcement often presents an acceptable compromiis between network upgrades needed for other type of NAC enforcement and providing another layer of protection in the securing the network. 6 of 7 Copyright © 2002-2007 StillSecure®. All rights reserved.802.1X Perhaps the most secure and scalable method of NAC enforcement, 802.1x also requires compliant hardware and infrastructure. Most often using Radius servers, 802.1x capable switches and a NAC produuc that inserts itself into the authentication and VLAN assignment process, if done under best practices, 802.1x is very difficult to thwart. Because it does not have to be inline, it is also very scalable. The biggest drawback to more widespread use of 802.1x as an enforcement method is that most networks do not have all of the necessary compliant systems in place. SNMP SNMP can be a “poor mans” 802.1x method of enforcement. It gives you the port level access control, but has significant drawbacks. Most often SNMP commands are sent in the clear and can be sniffed and intercepted. Even with some of the new more secure and propriettar SNMP versions, info and/or passwords are still sent in the clear. Another issue with SNMP is that each switch in the network has to be individually scripted. In large enterprise deployments this makes for an expensive and lengthy implementation process with updates needee every time a switch is added or changed. So while SNMP does offer port access control, as with other NAC enforcement options, there are trade-offs to be made. CISCO NAC AND TCG/TNC Both Cisco NAC and the Trusted Computing Group’s TNC offer NAC enforcement. TNC is at its heart of 802.1x methodology. Cisco NAC is also a proprietary version of 802.1x. Both offer outoofband methods of enforcement. Recently there have been flaws demonstrated in the Cisco NAC method. In addition with both CNAC and TNC you need compliant equipment throughout the network. Microsoft NAP actually relies on many of the enforcement options mentioned above. Additionally NAP can use IPSec for enforcemeent CONCLUSION In a relatively short period of time NAC has come a long way. Today’s more advanced NAC systems offer pre admission health checks, post admission monitoring, and identity-based access contrrol Many NAC solutions continue to mature and evolve, so road map discussions with any potential vendors should be an importaan part of an NAC buying decision. There are many options in the market that cloud the decision making process for customers. Another point of contention in NAC is the endpoint versus networrke based decision. Customers would be wise to carefully research all of the different phases of NAC and determine what the problem they are trying to solve is, and what NAC solutions work best for them. 7 of 7 Copyright © 2002-2007 StillSecure®. All rights reserved.