Strategies for Automating Network Policy Enforcement -- (DRAFT 02)

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


SUMMARY

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 is an initial document meant to be the
beginning of ongoing conversations and investigations into
this topic and does not contain any final answers or
recommendations.

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.

Host registration and user authentication are within the
scope of this working group, but will not be covered in this
document.

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. We
understand that the late summer is a bad time to bring new
systems into production, but it is a great time to start
planning for next year. The second document will outline
future requirements of an ideal system designed to embody
all aspects of this process.  We also plan to work with the
Security Task Force's Effective Practices working group to
gather detailed technical summaries of different
institutions' current approaches to this process.


CHALLENGE

The major security challenge facing university residential
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 student 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.


IMPACT

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, 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.


VALUE

Host registration 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 registration allows for fast, direct communication with
whoever is responsible for a particular system, as well as
basic authentication of that party as a known
user. Preventative policy enforcement reduces the total
number of technical security vulnerabilities as well as the
success of a particular piece of malware or attack
technique. 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 COMMON PROCESS

The process common to all implementations involves four
steps: registration, detection, isolation, 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.

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 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 can
  be detected by examining patterns or signatures of
  outbound traffic.  Existing intrusion detection systems
  may be leveraged.  Can detect compromised systems, even if
  such systems operate a deny-all incoming firewall.
  Passive monitoring 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. 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 never 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 not to disable or tamper with it. 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. 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.

  3. 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.


  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 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
  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.

IV. Remediation

Remediation is where some type of corrective action is
recommended, usually on a Web page, and appropriate support
steps or contact information is displayed.  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.


OPEN SOURCE SOLUTIONS

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)

http://www.freeradius.org/

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)

http://www.nessus.org/

"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)

http://www.net.cmu.edu/netreg

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)

http://www.netreg.org/

"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.

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.


COMMERCIAL SOLUTIONS

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.

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.


LEGAL AND POLICY IMPLICATIONS

One should always take a moment to 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, we feel that there
could be legal and policy implications if you transition
your institution 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 below a few issues
related to each category.

I. Government Regulations

These comments are currently focused on government
regulations in the US.  Similar regulations likely exist in
other countries, but are not currently 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?


SYNERGIES AND PARTNERSHIPS	

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
eachothers networks."

HOW CAN I HELP?

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
, with the subject line .  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.


ACKNOWLEDGEMENTS

Thanks to the many people who contributed to this document:

Jason Azze
Fairfield University

Jeff Bollinger
University of North Carolina

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