Salsa-CSI2 Conference Call
February 15, 2007

*Attending*
Chris Misra, U. Mass (Chair)
Brian Smith-Sweeney, NYU
Phil Deneault, WPI
Doug Pearson, Indiana/REN-ISAC
Kevin Amorin, Harvard
Lynn Little, Internet2
Dean Woodbeck, Internet2 (scribe)

*Action Items*
[AI] {Phil} Develop RENOIR agenda for the March 5-6 working group meeting.

*Carryover Action Items*
[AI] {Chris} Place on the agenda for the next call: boundary conditions for sharing data from shared darknet.
[AI] {Doug} In terms of programmatic interfaces with REN-ISAC data: {Doug} will determine concerns of Information resources at REN-ISAC; {Phil} will post his code to the list; {Brian} will discuss the hashing idea with his resources.
[AI] {Chris} Add WCLSCAN to agenda.
[AI] {Doug} Organize a call to have a discussion with those who want to actively participate in getting data from their institution to the shared darknet.
[AI] {Chris and Doug} Connect with NoX GigaPOP folks for Arbor information.
[AI] {Chris} Create project plan on using UMass for first data source for shared darknet.
[AI] {TBD} Normalizing data and noise reduction -- put together suggestions of what makes sense to be done at the end-user site and what makes sense to do centrally (to list and to wiki).

*Discussion Items*

RENOIR
The RENOIR document is posted on the Internet2 web site. Phil will be submitting the document to several places, including REN-ISAC, Educause and Unisog, and will post it to other lists.

Encryption Keys: One of the next questions to answer is where to store RENOIR data encryption keys, on the server side or client side. If RENOIR eventually uses a web-based client, what affect will that have? The tentative plan is to put the keys on server side. Phil believes the question is really how this will be done. If the keys are all in one place, even if encrypted, what mechanisms have to be modified to move data back and forth from server to client? If we later decide to do a web-based client, what is the benefit and what do we lose?  What effect will there be if we use the browser for transport and rendering?  

Data Retention: What deletion/retention policies should be specified and allowed? Should the data creator be allowed to mandate how long a document is retained? Doug mentioned that this could interfere with the ability to assess trends and perform other analyses.

Phil sent an email on January 8 with different options for saving tickets and purging data. One option is to use a simple deletion flag. Any item with this flag would be stored for a specified number of days. There could be different levels of data, with the purge date based on the encryption level. If the data is informational or descriptive, it could stay indefinitely. Encrypted tickets could be purged after a certain amount of time since access is limited and their long-term value is not as great.

Doug asked whether encrypted tickets would include non-encrypted meta information to use for analyzing trends. Phil said that some information with each ticket is unencrypted and could be used this way. The general metadata available includes the type of information included (darknet, informational, etc), release level, date crated/modified, the names of those who have access, and some history.  

When people create tickets, Phil said he felt it best if the default would not be "encrypted," but "limited access," meaning only those involved (plus REN-ISAC) can view and edit the ticket, but the information is not encrypted. This allows tracking trends and performing analyses without worrying about encryption.

Doug mentioned that once RENOIR is up and running and reports are developed, we may want to go back and enhance the metadata. Phil said this is possible.

Phil also said the only encrypted information is the content field, which is in XML and constitutes the meat of the ticket. Everything else is unencrypted in a database style. The owner information is stored in metadata, since we need to know who created and is accessing the ticket.

Doug asked whether RENOIR has a mechanism to send items as a batch. He said there will be incidents that you may want to see immediately, while others could be delivered in a batch at specified time intervals. Phil said that right now, RENOIR is storage. Moving tickets all at once or one at a time is an implementation detail that needs to be worked out.

Brian mentioned that RENOIR will need a best-practices guide at some point. Phil's hope is that implementation bugs are dealt with as they arise, as the number of users ramps up and we see how RENOIR is used.

Chris said these are good things to work out at the workshop. [AI] {Phil} will take some of the questions related to encryption keys, data retention, and other RENOIR issues and form an agenda for a portion of the workshop.

******
Cybersecurity Registry
Doug is working on a schema for the Cybersecurity Register, trying to determine how organizations and sub-organizations fit together. This is made complicated by having some participating institutions that are very centralized and others that are very de-centralized.

Doug said REN-ISAC explicitly supports medical schools as separate entities, but tends to discourage other sub-entities.

Chris suggested that the concept of a relational database may be more useful than thinking of a hierarchy of organizations and suborganizations. For example, a suborganization may not be a subsidiary, but have some other relationship with the main organization. The system under discussion may be trying to make organizations fit a data model, as opposed to the data model reflecting reality. We may need to register institutions and have relationships encoded one way and relationships between them encoded another way for the purposes of REN-ISAC.

******
CSI2 Working Group meeting

The meeting is scheduled for March 5-6 in Cambridge, MA, in a hotel near Harvard Square. A draft agenda is posted. If any working group members have suggestions others to invite, please let Chris know ASAP.

******
REN-ISAC face-to-face

Attendance at this meeting in April will be capped at 50 and there are already more than 20 registered. If you are planning to register, do so soon. Doug is sending a reminder to the REN-ISAC list with an agenda.

******
The next call is scheduled March 1, to be used for finalizing the agenda for the working group meeting on March 5-6.