| Body: | 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/ |
datatracker.ietf.org