Response to "Cybersecurity information exchange framework"
|To||ITU-T SG 17|
Liaison Statement To: ITU-T SG 17 For Information Source: IETF Security Area Directors Subject: Re: Cybersecurity information exchange framework Thank you for the liaison statement describing SG17’s new cybersecurity information exchange framework (CYBEX) standardization initiative. Automated mechanisms for the exchange of cybersecurity information are a critical requirement for incident reporting and enable collaborative and coordinated incident response. Given that security incidents often cross enterprise and national boundaries, the IETF Security Area applauds SG17’s efforts. The IETF also appreciates that the CYBEX framework imports existing standards and de facto standards where appropriate. In particular, we note that CYBEX references IETF-developed standards (e.g., IODEF) and independent stream RFCs (RFC 3924). Inclusion of these specifications in CYBEX both recognizes and enhances their value to the community. While recognizing the utility of this effort, the IETF is not contemplating a framework level effort of its own. Based on our review of the liaison and the accompanying documents, if a framework is needed to support IETF standardization activities, referencing CYBEX would be the preferred mechanism. The liaison statement indicates SG17’s desire to extend RFC 5070 (IODEF) to support CYBEX reporting requirements. The working group that developed IODEF has closed. Current activities in this space are in focused in the Message Abuse Report Format (MARF) working group which uses a competing format. We do not believe that the MARF work precludes development of new versions of IODEF, or other work leveraging IODEF, but do not expect such work to occur in the IETF. The IETF is not currently developing new specifications based on IODEF, so the proposed SG 17 activities to address new areas of crime or misuse would not create conflicts or redundancies. IODEF was meant to be extensible, so it is likely that these areas can be addressed without revising the base specification. In this case, SG17's specifications would simply reference RFC 5070, instead of creating a new version of IODEF. The Security Area suggests that ITU-T register any new specifications with the Internet Assigned Numbers Authority (IANA) so that all IODEF registrations are collected in a single registry. If revisions to the base specification are essential, the process becomes more complicated. There does not seem to be sufficient interest in IODEF within the IETF to support development of an IODEF version 2. If SG17 has the energy and interest to pursue this work, it is probably in the best interest of the community to transfer change control of IODEF from the IETF to SG17 so that a new version can be developed. The IETF process for transferring change control requires demonstrating rough consensus among IETF participants. This process involves drafting and publishing an IETF stream RFC. We suggest reviewing RFC 4663 as an example of such an RFC. (The document is available at http://tools.ietf.org/html/rfc4663). This process includes an IETF-wide “Last Call” and evaluation by the Internet Engineering Steering Group (IESG). This process can be completed in a few months, assuming the proposal is well received by the IETF community. We should note that IETF does not hold the necessary copyright licenses to permit transferring change control of RFC 5070 at this time. (Since the publication of RFC 5378, the copyright statements were changed to ensure that the IETF will have the necessary rights to transfer change control for work initiated after that time. Unfortunately, IODEF predates 5378.) It will be necessary to identify the various contributors and persuade each of them to provide an updated license agreement. One of the chairs of IODEF has offered to assist with this process, should SG 17 decide to request change control. There are other efforts underway or under consideration within the IETF that could potentially contribute to the CYBEX framework. As noted above, the MARF work is focused on development of an Abuse Report Format (ARF) for reporting email abuse. The base specification for ARF has been published as RFC 5965, and work on two additional specifications (discovery mechanisms and acceptance criteria) is underway. While the collision of acronyms with the Assessment Result Format (also known as ARF) is unfortunate, we believe RFC 5965 and the companion specifications would complement the existing CYBEX standards. In the IT Asset Management Domain, the IETF has two families of standards that should be considered for inclusion in CYBEX. The SNMP protocols and the various management information bases (MIBs) defined by the IETF are a widely used to manage assets based on IETF protocols. The netconf protocol and YANG modules provide an XML-based mechanism for managing the same assets. While the MIBs and YANG modules defined by the IETF are specifically tailored to manage assets based on IETF protocols, the SNMP and netconf mechanisms are generally applicable. The SCAP family of specifications, and their relationship to the IETF specifications, were the subject of a Birds of a Feather session at the Beijing IETF. The purpose of the BOF was to inform the IETF community about SCAP and identify areas of synergy. We greatly appreciated the participation of Mr. Takeshi Takahashi in the BOF to highlight the importance of SCAP to the CYBEX efforts. It would be premature to speculate as to IETF standardization activities but any work the IETF would choose to perform in this area should only enhance the value of CYBEX in the Internet. Finally, upon reviewing the compendium of “Network forensic and vulnerability organizations”, we suggest adding the Messaging Abuse Reporting Format (marf) working group to the current IETF list. The marf charter is available at http://datatracker.ietf.org/wg/marf/