Liaison statement
Response to "Cybersecurity information exchange framework"

Submission date 2010-11-30
From IETF SEC AREA (Tim Polk)
To ITU-T SG17 (tsbsg17@itu.int, sebek@itu.int)
Cc tony@yaanatech.com
Response contact sec-ads@ietf.org
Technical contact tim.polk@nist.gov, turners@ieca.com
Purpose In response
Attachments (None)
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/