internet2-salsa-netauth-policy-enforcement-200504.html
Phil Rodrigues, Editor
New York University
Eric Gauthier, Editor
Boston University
Copyright © 2005 by Internet2 and/or the respective authors
April 2005
Comments to: salsa-netauth AT internet2 DOT edu
Table of Contents
1.
Summary
2. Challenge
3. Impact
4. Value
5. The Common Process
6. Open-Source Solutions
7. Commercial Solutions
8. Legal and Policy Implications
9. Synergies and Partnerships
10. How Can I Help?
11. Acknowledgements
A. Appendix A - References
and Documents of Interest
B. Appendix B - Change Log
This document provides a summary of some approaches for automating technical policy enforcement as a condition for network access in colleges and universities. These approaches allow for host isolation into specialized networks, captive-portal-like remediation systems, and other forms of conditional network access. This document attempts to highlight the importance of these methods and to distill the myriad of current approaches into a single common framework. This, the first document of the SALSA-Netauth working group is meant to be an overview of various techniques for network authorization and policy enforcement.
The NetAuth working group was created in May 2004 by SALSA, which is affiliated with the EDUCAUSE / Internet2 Computer and Network Security Task Force. The NetAuth working group also works closely with the ResNet (Residential Networking) Symposium. Part of the NetAuth charter is to investigate requirements and implementations of network database and registration services in support of network security management as well as extensions to these services including proactive detection of unauthorized or malicious network activity, containment and prevention of such activity, and identification and remediation of the sources of such activity. Additionally, NetAuth has spawned a sub-group to investigate technologies which support network access to visting scholars among federated institutions (SALSA-Netauth FWNA).
The NetAuth working group plans to issue at least two follow-up documents to this summary. The first document will outline the complementary and often pre-requisite systems that institutions need to put in place if they wish to implement a NetAuth process in their environment. The second document will outline future requirements of an ideal system designed to embody all aspects of this process. Individual host registration implementations as well as the mechanisms and protocols used for authenticating users, though significant parts of any overall authentication and policy enforcement infrastructure, will be covered in one of these related documents. Additionally, the working group anticipates working with the Security Task Force's Effective Practices working group to gather detailed technical summaries of different institutions' current approaches to this process.
The major security challenge facing university residential networks and other large-scale end-user networks is the thousands of privately owned and unmanaged computers directly connected to an institution's relatively open, high-speed Internet connections. Security policy enforcement is often lax due to a lack of central control over end-user computers and an inability to tie the actions of these computers to particular individuals. A few times a year there are surge events, including the predictable start of each semester and the unpredictable and increasingly frequent reactions to large-scale security incidents, that require massive support intervention.
If these challenges are allowed to evolve unchecked, the result is the presence of thousands of unsecured computers that are prone to mass infection by malware or wide-scale compromise by increasingly unsophisticated attackers. Malware and attackers often specifically seek to harness large numbers of unsecured hosts for use in distributed file sharing, spam, and/or attack networks. The presence of these malicious overlay networks has been known for some time, but the full realization of fast, always-on Internet access has increased their size and potential for harm.
When infection or compromise is detected or external complaints are received, remediation of these incidents often requires manual investigation to determine who is responsible for a particular computer. After the responsible party is identified and notified, time-intensive support intervention is required to fix the problem. This is a drain on already scarce support resources and can negatively impact the productivity of an institution's entire computing staff.
Host authentication systems, while fairly common today, were considered a novelty by some when introduced in the recent past. They have since become standard practice in many institutions and are a recommended effective practice by the Security Task Force. We expect automatic network policy enforcement, isolation networks, remediation systems, and overall conditional access to become standard practice in educational networks in the near future.
Host authentication allows for fast, direct communication with whoever is responsible for a particular system, as well as placing the users system intoa role with network access appropriate to its owners standing within the community (e.g. administrator, guest, student). Preventative policy enforcement reduces the total number of technical security vulnerabilities as well as the successfulness of an attack technique or any particular piece of malware. Isolation networks separate compromised and infected hosts from the main network to both minimize the spread of infection and to block external access from attackers. Automated remediation systems have a positive impact on a large number of hosts with a relatively small time investment from computing staff.
The process common to all implementations involves five distinct steps: registration, detection, isolation, notification and remediation. The order of these steps varies, as does the exact terminology.
I. Registration
Although network registration is outside the scope of this document, it is an integral part of the process. An institution's specific method of network registration will heavily impact which methods for detection, isolation, and remediation it will be able to use. Some institutions will enforce strong authentication of user credentials before granting network access, while others will permit access without any authentication. The capabilities described in this document will apply most directly to the former.
Generally, registration systems intercept communications at either the physical layer (port-based solutions such as 802.1X), the data-link layer (MAC address solutions such as NetReg), or the network layer (IP solutions such as ARP manipulation, SSSL-based VPNs, tunneling equipment, inline gateways). In addition to the ISO layer at which they operate, registration systems typicall fall into one of three "duratioin" categories, which indicate how often a registration is rewnewed. Systems typically are "premenant" or one-time registrations, periodic (e.g. once-a-week), or event-driven (e.g. whenever a port state changes).
The introduction of NAT devices into campus networks by end-users poses security challenges for network operators and introduces potential liability concerns for the end-user. Network policy enforcement solutions relying on the media access control (MAC) address as a unique host identifier, and user authentication as a means of implying ownership and responsibility for a given host can no longer make such a definitive association when a device performing network address translation provides the direct interface to the campus network. During host registration, it is the NAT device, not the end-user’s host that is registered. Following the initial registration, additional hosts connecting behind the NAT device access the network unchallenged and with the same access rights as the original registrant. An important part of campus network security is bypassed, or at least reduced to the strength of the security measures employed on the NAT device. With wireless access points (WAPs) becoming the most prevalent end -user device performing NAT on campus networks, those in relatively close proximity have potential access. Any violations of local policy or law by others through the NAT device lead back to a likely unsuspecting end-user.
To enforce a ban on NAT devices, or ensure that they are operated in bridge mode, thus restoring end-to-end transparency, detection is necessary, whether active or passive. Active detection can be performed with real-time traffic analysis during the registration process, or through the use of network scanning software and associated plug-ins designed to identify some kinds of devices that typically use NAT. Passive detection is possible with some IDS systems. It should be noted that it is possible to avoid these detection methods through various techniques.
II. Detection
The detection phase attempts to determine the host's compliance with local network policy. Compliance can include the proper patch level, presence of up-to-date antivirus software, the presence of administrative passwords, or other administratively defined conditions. Detection can take place before or after registration, and often results in isolation if the host is not found to be in compliance. There are many cases where detection may not be possible, such as if a host is firewalled or a software agent does not install cleanly on a host. Some detection systems allow a host to gain network access if detection is not possible, while others suspend access until detection is successfully completed.
A. Active
An active scan attempts to determine policy compliance externally. It transmits a series of known triggers across the network and uses the responses to make inferences about the policy compliance of the host. TCP port scans followed by vulnerability tests on those ports is a common form of active detection. Nessus is an example of an open-source active detection tool.
Pros: Does not require installation of software on end-user hosts. May leverage existing vulnerability scanning systems. Active external scans are often operating system independent or can scan for vulnerabilities across multiple operating systems.
Cons: May be ineffective at determining policy compliance of hosts that are behind a firewall. Complex scans across many hosts can use a considerable amount of server resources. May trigger bugs or otherwise cause inadvertent denial-of-service to client machines.
B. Passive
Passive monitoring inspects network traffic emanating from the host to make inferences about its policy compliance. It matches the traffic to known signatures or known anomalous patterns and recommends action based on what alerts are triggered. For example, if a host is detected as scanning for suspicious ports on internal honeynets or darknets where no legitimate services are offered, then the host is presumed to be infected and is isolated. Snort is an example of an open-source, signature-based, passive detection tool. IPAudit and Argus are examples of open-source, pattern- or flow-based passive detection tools.
Pros: Most malware scans for new hosts to infect and these scans can be detected by examining outbound network traffic for known patterns or signatures. Existing intrusion detection systems may be leveraged. Can detect compromised systems, even if such systems operate a deny-all incoming firewall and is completely independent of the operating system of the transmitting host.
Cons: Can only detect systems that have already been compromised and cannot detect vulnerable systems. Pattern and signature based traffic analyses is still mostly unautomated and may require significant server resources to collect, analyze, aggregate, and report.
C. Agent
Installation of specialized client software, sometimes called an agent, on the local machine may be required to check the compliance of policies not visible from the network. The agent runs a series of checks from inside of the host and sends that information back to a central location.
Pros: Effectiveness is not hindered if the host is behind a firewall. Allows for very granular checks, including anti-virus definition dates and the presence of certain system settings, which external methods will not have access to.
Cons: Requires user cooperation - willingness both to install the agent (for example a temporary guest who might have a conflicting agent from his or her home institution) and allow it to run to completion. Deployment scalability issue - the agent must be installed on potentially thousands of end-user machines. Version control is often difficult, especially if this is an immature home-grown application. Licensing fees for tens of thousands of agents may become costly with a commercial product. Agents are usually written for one specific operating system.
1. Home-Grown
Agents that are written by college or university computing staff to check for compliance with local policy. These agents are specifically built for one institution and are not shared with others.
Pros: Full customizability with respect to the policies that are checked. Good chance at full compliance with local non-technical information policy related to privacy and data.
Cons: Requires dedication of staff resources for development and maintenance. Immature, not widely tested software may contain security holes.
2. Open Source and/or Public Domain
Open source and/or public domain generally describes software that does not require payment of licensing fees to use and for which the source code is widely available. Public domain agents are given away by their creator without the protection of an open-source or commercial license.
Pros: Low cost. May be in use at more than one institution and thus allow for cross-site agreements on what constitutes policy compliance. Ideally well tested by the community. Ability to see what the agent is capable of at a code level. Free support may be available from external sources.
Cons: Some open source solutions may be immature, or not widely tested.
3. Commercial
Commercial agents can be stand-alone policy enforcement agents or written as part of a larger detection system.
Pros: Ideally robust and well supported. May be in use at more than one institution and thus allow for cross-site agreements on what constitutes policy compliance.
Cons: Costly. Exact operation may not be fully transparent if the source code is closed.
D. Detection Interval
The frequency at which policy compliance is determine for a given host must be established.
1. Initial
Some detection systems check for policy compliance during a one-time or infrequent event. This event is often initial network registration or connection to a central system. If a deficiency is found, this event (e.g., registration, login, etc) is denied until the host has been remediated.
Pros: May be less complex due to event-driven triggers.
Cons: Unable to detect new vulnerabilities discovered after completion of the one-time process. Increases the time required for registration or login.
2. Ongoing
Some detection systems check for compliance at regular intervals, such as daily or hourly scans or every time a host connects. Passive systems may be constantly looking for a pattern of malicious behavior. If a deficiency is found the system may isolate the host immediately or it may wait a set interval.
Pros: Able to detect new vulnerabilities. Able to detect hosts vulnerable to newly-discovered issues. May be less complex due to registration integration requirements.
Cons: Constant scanning traffic on the network.
III. Isolation
Isolation often happens after a deficiency has been discovered in the detection phase. Isolation is enforced by changing network devices to limit the access of a non-compliant host. This protects the host from additional compromise, protects other hosts from it, and can be a conduit for informing the responsible individual of the hosts deficiency. There are a number of different ways of isolating a host. Some of the most popular methods in use include:
A. VLAN
VLANs provide true network isolation for different ports on the same switch. Systems will assign one VLAN to hosts that have not yet authenticated, another to hosts they know to be deficient, and another to hosts that are approved for access to the Internet.
Pros: Broadcast traffic is not shared between different VLANs on the same switch. Close to true physical separation between isolation and normal networks.
Cons: Edge hardware must support VLANs - hubs and unmanaged switches will not be capable of segmenting network ports. Automation often requires a single vintage and/or vendor of edge hardware. If an individual has a personal hub or switch, all machines connected to this device will also be segmented. May require significant re-configuration to enable multiple VLANs throughout the network.
B. IP
IP-based isolation occurs in much the same way as VLAN isolation, but it assigns hosts to different logical networks. The different networks are overlays onto the same physical network, so some broadcasts will be seen across all networks. DHCP servers are often used to assign hosts into the different pre-registration, remediation, or public networks.
Pros: Works across different vendors, vintages, and types of edge equipment. IP-based systems are in wide use and the process is fairly mature.
Cons: Different IP networks layered across the same device will still share the same broadcast-all traffic, which may allow for certain infections to spread. IP solutions usually rely on DHCP for address control and clients will take anywhere from 50% to 100% of the lease time before requesting and receiving their new address. This can slow reaction time to critical events. Statically configured machines or machines that do not re-DHCP immediately will bypass isolation efforts.
C. Gateway
A captive gateway has all traffic sent through it and makes decisions about where to send the client's traffic, thus determining to which internal or external networks the host can connect. It sits inline and assumes routing functions for or bridging between the networks that connect to it.
Pros: Complete control of the network path of a certain host since it acts as the router and very often controls to which VLAN the port is assigned. Single point of policy enforcement.
Cons: An inline system needs to be redundant - if it fails traffic will stop flowing entirely. May be difficult to scale.
D. VPN
Some systems require the establishment of a tunnel (VPN/IPSec, GRE, PPPoE, and so forth) before they will allow external access. This tunnel might be restricted in different ways, depending on the security posture of the host.
Pros: Allows for centrally managed systems that are not distributed throughout the network. Easily tie network access to an end-user through standard authentication mechanisms.
Cons: Typically requires end-user software. Does not scale well. Requires additional client and server capacity, impacting network performance.
E. ARP
ARP, as a lower-layer network protocol, provides a mechanism to isolate hosts independent of media type or network architecture. Systems that have not authenticated or are in breach of network policy will have their gateway ARP cache entry overwritten to point to a captive gateway (enforcement) device. There are negative connotations associated with ARP poisoning, although more products are depending on it for isolation functionality.
Pros: Vendor agnostic in that the ARP process is present on all ethernet-connected systems. Inter-subnet isolation requires only one ARP packet to overwrite the gateway's entry. ARP 'stuffing' can be done via a directed unicast packet to the affected systems.
Cons: Intra-subnet isolation requires overwriting ARP cache entries for all local hosts. Broadcast ARP requests overwrite poisoned entry and must be immediately followed by another poisoned entry. This introduces a slight race condition and may let some packets through. Hosts can add static ARP entries to bypass isolation efforts, although this can be detected with proper heuristics. Some operating systems and security appliances see this type of activity as a security violation and might block the secondary ARP message.
IV. Notification
Notification is the process by which the policy enforcement infrastructure will attempt to notify an appropriate person about the state of a system. Included in this notification is usually an explanation for the policy violation, if any, and detailed instructions for authenticating a host for network access or for resolving a policy violation. Notification can either be done in "inband", typically through pop-up messages or application hijacking (e.g. web browser redirection) or "out of band" via another mechanism such as email, telephone calls, or site visits. Additionally, a determination of the proper techincal contact for a system must be made. Appropriate contacts may be the system owner, a separate system administrator, a support group such as a helpdesk, or a third-party support team such as may occur in a federated authentication system.
V. Remediation
Remediation is where some type of corrective action is taken. Remediation may be self-service, which allows users to perform the necessary steps themselves and remove themselves from the isolated network, or remediation may require support staff intervention. It may even be possible for remediation to be automatic, usually in conjunction with a specialized software agent.
A. Local
Local remediation delivers files, such as patches or antivirus definitions, which have been re-hosted within the institution's network as permitted by law or under license agreement.
Pros: Files hosted locally may be transmitted much faster across the network. It may not require access to any external systems and thus function even if the entire institutional network is disconnected from the Internet.
Cons: Rehosting files locally may require legal agreements with the patch's vendor. There is always a delay after the vendor releases a new update.
1. Static
Static files are hosted on an internal file server with links to the appropriate patches. The links to these files may be generated dynamically based on the detection phase, but the files themselves are manually obtained and maintained on the local server.
Pros: Very simple to implement. Complete control over which files clients are able to download and install.
Cons: Time intensive to gather all necessary patches in one place, for all operating systems and languages, and keep them updated. Storage requirements may grow steep if a large number of updates are required.
2. Dynamic
Some operating systems allow creation of local mirrors of their dynamic support process. Dynamic local update systems update their content from the central, external servers automatically. Often times they look and feel like an exact copy of the remote update system, except that they reside within the institution's network boundary.
Pros: Once installed, the system updates itself with new files and offers synchronization with the vendor's complete list of updates. May also allow granular local control over what updates are available to your hosts.
Cons: More complex to set up. Storage requirements may grow large if a full mirror is made. Clients may need to be reconfigured to use the local dynamic update service. This reconfiguration may require clients to continue to look towards that institution's network for updates after they leave the institution.
B. External
External remediation systems deliver the necessary update files to the host via the vendor's preexisting support mechanism. If deficient hosts in an isolated network need to contact an external system to facilitate remediation, there needs to be some specialized network configuration to allow this to happen.
Pros: Does not require any local storage space.
Cons: Requires some way to get traffic from isolated hosts out to the update site. New external updates or local events (move-in) may cause a large spike in the volume of Internet traffic.
1. Proxy
Since external update processes are increasingly Web based, an http proxy is often used to bridge the gap between private isolation networks and the Internet. Application proxies may also be used to allow non-http update systems to connect to external networks.
Pros: Granular, site-based access control can be used for some types of update traffic.
Cons: Some SSL-based update mechanisms may break entirely if proxied. Web proxies do not allow for granular access control if the update process is encrypted with SSL. Requires ongoing administrator time to maintain proxy list as external sites change.
2. Translation
Some remediation systems translate private addresses into public addresses through NAT or PAT to allow clients to connect to external networks.
Pros: Operation is invisible to the end user.
Cons: Translation hardware, such as routers or firewalls, is expensive. Translation may require IP address-based access control to limit the ability of isolated hosts to connect to external resources. IP address-based access control is difficult to implement and maintain with modern, dynamically updating external content delivery networks.
3. Split DNS
Proxy and translation often require some sort of DNS name-based access control, since maintaining a list of allowed IP addresses is difficult when external systems use dynamic content delivery networks. Some remediation systems accomplish this with a multi-tiered name server that allows resolution of the resources required to contact the external support system, while blocking or redirecting all other queries.
Pros: Allows for per-domain control of translated traffic.
Cons: Some external update systems have multiple, changing domains. Maintenance is required for the correct list of domains.
Several open source solutions are available. No single package handles all aspects of this process (yet), but the pieces many people use to build their own solutions are listed below in alphabetical order.
CMU Epidemic (Remediation)
http://www.net.cmu.edu/epidemic/
The CMU Epidemic system is a flexible incident-tracking system. It is used to integrate network registration and accounting data from various sources (DHCP lease logs, RADIUS logs, VPN access logs), determine the party responsible for an IP address at a given time using this information, and take appropriate action in response to the incident. An incident can be created in response to either a relatively benign issue involving e-mail or an active network attack necessitating immediate filtering of the local source. The system has a SOAP-based interface to easily integrate network vulnerability scanners (Nessus), resource accounting systems (bandwidth accounting) or other such systems. The system consists of a Web interface (primarily administrative) and backend-processing daemon.
FreeRadius (Registration)
The FreeRADIUS Server Project is a high-performance and highly configurable GPL'd free RADIUS server. FreeRADIUS includes more than 40 vendor-specific dictionary files. It ships with support for LDAP, MySQL, PostgreSQL, and Oracle databases. It supports EAP, with EAP-MD5, EAP-TLS, EAP-TTLS, EAP-PEAP, and Cisco LEAP subtypes.
Nessus (Active Detection)
"The Nessus Project aims to provide to the Internet community a free, powerful, up-to-date and easy to use remote security scanner. A security scanner is software which will audit remotely a given network and determine whether someone (or something, such as a worm) may break into it, or misuse it in some way. Unlike many other security scanners, Nessus does not take anything for granted. That is, it will not consider that a given service is running on a fixed port - that is, if you run your Web server on port 1234, Nessus will detect it and test its security. Nessus is very fast, reliable and has a modular architecture that allows you to fit it to your needs. Nessus works on Unix-like systems (MacOS X, FreeBSD, Linux, Solaris and more) and a Windows version called NeWT is available."
CMU NetReg (and NetMon) (Registration)
The CMU NetReg system provides administrators with a central platform for administration of network information. NetReg keeps a database of subnet information, DNS zones, DHCP options, machine registrations, and more. It has a finely grained access control mechanism to provide administrators with maximum flexibility in delegating access. In the QuickReg mode, NetReg can be used to redirect unregistered machines into the system for purposes of registering their computer with minimal effort. After registering a machine, NetReg updates DNS zones, DHCP configuration, and other access controls as necessary. The system consists of a Web interface to a database, with backend processing daemons to update and maintain network systems.
NetMon, the "sister" of NetReg, collects and processes dynamic network data. It captures CAM table and ARP table information from network devices, as well as store DHCP lease information (updated in near real time by the DHCP servers). The goal of NetMon is to provide a real time, historical view of the network. NetMon is able to detect misregistered and unregistered machines.
Southwestern NetReg (Registration)
"NetReg is an automated system that requires an unknown DHCP client to register their hardware before gaining full network access. Through a simple Web interface, the client is prompted for their user identification. Powerful scripts then retrieve the client's network fingerprint and store it along with the user's information in a database. The database provides administrators with real-time information for troubleshooting and auditing their networks. The entire system was developed utilizing unmodified, open-source servers and in-house developed CGI programs."
NetReg Scan (Active Detection, Remediation)
http://www.security.uconn.edu/old_site/netregscan/
NetReg Scan is a simple extension to Southwestern's NetReg to allow it to detect computers vulnerable to Windows DCOM vulnerabilities and redirect them to a static remediation page. Once a host passes the pre-registration scan, it is allowed to access NetReg and register normally. NetReg Scan looks for a single vulnerability and, as such, is currently only useful as an example of a simple automatic detection and remediation system.
PacketFence (Remediation, Registration, Active/Passive Detection)
PacketFence is an open-source network registration and remediation application with layer2 redirection functionality.
PacketFence provides a method of registering every system (MAC address) to a corresponding student (user ID). In combination with a MAC->IP audit trail that PacketFence maintains, this allows for easy resolution of DMCA violations. The worm mitigation and remediation features of PF allow for detection and self-remediation of known worms with (in theory) no IT staff involvement. One of our most innovative features - passive mode - allows PF to be installed as any other host on the network. This requires no network configuration change and provides a fail-open solution. In this mode, PacketFence uses ARP cache manipulation to inject itself into a client datastream.
Radiator (Registration)
http://www.open.com.au/radiator/
Radiator is a highly configurable and flexible Radius server that supports authentication by a huge range of authentication methods such as Flat files, DBM files, UNIX password files, SQL databases, remote Radius servers (proxying), external programs, NT User Manager, Active Directory, LDAP, PAM, iPASS, GRIC, NIS+, Tacacs+, and a wide range of ISP billing packages such as Emerald, Platypus, Rodopi, Hawk-i, Interbiller98, Freeside and so forth.
ScanLite (Active Detection)
http://www.cpan.org/modules/by-module/Net/Net-Nessus-ScanLite-0.01.readme
Net:Nessus:ScanLite is a perl module "designed to perform a fast authentication and request a Nessus attack on a given host. This module takes advantage of the Nessus NTP 1.2 protocol's fast_login mechanism. In the past Nessus would send a plethora of information about all the plugins it knows about, which could take minutes. Systems that can benefit from this module include a CGI self scan and NetReg type applications. This module does not speed the latency or duration of a Nessus scan, which is primarily determined by the plugin_set and preferences such as autoenabling dependencies."
User Tracking (Remediation)
http://www.sourceforge.net/projects/usertracking
Usertracking is a project licensed under GPL aiming at tracking and tracing abuse of users connecting to the network using 802.1X authentication. The project tries to do that by combining the contents of various logfiles (DHCP, RADIUS) as well as by actively monitoring (ARPWATCH). The result of this analysis is a database essentially containing user ID, IP address, MAC address, and timestamp tuples.
Available commercial solutions are summarized below to provide an overview of the different methods each vendor is using. We do not specifically endorse any commercial product or vendor, although we may recommend an ideal process at a later date. Vendors are listed in alphabetical order.
Bradford Campus
Manager and Remediation
System
http://www.bradford-sw.com
The solution initiates an active detection scan through Nessus and has a list of the set of switch manufacturers to which it can speak. Basically, the Campus Manager (CM) "learns" information about all edge switches and presets a VLAN ID on a per port basis. When users connect to that port, they are automatically assigned to a configuration VLAN (registration [to register a MAC for DHCP], quarantine [for network/vulnerability scanning from the "Remediation System"], or full-access). The system can speak LDAP, RADIUS, and SNMP and send e-mail alerts.
Cisco NAC
http://www.cisco.com/warp/public/cc/so/neso/sqso/csdni_wp.htm
NAC works at layer 3 (routers, VPN Concentrators - Cisco only). You must also have the Cisco ACS Server which actually actively writes and removes ACLs to the closest Cisco router based on whether the client has the Cisco Trust Agent (CTA). The CTA can force the user to install the Cisco Secure Agent (CSA) before the ACS writes the "permit" ACL to the router. CSA/CTA clients are available for Windows and Solaris 8. Scalability information for the ACS boxes is not known, but the current iteration of the Management Console for the CSA can allow up to 10,000 licenses. NAC for the 6500 Series is not yet available.
Perfigo CleanMachines
and SecureSmart
http://www.perfigo.com/products/securesmart.html
http://www.perfigo.com/products/cm.html
Perfigo uses the concept of a "virtual gateway" and has an optional client agent. You can mandate the client for access or leave it optional. The software agent is required for more thorough registry checks (antivirus version, def/dat version, and so forth) but Perfigo still uses Nessus for the network scanning piece to verify any patch level for which Nessus can check. The Web pages that are presented to the end user for authentication and remediation are customizable. Though acquired by Cisco, the CleanMachines and SecureSmart product lines are still distict from the general Cisco CTA/CSA products.
Still Secure Safe
Access
http://www.stillsecure.com/products/sa/
Still Secure Safe Access requires an admin password or admin-level account information to check for vulnerabilities on the host. It uses a captive gateway to trap all traffic and an active scan for detection. The gateway then either blocks the traffic, redirects it to a isolation network, or allows it to access the Internet.
Sygate Secure Enterprise
http://www.sygate.com/products/sygate_secure_enterprise.htm
This solution offers agent-based detection, automated remediation, and a captive gateway that blocks access, isolates it into remediation networks, or allows access.
8. LEGAL AND POLICY IMPLICATIONS
One should always consider the legal and policy implications of a new technology before deploying it pervasively. Sometimes, the impact is minimal or nonexistent. However, in this case, there could be legal and policy implications if your institution transitions from an open-access network to one that contains access restrictions, authentication requirements, scanning, and a link between individuals and the traffic they generate. In broad terms, the issues fall into three categories: government regulations, policy implications, and liability. Below, we have outlined a few issues related to each category.
I. Government Regulations
These issues are currently focused on government regulations in the US. Similar regulations likely exist in other countries, but are not covered by this document.
A. Educational institutions are generally restricted from releasing student educational records under FERPA. What information collected by this system is protected by FERPA? What restrictions do you need on who can access this information?
B. COPPA restricts the types of information one can collect from children 13 years old and younger. What modifications need to be made if someone 13-years old or younger might access your network?
C. In general, Internet service providers and telecommunications carriers are not liable for the content that traverses their networks if they fall into the common carrier status. This status is premised on limitations to what institutions do to control or collect information from their networks. How might this process impact a network's common carrier status, especially if certain detection measures are implemented?
D. Public institutions, like all government agencies, have special restrictions and requirements placed on them relating to the public information that they collect about individuals and information that they must make available for public inspection. If you are a public institution, what information are you required to collect for purposes such as transaction tracking, census information, auditing, etc? What information are you restricted from collecting?
II. Policy Implications
A. What is the privacy policy related to this information?
B. How does the storage and archiving of this information relate to your institutions general policy on records management and retention?
C. What are the circumstances around which a host will not be allowed on the network? Are there "black out" periods, such as finals week, where no systems will be isolated?
D. If you build your own custom software, do you have a license agreement for it? Is it open source? Public domain? If you designed your own software, are there any intellectual property issues related to its development and use? Can employees use this software if they leave your institution or post into public forums the source code and details of its operation?
E. If you are charging students for network access, does your access agreement contain language that allows you to discontinue service?
III. Liability
A. If you require or recommend a client-side software agent, what liability are you assuming for the end user's system? What if the software is licensed from a third party? Open source? Homegrown?
B. If you build your own software and it damages an individual's system, are you liable for those damages? What if the discontinuation of network services itself causes damage to an individual (e.g. prevents them from completing class work or causes them to fail a course and thus forfeit the tuition for that class)?
C. Is your institution more or less liable for network security incidents by doing something, even if it is not a perfect system, than by doing nothing? If your institution makes security claims, what liability are you assuming if these claims are not met or if the system fails?
D. If you are using a local source for remediation, are you violating any licensing or legal agreements by rehosting an outside vendor's patches?
This is an alphabetical list of the organizations that are looking into solutions in this space. This summary was created by the SALSA-NetAuth working group, which is part of the joint Computer and Network Security Task Force of the EDUCAUSE and Internet2 communities. These are direct quotes from the organization's Web sites, with links provided for further information.
EDUCAUSE/Internet2
Computer and Network Security
Task Force
http://www.educause.edu/security/task-force.asp
"The Security Task Force actively promotes effective practices and solutions for the protection of information assets and critical infrastructures. The Security Task Force is coordinating its efforts on behalf of institutions of higher education with the support of the Higher Education Information Technology Alliance."
EDUCAUSE Cybersecurity
Resource Center
http://www.educause.edu/security/
"The Web site is intended to be a focal point of information and resources on computer and network security for the higher education community. The Web site will lead you to content determined to be most relevant by the Task Force."
Internet2 Security
Initiatives
http://security.internet2.edu/
"The Internet2 Security work is oriented towards improving our ability to integrate our advanced networking requirements with network security in an insecure world. It is part of the overall EDUCAUSE/Internet2 Security Task Force and complements other efforts in education, policy, training and related areas. It is advised by SALSA, a group of leading campus network security architects."
REN-ISAC
http://www.ren-isac.net/
"The REN-ISAC supports higher education and the research community by providing advanced security services to national supporting networks, and supports efforts to protect the national cyber-infrastructure by participating in the formal sector ISAC infrastructure."
The ResNet Symposium
http://resnetsymposium.org/
"With the desire to accentuate the living-learning experience at academic institutions, many colleges and universities are delivering high-capacity computing and networking technology directly to students' residential living spaces. These technologies include in-room networking, residence-based computing clusters, multimedia, and distance learning. Associated with these technologies are support issues and information security concerns."
SALSA
http://security.internet2.edu/salsa
"SALSA is an oversight group consisting of technical representatives from the higher education community who will advise on leading edge technology issues, provide prioritization, and set directions in the security space. SALSA is affiliated with the EDUCAUSE/Internet2 Computer and Network Security Task Force, but is independent of both organizations. SALSA will be future-oriented and state-of-the-art in nature, focusing on high performance and advanced networks."
SALSA-NetAuth
http://security.internet2.edu/netauth
"The SALSA-NetAuth working group will consider the data requirements, implementation, integration, and automation technologies associated with understanding and extending network security management related to authorized network access, style and behavior of transit traffic, and forensic support for investigation of abuse."
TERENA Taskforce
on Mobility
http://www.terena.nl/tech/task-forces/tf-mobility/
"TF-Mobility is the forum in which most European NRENs (predominantly) work on issues related to roaming access to each others networks."
If you are interested in this topic and want to help us explore it, here are ways to become part of the process:
* Participate in the NetAuth discussion group
To subscribe to the NetAuth list, send email to sympa AT internet2 DOT edu, with the subject line:
subscribe salsa-netauth
Participation in the working group is open to all members of the EDUCAUSE / Internet2 community.
* Contribute to future documents
This summary is just the beginning of what we hope NetAuth will accomplish. Join the discussion group and become actively involved in our next projects.
Thanks to the many people who contributed to this document:
Kevin Amorin
Harvard University
Jason Azze
Fairfield University
Jeff Bollinger
University of North Carolina
Robert Lowe
Lawrence University
Kevin Miller
Duke University
Christopher Misra
University of Massachusetts
Jonathan Moore
University of Pennsylvania
Rodney Peterson
EDUCAUSE
Mark Poepping
Carnegie Mellon University
Martin Schulman
Juniper Networks
Klaas Wierenga
SURFNet
APPENDIX A: References and Documents of Interest
Deraison, Renaud and Ron Gula. Using Nessus to Detect Wireless Access Points. http://www.tenablesecurity.com/images/pdfs/wap-id-nessus.pdf. May 5, 2003.
Miller, Toby, Passive OS Fingerprinting. http://www.sans.org/rr/special/index.php?id=passiveos. 2001.
Phaal, Peter. Detecting NAT Devices using sFlow. http://www.sflow.org/detectNAT/
Lowe, Robert. NATfinder. http://www.lawrence.edu/fast/lower/NATfinder.html. December 2004.
Bellovin, Steve. A Technique for Counting NATted Hosts. http://www.research.att.com/~smb/talks/findnat.pdf. November 15, 2002.
Kohno, Tadayoshi, et al. Remote physical device fingerprinting. http://www.caida.org/outreach/papers/2005/fingerprinting/. March 1, 2005.
Draft 02 to Final Version (1.0) Summary:
1) Edited the final sentence of the first paragraph to make it less conversational. 2) Added sentences to the second paragraph regarding FWNA sub-group 3) Complete rewrite of 3rd paragraph and integrated into the 4th paragraph 4) Removed note about "late-summer" in 4th paragraph
Challenge:
1) Expanded scope of first sentence by adding "and other large-scale end user networks"
Impact:
1) Added "and notified" in the 2nd sentence of final paragraph
Value: 1) Changed "registration" to "authentication" in first sentence of the first and second paragraphs. 2) Added updated language in 2nd paragraph detailing role-based network access policies
Common Process: 1) Updated the steps to five by adding "notification". 2) Under registration, cleaned up language of the first paragraph. 3) Under registration, added brief section on the types of registration systems, both by OSI layer at which access is checked as well as how often it is checked. This section likely needs review as well as a pro/cons section. 4) Under Detection->Passive, cleaned up language in the Pros and Cons sections 5) Under Detection-Agent, minor language changes 6) Changed the ordering in Detection->Agent making Open Source/Public Domain second and Commercial agents third. 7) Under Isolation->Vlan, minor language change 8) Added a Notification section before Remediation. 9) Under Remediation's first paragraph, removed sentence that pertained more to the "notification" section. 10) Added two paragraphs relating to the registraiton process and NAT devices. Special thanks to Robert Lowe of Lawrence University 11) Added ARP section, provided by Kevin Amorin of Harvard, to the ISOLATION list.
Commercial Solutions: 1) Added line in the Perfigo section regarding the Cisco acquisition.
Legal and Policy Implications 1) Updated the language in the first paragraph
Acknowledgements 1) Added Kevin Amorin and Robert Lowe
OTHER: 1) Added an appendix with paper references provided by Robert Lowe of Lawrence University for NAT detection.