SALSA-CSI2 conference call
June 8, 2006
*Attendees*
Chris
Misra, U. Mass (Chair)
Brian Smith-Sweeney, NYU
Phil Deneault,
WPI
Nick DePetrillo, OSHEAN
Doug Pearson, IU/REN-ISAC
Charles
Yun, Internet2
Jim Lowe, U. Wisconsin
Steve Olshansky, Internet2
Dean Woodbeck, Internet2
Jessica Bibbee (scribe)
New *Action
Items*
[AI] {Anyone} who has data to submit to REN-ISAC, please
contact {Doug}.
[AI] {Phil} requests input on the RENOIR schema,
and will continue adding to the wiki.
[AI] {Nick} will add
documents to the wiki, and requests feedback from the {Group}
before the next call.
[AI] {Group} will send ideas to {Charles
or Doug} for discussion at the NewNet meeting next week.
Carryover
*Action Items*
[AI] {Nick} will draft a technical recommendations
document on the Procedure for Submission of Data, and continue
discussion of application-level noise reduction.
*Discussion*
{Chris} is still working on the Project Plan, which stemmed
from the MoU discussion. He said they were ready to submit
data to REN-ISAC. {Doug} will be in touch with David Ripley,
who is working on REN-ISAC programming. [AI] {Anyone} who has
data to submit to REN-ISAC, please contact {Doug}.
{Phil and Brian} have exchanged discussion on encrypted ticket options and schema and encryption levels (cf. emails 7/8-June). Should REN-ISAC employees have access to the data? Functionality is a primary concern, but feasibility of encryption level is also to be considered. {Phil} detailed how a report, history, and comment could be used in the access and encryption level. Secrets would be used to protect the metadata of each submission, and would protect access to the key as well as who has access. Discussion will continue over the CSI2 list. [AI] {Phil} requests input on the RENOIR schema, and will continue adding to the wiki.
{Doug} provided an update on REN-ISAC activities and data disclosure; they are now providing a set of information to members that includes botnet DNS control names and IPS names, which members can use in their monitoring system to ID and react to locally infected systems. Guidelines for sharing information are strict, and there are challenges when a decentralized institution wants or needs to share information. Discussions of rules suggest that in such a case, it may be advisable for multiple departments (etc.) become members of REN-ISAC so that they can apply it to their span of control. Centralized institutions can process the data and disperse information about observed infected systems to various units; this leads to {Phil's} idea of a mechanism to centrally perform tasks with the consent of all involved parties.
Discussion continues on whether to keep data centrally at REN-ISAC or locally at each institution before being passed over to REN-ISAC.
Reverse engineering is always a problem when hashing is available. A sort of filtering may serve to minimize the number of hits. {Doug} offered two options: 1) hand the has list to individual hash administrators for checks on hashes given by REN-ISAC members, and 2) REN-ISAC could run a server service for lookups that act as an aggregate of all other DNS servers at the institution (e.g., a request to central server once per hour.) {Chris} pointed out that all methods should also address security issues, not simply serve as a usable solution.
Charles provided a link to the Internet2 Community Design Workshop <http://events.internet2.edu/2006/designws/>. [AI] {Group} will send ideas on to {Charles or Doug} for discussion at the NewNet meeting next week.
[AI] {Nick} will add documents to the wiki, and requests feedback from the {Group} before the next call.
The next SALSA-CSI2 WG call will be Thursday, June 22, 2006 at 2:30pm ET.