Salsa-CSI2 call
Thu 16-Mar-06

*Attendees*
Chris Misra, U. Mass (Chair)
Phil Deneault - Worcester Polytechnic Institute (WPI)
Brian Smith-Sweeney, NYU
Doug Pearson, Indiana/REN-ISAC
Jim Lowe, U. Wisconsin
Renee Frost, Internet2
Mark Poepping, CMU
Charles Yun, Internet2
Steve Olshansky, Internet2 (scribe)

*Action Items* New

[AI] {Chris} will send out a list of Security-related sessions at the Spring Internet2 Member Meeting (I2MM)

[AI] AI {Group} send related link suggestions for the CSI2 website to {SteveO}

[AI] {Group} if anyone has suggestions along noise reduction approaches for darknet data, please float to the list.

*Discussion*

- Working Group Mechanics -
The CSI2 website now live, linked from Security page. http://security.internet2.edu/csi2/ Minutes from these calls will be sent to this list in draft form, as is standard for Internet2 Working Groups, if you have any comments or corrections please either discuss them on the list or send them privately to Chris and SteveO. On the subsequent call they will be approved and posted publicly on the website.

- Upcoming Meetings/Conferences -
There will be a CSI2 dinner at the upcoming Security Professionals Conference 10-12 April in Denver, the dinner will be Monday 10-April. If you will be at the conference and would like to attend the dinner please RSVP to SteveO no later than COB 3-April (see mail to this list 16-March).

Several sessions at the workshop are relevant to our work, including pre-conference seminars, see the website program for details: http://www.educause.edu/sec06

There will be a number of Security-related sessions at the upcoming Internet2 Spring Member Meeting, April 24-26 in DC, see the website program for details: http://events.internet2.edu/2006/spring-mm/

[AI] {Chris} will send out a list of Security-related sessions at the Spring Internet2 Member Meeting (I2MM)

- Data that may be useful to share -
Chris and Doug sent recent presentations to this list, and a link to an example darknet map. All are now posted on the CSI2 page. See for reference Doug's note to the list 2-Mar-06 about shared darknets. Comments on this are welcome, please discuss via the list.

Noise reduction is a problematic issue in interpreting the data collected from darknets. A lot of it seems to originate from P2P applications doing firewall traversal. Statistical analysis techniques would be a logical tool to bring to this, if anyone has suggestions along this line please float to the list. Examples of data containing this noise would be useful, for further research, REN-ISAC will look into anonymizing out the destination addresses and sharing this in the future.

U. Mass and REN-ISAC are working on a MOU for sharing a variety of data, more to come on this. Do any others in the group have interest in participating in this? NYU may be interested...

[AI] {Group} if anyone has suggestions along noise reduction approaches for darknet data, please float to the list.

How do IODEF (Incident Object Description and Exchange Format) and RENOIR (Research and Educational Networking Operational Information Repository) fit into this picture, if at all? Do they act on the data from the collectors to the central hub which does the distillation, or does it act downstream from the hub?

RENOIR would fit in the latter, but not so well in the former? Per Phil "RENOIR is a system designed around the concept of ticket system used for handling security data from a vast array of sources and organizing that data into individual high-level cases which can then be used for reporting on daily operational incidents."

IODEF event definition may prove useful in this context as well. In addition to having an incident-level classification, it has a (lower level) event-level classification.

Our near term goal is get started with tools we know, get some analysis underway to determine what information can be derived and how useful it is, before looking at formatting, XML etc. One possible approach may be to input flows collected from darknets into RENOIR, and use IODEF as the message transport for disseminating information about hits that may be relevant.

IODEF Refs:
Extended Incident Handling (inch): http://www.ietf.org/html.charters/inch-charter.html
RFC 3067 http://www.ietf.org/rfc/rfc3067.txt

The darknet map referenced above seems to be a useful tool, and it was observed that visualization tools in general are highly desirable in this area.

For further reference see Phil's mail to the list 15-March discussing RENOIR and IODEF, and how they could potentially fit into our mid-range goals for a shared incident handling infrastructure.

Defining an "incident" will likely be an important factor affecting our approach to tool development. An example would be a botnet attack spanning several days or weeks, originating from a number of hosts and targeting a number of sites, which ought logically be viewed as a whole rather than a number of discrete attack incidents. A useful incident tracking system thus ought to have the ability to aggregate incidents intelligently. Encouraging standardization on IODEF-structured data will be helpful in this regard.

Similarly, diagramming (at a high level) the various components and the nature of the data interchange (I/O) between them would seem to be a very valuable initial exercise, for obvious reasons. The main elements we want to capture include (1) data reporting, (2) repository, and (3) incident handling/ticketing.

- IODEF in relation to EDDY (Diagnostics) -
There is likely good synergy here. EDDY could serve as a transport for the IODEF messages, and offer storage agents etc. in support of this. If there is a pipeline of detectors/analyzers that should look at a number of different messages from a number of different sources, EDDY could facilitate this by extracting the most interesting fields from the source message(s). EDDY is not a tracking system. If there is an archive, and you want to verify that it contains everything that you think it should, EDDY's storage agents could facilitate this. EDDY also is able to query back for source information.

Q: would there need to be an EDDY server at each school?
A: there needs to something able to read/parse messages, but not a server in the traditional sense - the approach is more akin to Unix pipeline and filtering. EDDY Java code for this is set to be released shortly.

Q: Encryption capability in EDDY?
A: EDDY supports SSL transport, and fields within a message could be further encryption if desired. EDDY can also function inline to anonymize source addresses in flows, if that is appropriate.

EDDY's essential function is to normalize and transport events of any type, and it is very flexible.

EDDY ref: http://middleware.internet2.edu/e2ed/

Next call is Thu 30-March 2:30 ET.