Pilot Technical Project Proposal Author(s): Jan Meijer, Robert Morgan, Yuri Demchenko Title: Pilot implementation of the IODEF based Incident Handling 0. Introduction An important component of effective interaction between CSIRTs in handling Computer Security Incidents that may span over multiple networks and geographical and country boundaries is creating and using a common format and convention on Incident information exchange that is needed for a quick and adequate response to ever rising numbers of Computer Security Incidents. CERT/CC attempted to create a framework for common incident reporting and handling, based on their incident repository. Practice shows the framework does not allow for new types of incidents to easily fit in the framework, unambiguous classification of an incident is not possible, and the framework never gained wide-spread use within the CSIRT community. During recent years there were numerous attempt to tackle different parts of this problem. This includes the creation of numerous Vulnerability and Exposure databases that all use their own format for reporting, handling and storing. Another direction of solving the general problem of preventing and reacting on Security Incidents is the development of a common format for Intrusion Detection messages exchange (IDMEF) that again aims to inter-network information exchange about incidents. IDMEF is strongly backed up by industry because of existing and potential big market volume for IDS. This work is supported by the IETF Intrusion Detection WG. The obvious next step in extended Incident Handling is the creation of the common format for Incident reporting and exchange to enable further automation of CSIRT operations. This has been tackled by the TF-CSIRT Incident Taxonomy and Description WG that is developing the Incident Object Description and Exchange Format (IODEF). The first result of the ITDWG work was the publication of the informational RFC3067 on IODEF Requirements. Other WG deliverables include development of IODEF XML DTD and IODEF Data Model, which are also intended to be submitted to IETF. The proposed project aims to create a pilot implementation of the IODEF among a few European CSIRTs and investigate further problems and tasks in deploying Extended Incident Handling scheme/infrastructure between CSIRTs. 1. Objectives o How will the needs be satisfied * To implement IODEF in practice of participating in the projects CSIRTs CERT-NL and JANET-CERT * To develop special API modules for input of IODEF based Incident descriptions into used by CSIRTs Incident Handling/Tracking Systems * To develop XML parser based on XML DTD (or Schema) to convert data to/between database formats used by CSIRTs * Produce guidance for API development by another teams * To progress with Internet Drafts and further development of Extended Incident Handling Scheme based on experience acquired 2. Justification o Demonstrable need o Community backing A pilot implementation is a necessary stage of any new development that especially targets for wide community use. * Pilot implementation of IODEF is needed to progress with further development of standard base (with IETF and in general) * Demonstrable effect of IODEF implementation and use will contribute to creating better cooperation between CSIRT and securing Internet infrastructure by enabling faster and qualitative better exchange of incident related information * Successful implementation of the IODEF will contribute to TERENA and TF-CSIRT recognition in Europe and worldwide, it may also attract industry support and contribution * IODEF development is a first Europe initiative in an area where all previous attempts have been US based. The IODEF development is a product of TF-CSIRT and ITDWG. The results of the IODEF developmen have been presented at all previous TF-CSIRT Seminars and the need for pilot implementation in the frame of TERENA Pilot Project has been agreed at the last TF-CSIRT meeting. Besides this the IODEF work as a component of Extended Incident Handling Problem found interest among the IETF community and particularly from the IETF IDWG. CERT/CC and Symantec have also agreed to work together on the problem. 3. Deliverables and timetable o Timetables o Phases, cut off points Deliverable Description Months Participants after project starts D1 Initial stage: 1-4 TERENA, * Finalising and testing IODEF SURFnet, JANET XML DTD * Setting cooperative development infrastructure between participants, purchase of SW * Selecting SW components, e.g. XML parser * Obtaining necessary information for developing APIs for used Incident Handling systems, e.g. Remedy, Magic TSD, etc. * Writing down requirements for APIs D2 Development of suggested APIs and 3-9 SURFnet, JANET other components for Incident information exchange D3 Implementation and testing 7-11 SURFnet, JANET, other volunteers D4 Preparing recommendations and 10-11 TERENA, describing experience, wring SURFnet, JANET recommendation for further developments D5 Writing TERENA Technical Report 12 TERENA, SURFnet, JANET 4. Resource Requirements o Estimate TERENA staff effort required 1/8 FET PDO o Direct Financial Support needed Total - 5 man months at 3,000 euro per mo 15,000 o Additional Effort Resources needed o Hardware / Software Resources needed XML Authoring tools estimated 2,000 5. Contribution Commitments to the Project o Commitments of project partners and other parties in terms of money, manpower and/or equipment. CERT-NL and JANET-CERT intent to support this project by providing dedicated project developers for the total duration of the project. Estimated amount is SURFnet 25 man days nil JANET 25 man days nil It is anticipated 2 to 3 project-development meetings may be required over the projects lifespan. Travel costs for these specific project-development meetings will be refunded by TERENA at the prevailing rate. The project team would like to request from TERENA the reservation of contingency funding in the amount of 5,000 Euro for ad-hoc expenses for traveling for person(s) other than SURFnet, JANET or TERENA members of the development team, expert or consulting services. These expenses will be subject to a separate request to TERENA. 6. Evaluation Criteria o Critical Success Criteria by which the project is to be judged * Working Demonstration system implemented into daily practice of participating and volunteering CSIRTs * Community adopted technical documents, e.g. Internet Drafts, Recommendations, Guidance o Evaluation Method Proposed and Proposed Evaluators * TF-CSIRT discussion and approval. Three weeks before a TF-CSIRT meeting a short status-report will be send to the TF-CSIRT mailinglist.