To: ITU-T SG 17
Source: IETF Security Area Directors
Subject: Re: Cybersecurity information exchange framework
Thank you for the liaison statement describing SG17’s new cybersecurity
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
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
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
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
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
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
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/