Subject: Re: [mile] Fw: New Version Notification for draft-takahashi-mile-sci-02.txt

From: "Panos Kampanakis" <[email-masked]>
Date: Tue, 8 Nov 2011 18:33:50 -0500

Hi Take,

A few comments/questions: 

1) Some extended classes apply only to some Specifications. For example, a
Vulnerability class can be OVAL, CVRF spec but not CEE or OCIL. In the same
manner an Event Report class cannot have a SpecificationID of CAPEC_1.6 or
OVAL. A PlatformID class can only be CPE spec. So, the SpecificationID can
be restricted to some values only for each class, which if added will help
clarify what standard/spec (CEE, CPE, etc) applies to each class introduced.
The restriction can be stated in the restriction attribute of parent class
of the introduced extended class.

2) Would MAEC and CCE be worth to be included in the extension?

3) How do the extended classes incorporate XCCDF's  <xccdf:Benchmark>
element and CCE? What class would be suitable for these? Is it Remediation?
It doesn't seem one of the proposed classes conceptually covers
configuration or benchmark checks or XCCDF or CCE references.

4) Does OVAL fit in the Remediation class? OVAL provides vulnerability
description and machine state for vuln assessments, I wonder if Remediation
class would be the one suitable to include such info. 

Rgs,
Panos

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Takeshi Takahashi
Sent: Sunday, October 30, 2011 1:29 AM
To: [email-masked]
Subject: [mile] Fw: New Version Notification for
draft-takahashi-mile-sci-02.txt

Hello all,

The new version of our draft is available online.

http://tools.ietf.org/html/draft-takahashi-mile-sci-02

The major change to previous version is its schema.
I would appreciate any comments on this draft.

Thank you.

Take

2011/10/29  <[email-masked]>:
> A new version of I-D, draft-takahashi-mile-sci-02.txt has been
successfully
> submitted by Takeshi Takahashi and posted to the IETF repository.
>
> Filename:        draft-takahashi-mile-sci
> Revision:        02
> Title:           IODEF-extension to support structured cybersecurity
information
> Creation date:   2011-10-29
> WG ID:           Individual Submission
> Number of pages: 26
>
> Abstract:
>   This document extends the Incident Object Description Exchange Format
>   (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched
>   cybersecurity information exchange among cybersecurity entities by
>   embedding structured information formatted by specifications,
>   including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], CVE(R)
>   [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] [CWSS], ISO/
>   IEC 19770-2 [ISOIEC19770-2], OCIL [OCIL], OVAL(R) [OVAL], XCCDF
>   [XCCDF], and XDAS [XDAS].
>
>
>
>
> The IETF Secretariat
>

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

---

From: <[email-masked]>
Date: Wed, 9 Nov 2011 12:35:45 -0500

Panos,

Thank you for the review.  Do others have opinions on the questions raised?

Take,

I would also like to see MAEC in the proposal.  Is there a reason why it was not included?

Thank you,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Panos Kampanakis
Sent: Tuesday, November 08, 2011 6:34 PM
To: 'Takeshi Takahashi'; [email-masked]
Subject: Re: [mile] Fw: New Version Notification for draft-takahashi-mile-sci-02.txt

Hi Take,

Rgs,
Panos

-----Original Message-----

Hello all,

Thank you.

Take

successfully
information

---

From: Chris Inacio <[email-masked]>
Date: Sun, 13 Nov 2011 01:37:19 -0500

> class would be the one suitable to include such info. 

No OVAL is not a remediation standard.  There is other work happening within SCAP that is remediation focused.  CRE (Common Remediation Enumeration) will likely be the first one out of the gate.  It will reference back to OVAL as the check for remediating (most likely via some other configuration setting - on the affected device, or some other appropriate device) to ensure that a vulnerability has been remediated.

> Panos
Chris

---

From: "Panos Kampanakis" <[email-masked]>
Date: Sun, 13 Nov 2011 18:06:13 -0500

Agreed.

The IODEF extension draft has an example where OVAL is under the newly
introduced class called Remediation. 

    <AdditionalData dtype="xml">
      <iodef-sci:Remediation SpecificationID="OVAL_5.10">
        <iodef-sci:Record>[OVAL-formatted data]</iodef-sci:Record>
      </iodef-sci:Remediation>

And, I was trying to point out that maybe that is not the record where we
would want OVAL to be.

Take will look into it, potentially changing the class name or adapting it.

Panos

-----Original Message-----
From: Chris Inacio [mailto:[email-masked]] 
Sent: Sunday, November 13, 2011 1:37 AM
To: Panos Kampanakis
Cc: Takeshi Takahashi; [email-masked]
Subject: Re: [mile] New Version Notification for

> class would be the one suitable to include such info. 

No OVAL is not a remediation standard.  There is other work happening within
SCAP that is remediation focused.  CRE (Common Remediation Enumeration) will
likely be the first one out of the gate.  It will reference back to OVAL as
the check for remediating (most likely via some other configuration setting
- on the affected device, or some other appropriate device) to ensure that a
vulnerability has been remediated.

Chris

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Mon, 14 Nov 2011 12:27:49 +0900

Hi Chris,

Thank you for your comment.
Yes, I agree. I am thinking to provide verification class and remediation
class separately.
Let me reflect your comment.

I am looking forward to the CRE in the near future.

Sincerely,
Take

-----Original Message-----
From: Chris Inacio [mailto:[email-masked]] 
Sent: Sunday, November 13, 2011 3:37 PM
To: Panos Kampanakis
Cc: Takeshi Takahashi; [email-masked]
Subject: Re: [mile] New Version Notification for

On Nov 8, 2011, at 6:33 PM, Panos Kampanakis wrote:

> 1) Some extended classes apply only to some Specifications. For 
> example, a Vulnerability class can be OVAL, CVRF spec but not CEE or 
> OCIL. In the same manner an Event Report class cannot have a 
> SpecificationID of CAPEC_1.6 or OVAL. A PlatformID class can only be 
> CPE spec. So, the SpecificationID can be restricted to some values 
> only for each class, which if added will help clarify what standard/spec
(CEE, CPE, etc) applies to each class introduced.
> The restriction can be stated in the restriction attribute of parent 
> class of the introduced extended class.
> 
> description and machine state for vuln assessments, I wonder if 
> Remediation class would be the one suitable to include such info.
> 

Chris

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Takeshi Takahashi