ISP Information Sharing & Analysis Center

Kelly J. Cooper kcooper at
Thu May 31 23:36:58 UTC 2001

This is a recap of my presentation Tuesday at NANOG22 about creating 
an information sharing and analysis center (ISAC) to help coordinate 
the resolution of Internet problems. We'd like broad participation in 
helping to form this ISAC.  If you'd like to be part of the process, 
please join the ISP-ISAC discussion mailing list, by sending mail to:

  isp-isac-d-request at

(It's a person at CNRI, so the response won't be instantaneous.)

And for anyone else who's interested in creating a shared-resource for
all types of ISPs and making it work, please consider signing up.  I'd
be happy to answer any questions you might have (although the bigger
questions will probably require discussion on the mailing list and
possibly in person).

Kelly J. Cooper
Security Engineer




o An Information Sharing and Analysis Center (ISAC) is loosely defined
  in President Clinton's 1998 Presidential Decision Directive 63
  (PDD-63) as a "mechanism for gathering, analyzing, appropriately
  sanitizing and disseminating private sector information ... for
  sharing important information about vulnerabilities, threats,
  intrusions and anomalies"

o ISACs were suggested by the President's Committee on Critical
  Infrastructure Protection (PCCIP) in their October 1997 report
  CRITICAL FOUNDATIONS: Thinking Differently

o The basic idea is to share, correlate, and analyze information in
  order to protect critical infrastructure

o ISACs currently exist or are planned for financial services,
  telecommunications, transportation, and the power utilities


o IOPS, together with a few other ISPs and service providers, thought
  it would be good for the industry to create an ISP-ISAC to solve
  problems that cross the boundaries of economics and competition; the
  design would allow for participation by a wide range of service

o The proposed goal for this ISAC is: to help coordinate the
  resolution of Internet problems and to help protect the Internet

This goal will be achieved through:

1. Communication - by creating and using a framework in which
   information about incidents can be shared by ISPs in real-time, in
   order to mitigate the impact and duration of these incidents

2. Analysis - by creating and using ISP-ISAC databases of both active
   events and informational reports of vulnerabilities, configuration
   issues, etc. in order to establish best practices, identify common
   hardware & software problems, and otherwise forewarn against
   possible future problems

Operating Plan

o The ISAC collects data through reports about outages, incidents,
  concerns, and advisories submitted by members or collected from
  other sources

o The ISAC manages tickets for active issues (opening, notification,
  resolution, closure)

o Members are alerted to both current incidents and other significant

o The ISAC maintains databases of past issues and important
  network-related information

o Analysis and correlation are performed to determine severity and
  possible relation to other data & reports

Organization Plan

o The ISAC will be a Limited Liability Company or a Not-For-Profit

o A support contractor will be hired who will operate and maintain a
  7x24 system that meets the requirements and who will handle the
  day-to-day details

o Budgetary estimate of annual membership fee (to cover costs):

Lessons Learned from Previous Attempts

o Nothing is perfect

o Nothing will work for everyone

o Getting Operators to do this manually is both difficult and cruel;
  automation is key

o No one wants to give up any information without getting something

o No one trusts anyone, so a non-ISP 3rd party vendor is crucial

o This function MUST be someone's job (or it won't get done)

Proposed Requirements

o Possible multiple databases (Active Issues, Historical Issues,
  Informational database)

o Multiple input types (web, formatted email) for initiating reports

o Multiple notification methods (pager, cell, email, etc.) for
  notification, set by each ISP

o Adjustable priorities with appropriate, adjustable notification
  methods (i.e. High priority = pager vs. Informational = email only)

o Active issues & historical databases containing (at a minimum)
  unique tracking code; date; time/time zone; geographical area;
  equipment type; software version; type of incident; brief
  description of incident; subsequent updates attached to incident;
  priority; reporting ISP; affected ISP(s); reports able to be

o Informational database with security information such as threats,
  vulnerabilities, config issues, outside reports, etc.

o 99.98% vendor system availability for databases 

o Multi-homed NOCs

o Disaster recovery capability

o Enough personnel & computing power for 7 simultaneous incidents &
  over 2000 simultaneous recipients of notification (initially;
  scaling required)

o Searchable historical data

o Automation and ease of use

Benefits - What makes the ISP-ISAC useful?

o Participation may help avoid regulation

o Reports (outages or security) that are specific and timely would
  greatly assist with rapid trouble-shooting and problem solving

o Pre-sorted ISP-specific (or network-specific) news reports,
  exploits, security vulnerabilities, and general information for
  dissemination to members are more complete than what an individual
  might find, saving individual sorting & distribution time

o Collected outage data from other sources (peering point vendors for
  the MAEs, NAPs, etc., mailing lists like NANOG & inet-access,
  circuit vendors, performance monitoring companies, other ISACs,
  etc.) & disseminated to the members provides a centralized source of
  information (and again saves sorting time)

o Improved communication between ISPs improves repair times and
  therefore the public's experience of the Internet

o Having the capability to reach out to a significant number of ISPs
  all at once would be helpful during large-scale issues, as would
  assistance in coordinating the handling of such incidents (creating
  a central ticket, coordinating information, sponsoring a bridge
  call, etc.)

o Forums for secure real-time or near-time communication would
  increase the speed of diagnosis:

o Regular conference calls for general discussion

o Facility for real-time response and discussion (bulletin board,
  private chat rooms, or voice bridge) by the Operators themselves

o ISAC vendor-provided language translation skills speed up tracking
  down attacks/routing mistakes

o Quick reference utilities like an access-controlled web page with
  color-coded live issues (culled from vendors, mailing lists, outage
  reports, and chat rooms/bulletin board) for rapid assessment of
  issues impacting any ISP

o Convenience of having one place for locating an accurate,
  well-maintained & up-to-date phone list of ISP NOCs

Why I Am Sending This

  We need your help

Pending Issues

There are many issues that could use some rough consensus from the
community, such as:

o With cost recovery (not profit) in mind, how do we make it
  affordable to as many ISPs as possible while still being able to pay
  the vendor?  (Should larger ISPs pay more?  If so, why?)

o Membership requirements... Who should participate?  (Should there be
  a cut-off?  I.e. if you don't have a 24x7 NOC, you don't get to

o What qualifies as an ISP?  

o Should vendors be allowed to participate?

o What's an outage?  (Meaning, what should be reported to the ISAC?)

o Should there be minimum participation requirements?

o How do we establish trust?

Government Involvement

o MOST FREQUENTLY ASKED QUESTION - Is the U.S. Government involved?

o Currently we are not planning on sending reports to the
  U.S. government (or any other state or country entity)

o We may consider it at some point in the future, but the members
  control the ISAC and make the rules - YOU decide

Current Events

o We're not done yet!  We just wanted to firm up the concept before
  talking to more companies

o IOPS (and friends) have collected sales quotes from a couple of
  possible ISAC Operators and we have talked with other ISACs (plus
  one or two industry experts) on infrastructure protection and
  problem coordination

o I'm looking to discuss the idea, take feedback, & recruit volunteers
  - we want more people to assist in the final formation of the

Next Steps

If you want to participate (please do not join just to be a silent
listener) send mail to:

   isp-isac-d-request at

Reaching Me

If you want to pass along feedback, contact me:

   Kelly J. Cooper
   Security Engineer
   3 Van de Graaff Drive
   Burlington, MA  01803
   kjc at or kcooper at

More information about the NANOG mailing list