An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information
draft-ietf-mile-sci-13

[Ballot comment]
The -12 version has addressed all the comments I had on the substance of the document, and thanks very much for considering and addressing those comments.  And particular thanks for the work on the Security Considerations section.

I had the following DISCUSS point, which I'm moving down here to a non-blocking comment:

-- Section 5 --

The shepherd writeup is silent about review by any XML schema experts.  How confident are we that the XML in here has had sufficient review?

One of the authors replied to this comment as follows:

----------------------

Regarding the 1st discussion issue, I think the schema is fine, because

1. I myself have been checking the schema by using a schema validation tool, called "MSV".

2. I also have received feedback from a researcher in Japan who has been working for semantic web (that includes XML schema and RDF/OWL etc.)

3. From the MILE colleagues, I've received feedback on 23rd Feb, 2012
(http://www.ietf.org/mail-archive/web/mile/current/msg00553.html)

4. The IODEF-SCI tool we have implemented uses the schema without any error.
(https://github.com/TakeshiTakahashi/IODEF-SCI/wiki/IODEF-SCI-tools)

5. Though minor changes exist, the basic structure of the XML schema hasn't been changed at all almost for two years.

----------------------

On (3), I see that the changes went into the -03 version of the document.  It's good to see that there was some schema review, and that errors were found and changes were made.  Thanks for that confirmation.

For some reason, I still have a nagging feeling about the XML review, but I'm moving to No Objection, and leaving it to the responsible AD to decide whether there's been enough review of the XML schema.  If Sean's OK with it, I'm OK with it.

[Ballot comment]

Thanks for handling my discuss points.

--- old comments below, I didn't check if they'd been
handled, feel free to ping me if I should check
something

- section 3, last para: does this mean we're putting up
IODEF as an alternative to NEA and/or SACM? I think it'd
be better to drop that use-case or if not to distinguish
it from other IETF protocols that do the same thing. (Or
maybe I'm confused?)

- 4.1: I get weirdness when I try to de-reference the
1st reference URI [1], is that just me? I get a
directory listing for the 2nd. [2] When I look at [2]
and load the xsd file I find there, I don't find the
string "AttackPattern." How is that IANA registry entry
going to be useful? It confuses me mightily;-)

  [1] http://standards.ieee.org/develop/indconn/icsg/mmdef.html
  [2] http://grouper.ieee.org/groups/malware/malwg/Schema1.2/

- 4.1: I don't understand the last para at all

- 4.3: s/This draft/This specification/ (Same thing at
the start of section 5)

- section 5: Are you really asking that receiver's do
XML schema validation? You say "MUST be able to" which
is not quite the same, but generally doing schema
validation on the fly is very dangerous and error prone.
Maybe you mean that they MUST be able to process inputs
that conform to the relevant schema and fail-safe for
other inputs that don't conform? But at what level? Say
if an XML document is received that has a Remediation
element with no SpecID - should the entire input
Document be ignored or what?

- section 6: "URGED" in caps is odd, and saying "areas
of concern" but then only having one subsection seems
odd too.

- section 6 generally: I support Barry's discuss

- section 6: Isn't this missing something about access
control and filtering outbound documents?  Maybe all
that's needed is a reference to some other RFC, but
won't it be common to do such authorization and
filtering?

- section 6: You mention signatures - do you mean use of
XMLDSIG? If so, a reference would be good and it'd be
even better to say which element might be signed, and to
check that that element has an ID so the signature
Reference can point to the to-be-signed data.

- section 7: In the absence of a definition of
Cybersecurity, I think its a bad idea to have an IANA
registry with that term in the title.  (Just a personal
opinion.)

[Ballot discuss]


Two relatively easy-to-handle things, or at least I hope
so:-)

(1) Please define or refrain from using the term
"cybersecurity" - I'm not just being pedantic here (I
hope:-) the term is often used to mean different things.
And please define "cyber attack" (used in the intro) as
well.  If you have a favourite definition then just
pointing at that would be fine.

(2) section 7: Is the content you suggest for the new
registry actually conformant to the rules you're setting
up? "xml" might syntactically be a hostname but
"http://xml/..." is not really a good HTTP URI is it?
And what if ICANN auction off "xml" as a gTLD?  And what
does "readily...  available" mean? (Esp since one of the
URIs you use is apparently not available at least for
me, at least right now;-)

[Ballot comment]

- section 3, last para: does this mean we're putting up
IODEF as an alternative to NEA and/or SACM? I think it'd
be better to drop that use-case or if not to distinguish
it from other IETF protocols that do the same thing. (Or
maybe I'm confused?)

- 4.1: I get weirdness when I try to de-reference the
1st reference URI [1], is that just me? I get a
directory listing for the 2nd. [2] When I look at [2]
and load the xsd file I find there, I don't find the
string "AttackPattern." How is that IANA registry entry
going to be useful? It confuses me mightily;-)

  [1] http://standards.ieee.org/develop/indconn/icsg/mmdef.html
  [2] http://grouper.ieee.org/groups/malware/malwg/Schema1.2/

- 4.1: I don't understand the last para at all

- 4.3: s/This draft/This specification/ (Same thing at
the start of section 5)

- section 5: Are you really asking that receiver's do
XML schema validation? You say "MUST be able to" which
is not quite the same, but generally doing schema
validation on the fly is very dangerous and error prone.
Maybe you mean that they MUST be able to process inputs
that conform to the relevant schema and fail-safe for
other inputs that don't conform? But at what level? Say
if an XML document is received that has a Remediation
element with no SpecID - should the entire input
Document be ignored or what?

- section 6: "URGED" in caps is odd, and saying "areas
of concern" but then only having one subsection seems
odd too.

- section 6 generally: I support Barry's discuss

- section 6: Isn't this missing something about access
control and filtering outbound documents?  Maybe all
that's needed is a reference to some other RFC, but
won't it be common to do such authorization and
filtering?

- section 6: You mention signatures - do you mean use of
XMLDSIG? If so, a reference would be good and it'd be
even better to say which element might be signed, and to
check that that element has an ID so the signature
Reference can point to the to-be-signed data.

- section 7: In the absence of a definition of
Cybersecurity, I think its a bad idea to have an IANA
registry with that term in the title.  (Just a personal
opinion.)

[Ballot comment]
I note that the all-caps "URGED" in Section 6 is defined in neither RFC 2119 nor RFC 6169.  Might it be better to say "RECOMMENDED" here?

[Ballot discuss]
I just have two small points, both of which should be easy to address.

-- Section 5 --

The shepherd writeup is silent about review by any XML schema experts.  How confident are we that the XML in here has had sufficient review?

-- Section 6 --
I question whether what's here is sufficient.  Yes, it's important to ensure confidentiality (etc.) of this sort of payload.  But apart from that, are there really no security or privacy concerns involved with reporting such things as incident attack patterns, what software platform the attacks are being made on, what vulnerabilities were exploited by the attacks, and so on?  Is there really nothing further to say here?

[Ballot comment]
-- Section 1 --

  The number of cyber attacks is growing day-by-day

Nit: You're not using "day by day" as an adjective here, so you shouldn't hyphenate it.  Similarly with "machine readable" in a few places: "machine-readable information", but "the information is machine readable".

-- Section 4.5.1 ---

  It is recommended
  that Method class SHOULD contain the extension elements whenever
  available.

2119 usage point: "RECOMMENDED" and "SHOULD" mean the same thing, so why the lower-case "recommended"?  Why not this?:

NEW
  It is RECOMMENDED
  that Method class contain the extension elements whenever
  available.
END

This applies to subsequent sections, as well. You're inconsistent about whether you include "SHOULD", but you are consistent in lower-case "recommended", leaving me a little unsure.  I prefer my version throughout, but whatevere you choose, please make it consistent.

acker.
IANA Actions - YES

Just one edit: we would suggest to make the following edit:

OLD:
http://www.iana.org/assignments/iodef/iodef.xhtml

NEW:
http://www.iana.org/assignments/iodef

This will ensure the URL will always work and point to the most
current version/extension.

Thank you,

Pearl Liang
ICANN/IANA

On Tue Nov 05 14:59:11 2013, iesg-secretary@ietf.org wrote:
> Evaluation for  can be found at
> http://datatracker.ietf.org/doc/draft-ietf-mile-sci/
>
> Last call to expire on: 2013-10-22 00:00
>
>
>        Please return the full line with your position.
>
>                      Yes  No-Objection  Discuss  Abstain
> Sean Turner          [ X ]    [  ]      [  ]    [  ]
>
>
> "Yes" or "No-Objection" positions from 2/3 of non-recused ADs,
> with no "Discuss" positions, are needed for approval.
>
> DISCUSSES AND COMMENTS
> ===========
> ?
> ---- following is a DRAFT of message to be sent AFTER approval ---
> From: The IESG
> To: IETF-Announce
> Cc: RFC Editor ,
>    mile mailing list ,
>    mile chair
> Subject: Protocol Action: 'IODEF-extension for structured
> cybersecurity information' to Proposed Standard (draft-ietf-mile-sci-
> 09.txt)
>
> The IESG has approved the following document:
> - 'IODEF-extension for structured cybersecurity information'
>  (draft-ietf-mile-sci-09.txt) as Proposed Standard
>
> This document is the product of the Managed Incident Lightweight
> Exchange
> Working Group.
>
> The IESG contact persons are Sean Turner and Stephen Farrell.
>
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-mile-sci/
>
>
>
>
> Technical Summary
>
> The document extends the Incident Object Description Exchange Format
> (IODEF)
> defined in RFC 5070 [RFC5070] to exchange enriched cybersecurity
> information .
> It provides the capability of embedding structured information, such
> as
> identifier- and XML-based information. It defines an IANA registry of
> external
> schemas that can be referenced from IODEF documents.
>
> Working Group Summary and Document Quality
>
> The document received extensive review from the working group, which
> led to
> significant changes in the document. Earlier versions of the document
> had
> significant potential IPR issues (references to trademarked schema
> names) as
> well as reference issues (normative references to non-standards
> documents);
> these have all been resolved satisfactorily by moving these references
> to an
> IANA registry of SCI specifications, and providing for long-term
> references to the
> MTI schema, MMDEF.
>
> Personnel
>
>    Brian Trammell is the doc shepherd.
>    Sean Turner is the responsible AD.
>
>
> RFC Editor Note
>
>  (Insert RFC Editor Note here or remove section)
>
> IRTF Note
>
>  (Insert IRTF Note here or remove section)
>
> IESG Note
>
>  (Insert IESG Note here or remove section)
>
> IANA Note
>
>  (Insert IANA Note here or remove section)
>
>
>

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mile-sci-09.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has a question about the IANA Actions requested in this document.

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, in the namespace registry of the IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/

a new namespace will be registered as follows:

ID: iodef-sci-1.0
URI: urn:ietf:params:xml:ns:iodef-sci-1.0
Filename: none
Reference: [ RFC-to-be ]

Second, in the schema registry of the IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry/

a new schjema will be registered as follows:

ID: iodef-sci-1.0
URI: urn:ietf:params:xml:schema:iodef-sci-1.0
Filename: [ as provided in Section 5.2 of the approved document ]
Reference: [ RFC-to-be ]

Third, a new registry called the IODEF Structured Cyber Security Information Specifications registry is to be created.

IANA question --> is this registry to be a new, stand-alone registry, or is it a subregistry of one of the existing registries at:

http://www.iana.org/assignments/

What is the URL address for the new registry?

IANA understands this registry to have the following fields:

Namespace Specification Name Version Applicable Classes Reference
----------------+-----------------------+---------+-------------------+-----------------+

The registry is to be managed via Expert Review and Specification Required as defined by RFC 5226.

There are no initial registrations in the new registry.

IANA understands that these are only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IODEF-extension for structured cybersecurity information) to Proposed Standard


The IESG has received a request from the Managed Incident Lightweight
Exchange WG (mile) to consider the following document:
- 'IODEF-extension for structured cybersecurity information'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-10-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document extends the Incident Object Description Exchange Format
  (IODEF) defined in RFC 5070 [RFC5070] to exchange enriched
  cybersecurity information among cybersecurity entities and facilitate
  their operations.  It provides the capability of embedding structured
  information, such as identifier- and XML-based information.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mile-sci/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mile-sci/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1786/
  http://datatracker.ietf.org/ipr/1787/

1. Summary

The document shepherd is Brian Trammell. The responsible Area Director is Sean
Turner.

The document extends the Incident Object Description Exchange Format (IODEF)
defined in RFC 5070 [RFC5070] to exchange enriched cybersecurity information .
It provides the capability of embedding structured information, such as
identifier- and XML-based information. It defines an IANA registry of external
schemas that can be referenced from IODEF documents.

2. Review and Consensus

The document received extensive review from the working group, which led to
significant changes in the document. Earlier versions of the document had
significant potential IPR issues (references to trademarked schema names) as
well as reference issues (normative references to non-standards documents);
these have all been resolved satisfactorily by moving these references to an
IANA registry of SCI specifications, and providing for long-term references to the MTI schema, MMDEF.

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79.

Sean Turner, sponsoring AD, filed IPR disclosures 1786 and 1787 on this
document on behalf of the IPR owners. 1787 regarding NIST IPR has been
withdrawn. 1786 indicates that the names of MITRE documents which were
previously referenced by this document are trademarked. In any case, MITRE has
indicated to the mile@ietf.org list that it is willing to grant license for
purposes of interoperability should these schemas be added to the resulting
IANA registry, and the schemas themselves have been removed from the present
revision of the document in any case.

4. Other Points

The document creates an IANA registry for schemas to be referenced from IODEF
subject to expert review and specification required, specifying only one such
schema as MTI. The intention is to add additional schemas after the publication
of the document.