Subject: [mile] FW: IODEF Reference Format for Enumerations

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 20 Jul 2012 14:12:56 -0400

Please find a previous thread below describing three possible options to embed identifier references in IODEF.  This sums up various options for identifier references in SCI and IODEF.

Sincerely,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Monday, April 09, 2012 2:38 PM
To: [email-masked]
Subject: [mile] IODEF Reference Format for Enumerations

All:

There is an identified need to specify a format to include relevant enumeration values in an IODEF document.  The initial idea is to place enumeration values and their references in IODEF's Reference class.  There are several ways to accomplish this goal.  I'll do my best to enumerate some options here, then I hope to hear some feedback/opinions about the different approaches from the list.

>From the Structured Cybersecurity Information draft (draft-takahashi-mile-sci-02), we may be interested to include the following (not an inclusive list) enumerations in an IODEF document:
CAPEC, CCE, CPE, CVE, CWE, IEC 19770-2.

The IODEF Reference class is described in 3.9.1 of RFC 5070, where a Reference must have a ReferenceName and zero or more of URL or Description respectively.

For each option described below, we can consider use of the IANA registry.
The registry may be used to identify the identifier category and potentially the appropriate identification format for that category.

Option 1: Simple ID
===================
The first option would simply embed the relevant identifier in the ReferenceName element of the Reference class.  This may look like the
following:

    <Reference>
        <ReferenceName>id</ReferenceName>
        <URL>http://www.example.com/path</URL>
        <URL>http://www.otherexample.com/path</URL>
        <Description>Description</Description>
    </Reference>

Using this option, a variety of specific identifier formats could be specified.  CVE, for example, would start with "CVE-" and this convention may be registered in an IANA table.

No changes to IODEF are required for this option.

Option 2: ID with coupled ID type
=================================
The second option would prepend the identifier with it's type, which may look something like the following.

    <Reference>
        <ReferenceName>id_type:id</ReferenceName>
        <URL>http://www.example.com/path</URL>
        <URL>http://www.otherexample.com/path</URL>
        <Description>Description</Description>
    </Reference>

Using this option, a variety of specific identifier types could be specified, such that the identifier itself would not necessarily be constrained, nor would new identifier formats necessarily need to be specified in the future.  An IANA table may be used for this solution as well.

No changes to IODEF would be required for this option.

Option 3: ID with type expressed in Reference attribute =======================================================
The third option would require opening IODEF to update the Reference class with an attribute, which may look something like the following.

    <Reference registryId="id_type">
        <ReferenceName>id</ReferenceName>
        <URL>http://www.example.com/path</URL>
        <URL>http://www.otherexample.com/path</URL>
        <Description>Description</Description>
    </Reference>

Changes to IODEF are required for this option.

----

I look forward to fielding responses to these options, including any additional options you may see, but which are not listed.

What is your solution preference?

Regards,

Adam W. Montville | Security and Compliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815

TRIPWIRE | Take CONTROL
http://www.tripwire.com

_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile