Subject: [scap_interest] Summary of first SCAP BOF meeting
From: Steve Hanna <[email-masked]>
To: [email-masked]
Date: Wed, 10 Nov 2010 22:10:39 +0800
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." <scap_interest.ietf.org>

While we're waiting for initial minutes from the SCAP BOF, here's the
summary that I sent to SAAG (Security Area Advisory Group). FYI.

Thanks,

Steve

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

The SCAP BOF met on Tuesday, November 9 from 1520 to 1810. This was
an exploratory BOF devoted to exploring the possible ways in which the
IETF and SCAP communities can work together. After an SCAP Overview
and several presentations that looked at SCAP from several perspectives
(Network Management, NEA, and ITU CYBEX), there was an extensive Q&A
and a discussion of the possibilities for collaboration. The group
agreed to write
up an Internet Draft with collaboration ideas, focusing especially on network
protocols that the SCAP community needs: reporting on SCAP compliance
within a NEA assessment, provisioning XCCDF and OVAL content to an
endpoint, etc. This draft can stimulate more concrete discussions about
whether a WG should be formed.

Date: Mon, 08 Nov 2010 12:01:02 -0500
From: Tony Rutkowski <[email-masked]>
Organization: Yaana Technologies
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: [scap_interest] CYBEX reference documents - PDF versions
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------050305040603050908020906
Content-Type: multipart/alternative;
 boundary="------------010305020509070103080801"

--------------010305020509070103080801
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

For those preferring PDF formats.
--tony

--------------010305020509070103080801
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
  </head>
  <body bgcolor="#ffffff" text="#3333ff">
    <tt><font color="#000000">For those preferring PDF formats.<br>
        --tony<br>
      </font></tt>
  </body>
</html>

--------------010305020509070103080801--

--------------050305040603050908020906
Content-Type: application/pdf;
 name="T09-SG17-101208-TD-PLEN-1165!!MSW-E.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="T09-SG17-101208-TD-PLEN-1165!!MSW-E.pdf"

--------------050305040603050908020906
Content-Type: application/pdf;
 name="T09-SG17-101208-TD-PLEN-1161!!MSW-E.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="T09-SG17-101208-TD-PLEN-1161!!MSW-E.pdf"

--------------050305040603050908020906
Content-Type: application/pdf;
 name="T09-SG17-101208-TD-PLEN-1162!!MSW-E.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="T09-SG17-101208-TD-PLEN-1162!!MSW-E.pdf"

--------------050305040603050908020906
Content-Type: application/pdf;
 name="T09-SG17-101208-TD-PLEN-1163!!MSW-E.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="T09-SG17-101208-TD-PLEN-1163!!MSW-E.pdf"

////////////////////////////////////////////////////////////////////////
--------------050305040603050908020906
Content-Type: application/pdf;
 name="T09-SG17-101208-TD-PLEN-1164!!MSW-E.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="T09-SG17-101208-TD-PLEN-1164!!MSW-E.pdf"

--------------050305040603050908020906--

Date: Mon, 08 Nov 2010 11:41:52 -0500
From: Tony Rutkowski <[email-masked]>
Organization: Yaana Technologies
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: [scap_interest] CYBEX reference documents - deliverables for the ITU-T December meeting
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------090702060705010805020702
Content-Type: multipart/alternative;
 boundary="------------040604000803030809060409"

--------------040604000803030809060409
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Please find attached the initial CYBEX
deliverables for review and requested
adoption at the ITU-T SG17 meeting in four
weeks in Geneva.  Following a rapid global
polling process that includes every ITU
country in the world and their industries,
these will become adopted Recommendations
in April, translated into Arabic, Chinese,
French, Spanish, & Russian languages, and
made available with a persistent URL and
downloadable for free from a trusted EVcert
identified host.  Going forward, the
provisions will be evolved as necessary
to remain current and synced with the
respective user communities.

This ensemble includes the basic CYBEX framework
(X.1500) and two key initial capability
specifications for CVE (X.1520) and CVSS
(X.1521).  Also provided are the report
of the continuing management group for
the effort known as the CYBEX Correspondence
Group, and the roadmap/workplan for 2011-2012.

This is a landmark of sorts, that represents
the considerable effort over the past 18 months
and combined vision by a great many people
from around the globe - especially the
specification source communities.  Some are
at the Beijing scap_interest BOF.

The IETF activity for security tool automation
implementations is one of many such initiatives
now occurring in diverse standards bodies.  We
all gain by our constant collaboration in these
efforts, and look forward to doing so as the
IETF moves forward, and will do everything possible
to share our work and provide involvement.  The
ITU's recent action to provide low-cost membership
to academic institutions will also be helpful in
promoting openness and direct access.

best regards,
tony  (ITU-T Q.4/17 - Cybersecurity - Rapporteur)

--------------040604000803030809060409
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
  </head>
  <body bgcolor="#ffffff" text="#3333ff">
    <tt><font color="#000000">Dear all,<br>
        <br>
        Please find attached the initial CYBEX <br>
        deliverables for review and requested<br>
        adoption at the ITU-T SG17 meeting in four<br>
        weeks in Geneva.&nbsp; Following a rapid global<br>
        polling process that includes every ITU<br>
        country in the world and their industries,<br>
        these will become adopted Recommendations <br>
        in April, translated into Arabic, Chinese, <br>
        French, Spanish, &amp; Russian languages, and <br>
        made available with a persistent URL and <br>
        downloadable for free from a trusted EVcert <br>
        identified host.&nbsp; Going forward, the <br>
        provisions will be evolved as necessary <br>
        to remain current and synced with the <br>
        respective user communities.<br>
        <br>
        This ensemble includes the basic CYBEX framework <br>
        (X.1500) and two key initial capability <br>
        specifications for CVE (X.1520) and CVSS <br>
        (X.1521).&nbsp; Also provided are the report <br>
        of the continuing management group for <br>
        the effort known as the CYBEX Correspondence <br>
        Group, and the roadmap/workplan for 2011-2012.<br>
        <br>
        This is a landmark of sorts, that represents <br>
        the considerable effort over the past 18 months<br>
        and combined vision by a great many people <br>
        from around the globe - especially the <br>
        specification source communities.&nbsp; Some are<br>
        at the Beijing scap_interest BOF.<br>
        <br>
        The IETF activity for security tool automation<br>
        implementations is one of many such initiatives<br>
        now occurring in diverse standards bodies.&nbsp; We <br>
        all gain by our constant collaboration in these<br>
        efforts, and look forward to doing so as the<br>
        IETF moves forward, and will do everything possible<br>
        to share our work and provide involvement.&nbsp; The<br>
        ITU's recent action to provide low-cost membership<br>
        to academic institutions will also be helpful in<br>
        promoting openness and direct access.<br>
        <br>
        best regards,<br>
        tony</font></tt>&nbsp; (ITU-T Q.4/17 - Cybersecurity - Rapporteur)<br>
    <br>
  </body>
</html>

--------------040604000803030809060409--

--------------090702060705010805020702
Content-Type: application/msword;
 name="T09-SG17-101208-TD-PLEN-1161!!MSW-E.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="T09-SG17-101208-TD-PLEN-1161!!MSW-E.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAATAAAAHQkAAAAA
AAAAEAAAHwkAAAEAAAD+////AAAAAAoJAAALCQAADAkAAA0JAAAOCQAADwkAABAJAAARCQAA
EgkAABMJAAAUCQAAFQkAABYJAAAXCQAAGAkAABkJAAAaCQAAGwkAABwJAAD/////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
--------------090702060705010805020702
Content-Type: application/msword;
 name="T09-SG17-101208-TD-PLEN-1162!!MSW-E.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="T09-SG17-101208-TD-PLEN-1162!!MSW-E.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAMgEAAAAA
AAAAEAAANQEAAAEAAAD+////AAAAAC8BAAAwAQAAMQEAAP//////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
--------------090702060705010805020702
Content-Type: application/msword;
 name="T09-SG17-101208-TD-PLEN-1163!!MSW-E.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="T09-SG17-101208-TD-PLEN-1163!!MSW-E.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAEAAAAyQEAAAAA
AAAAEAAAywEAAAEAAAD+////AAAAAMUBAADGAQAAxwEAAMgBAAD/////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
--------------090702060705010805020702
Content-Type: application/msword;
 name="T09-SG17-101208-TD-PLEN-1164!!MSW-E.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="T09-SG17-101208-TD-PLEN-1164!!MSW-E.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAOgEAAAAA
AAAAEAAAPAEAAAEAAAD+////AAAAADcBAAA4AQAAOQEAAP//////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
--------------090702060705010805020702
Content-Type: application/msword;
 name="T09-SG17-101208-TD-PLEN-1165!!MSW-E.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="T09-SG17-101208-TD-PLEN-1165!!MSW-E.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAjwAAAAAA
AAAAEAAAkgAAAAEAAAD+////AAAAAI0AAACOAAAA////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////

--------------090702060705010805020702--

Date: Mon, 8 Nov 2010 19:20:16 +0800
From: Steve Hanna <[email-masked]>
To: [email-masked]
Subject: Re: [scap_interest] Questions from David Harrington

I'd like to address one of David's questions:

> 4) In the past, IDS work has not been considered IETF work; IDS
> vendors tend to have their own security-related fora for sharing
> information. NEA has been brought into the IETF from the TSG, and the
> IEEE has created the Industry Connections Security Group that focuses
> on standardizing malware definitions.  I personally would love to have
> that community come into the IETF and use the IETF process for
> **developing** the specifications, not just for approving the
> specifications after they're done. Is the industry seriously
> interested in participating in the IETF, or will they continue to
> create multiple security fora to develop specifications and then bring
> their specifications to the IETF for approval as RFCs?

First, TCG and the SCAP community have not developed IDS standards.
IDS isn't really relevant to this discussion. But I think David's raising a
good issue so I'll just assume that David means security standards.
If that's not what David meant, please let me know. But I think his
point is valid with that substitution so I'll address it in that way.

Second, I'll speak to the case of NEA since I know all about that.
The TCG TNC community HAS come into the IETF and used the
IETF process to develop the NEA specifications, along with lots
of people who are not part of TCG. Yes, we had done some work
before we came to IETF. We brought our specifications to IETF and
offered them as initial drafts, giving change control over to the IETF.
If you compare those initial drafts to the RFCs that came out of the
IETF process, you'll see that lots of valuable changes and substantial
improvements were made to the specifications over the last few years.

David asks if the security community (I assume) will continue to develop
specifications in other fora and then bring those specifications to the IETF.
I certainly hope so! Many of the best and most successful security RFCs
started out in other fora: SSL/TLS, X.509, Kerberos, ssh, etc. David may
not like this approach but it has been demonstrably quite successful in
the security area and, I think, in other areas. Nobody should expect the
IETF process to be a rubber stamp. It's not. But that doesn't mean that
we should reject things that started out elsewhere and now want to come
into the IETF to get broader participation and review. In fact, we should
encourage that! Solutions developed by the IETF from scratch often
turn into endless academic exercises divorced from reality. At least,
I have seen that happen all too often.

Thanks,

Steve

From: "Waltermire, David" <[email-masked]>
To: Stephen Hanna <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 8 Nov 2010 05:23:40 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [scap_interest] Questions from David Harrington (Question 2)

Regarding question 2:

> 2) Will the the NVD be made available for use with the international
> standard, by the whole IETF community? What requirements must be met
> to be allowed to access the NVD database?

The NVD is already available for use by the international community.  The security reference data contained within the NVD (data feeds based on CVE, CCE, CPE) is freely available to anyone that visits the site.  The NVD supports language bundles for internationalization and contains some language translations contributed by the international community.  When applicable, we are committed to enhancing the NVD to support standards developed within the IETF.

Sincerely,
David Waltermire
NIST 

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Stephen Hanna [[email-masked]]
Sent: Friday, November 05, 2010 12:45 AM
To: [email-masked]
Subject: [scap_interest] Questions from David Harrington

David Harrington sent me some questions about SCAP and the SCAP BOF
recently. These questions (included below) are thought-provoking.
They should get some good discussions going on this list.

Since I'm not an SCAP expert, I don't have answers to all of these
myself. I have asked some SCAP experts to answer them. Please use
a separate thread for each question so that people can follow the
discussions more easily.

Thanks,

Steve Hanna

-----------

To help the BOF organizers, I have some basic questions I would like
to have answered during the BOF (and on the mailing list)

1) NIST is a national standardization organization. Is NIST/Mitre/DHS
willing to give change control
to IETF to develop this into an international standard?

2) Will the the NVD be made available for use with the international
standard, by the whole IETF community? What requirements must be met
to be allowed to access the NVD database?

3) various proposals to standardize IDS-related technologies have
failed in IETF, mostly
because the industry players seem not very interested in standards.
Major players use their vulnerability and signature libraries as
value-add features. They seem to develop proprietary protocols to suit
their specific applications. Why will this be different?

4) In the past, IDS work has not been considered IETF work; IDS
vendors tend to have their own security-related fora for sharing
information. NEA has been brought into the IETF from the TSG, and the
IEEE has created the Industry Connections Security Group that focuses
on standardizing malware definitions.  I personally would love to have
that community come into the IETF and use the IETF process for
**developing** the specifications, not just for approving the
specifications after they're done. Is the industry seriously
interested in participating in the IETF, or will they continue to
create multiple security fora to develop specifications and then bring
their specifications to the IETF for approval as RFCs?

5) The web page says "leaders in the SCAP community (including NIST,
NSA, MITRE, and commercial vendors) have decided to explore taking the
most stable and successful SCAP specifications to the IETF for
adoption as Standards Track RFCs." Are these leaders expecting the
IETF to rubber-stamp these mature/stable/successful specifications? I
am especially concerned by the explanation that this BOF is to
"explore whether the IETF would be an appropriate venue for such
standardization ***when ready***."  (emphasis mine). We have working
groups explicitly to do the development work, not to accept
specifications when ready.

6) Much of the SCAP standards are agreed-upon definitions, schemas,
etc. These apparently are registered with Mitre. The listshow.net web
page discusses this: "Formats for the existing enumerations such as
CVE and CCE are good candidates as well. Note we are only talking
about the actual enumeration formats, not the operational
uses/administration of the enumerations. That would remain outside the
IETF, as it is today."
Does this mean IANA would not administer the relevant registries for
these IETF standards? If not, how would the registrations be
administered, and who controls them? What are the requirements
(comparable to RFC5226)?

7) the web site says "We will continue to use this [open contribution]
model for the development of new SCAP specifications and
capabilities." Does this mean the SCAP community will work outside the
WG to continue development of SCAP proposals? The IETF has rules it
follows about things like downrefs, backwards compatibility,
interoperability requirements, etc. What happens if SCAP-developed
specifications do not interoperate properly with IETF standards
developed by the SCAP WG, because SCAP decides to use different rules?

8) I have concerns this appears to be a request to rubber-stamp a
national standard to make it an international standard. So if the IETF
rubber-stamps this work from NIST, will the IETF also rubber-stamp
work by CCSA? and comparable national standards organizations for UK,
France, Germany, Italy, Spain, Korea, Japan, Canada, and ... ?

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

From: "Waltermire, David" <[email-masked]>
To: Stephen Hanna <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 8 Nov 2010 05:01:47 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [scap_interest] Questions from David Harrington

Regarding question 1:

> 1) NIST is a national standardization organization. Is NIST/Mitre/DHS
> willing to give change control
> to IETF to develop this into an international standard?

If a specification is accepted by an IETF working group to be worked through the IETF process, NIST will give change control to the IETF.  We are committed to collaborate within the IETF community to resolve any challenges with the existing specifications and to enhance and extend the supported use cases.

Sincerely,
Dave Waltermire
NIST
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Stephen Hanna [[email-masked]]
Sent: Friday, November 05, 2010 12:45 AM
To: [email-masked]
Subject: [scap_interest] Questions from David Harrington

David Harrington sent me some questions about SCAP and the SCAP BOF
recently. These questions (included below) are thought-provoking.
They should get some good discussions going on this list.

Since I'm not an SCAP expert, I don't have answers to all of these
myself. I have asked some SCAP experts to answer them. Please use
a separate thread for each question so that people can follow the
discussions more easily.

Thanks,

Steve Hanna

-----------

To help the BOF organizers, I have some basic questions I would like
to have answered during the BOF (and on the mailing list)

1) NIST is a national standardization organization. Is NIST/Mitre/DHS
willing to give change control
to IETF to develop this into an international standard?

2) Will the the NVD be made available for use with the international
standard, by the whole IETF community? What requirements must be met
to be allowed to access the NVD database?

3) various proposals to standardize IDS-related technologies have
failed in IETF, mostly
because the industry players seem not very interested in standards.
Major players use their vulnerability and signature libraries as
value-add features. They seem to develop proprietary protocols to suit
their specific applications. Why will this be different?

4) In the past, IDS work has not been considered IETF work; IDS
vendors tend to have their own security-related fora for sharing
information. NEA has been brought into the IETF from the TSG, and the
IEEE has created the Industry Connections Security Group that focuses
on standardizing malware definitions.  I personally would love to have
that community come into the IETF and use the IETF process for
**developing** the specifications, not just for approving the
specifications after they're done. Is the industry seriously
interested in participating in the IETF, or will they continue to
create multiple security fora to develop specifications and then bring
their specifications to the IETF for approval as RFCs?

5) The web page says "leaders in the SCAP community (including NIST,
NSA, MITRE, and commercial vendors) have decided to explore taking the
most stable and successful SCAP specifications to the IETF for
adoption as Standards Track RFCs." Are these leaders expecting the
IETF to rubber-stamp these mature/stable/successful specifications? I
am especially concerned by the explanation that this BOF is to
"explore whether the IETF would be an appropriate venue for such
standardization ***when ready***."  (emphasis mine). We have working
groups explicitly to do the development work, not to accept
specifications when ready.

6) Much of the SCAP standards are agreed-upon definitions, schemas,
etc. These apparently are registered with Mitre. The listshow.net web
page discusses this: "Formats for the existing enumerations such as
CVE and CCE are good candidates as well. Note we are only talking
about the actual enumeration formats, not the operational
uses/administration of the enumerations. That would remain outside the
IETF, as it is today."
Does this mean IANA would not administer the relevant registries for
these IETF standards? If not, how would the registrations be
administered, and who controls them? What are the requirements
(comparable to RFC5226)?

7) the web site says "We will continue to use this [open contribution]
model for the development of new SCAP specifications and
capabilities." Does this mean the SCAP community will work outside the
WG to continue development of SCAP proposals? The IETF has rules it
follows about things like downrefs, backwards compatibility,
interoperability requirements, etc. What happens if SCAP-developed
specifications do not interoperate properly with IETF standards
developed by the SCAP WG, because SCAP decides to use different rules?

8) I have concerns this appears to be a request to rubber-stamp a
national standard to make it an international standard. So if the IETF
rubber-stamps this work from NIST, will the IETF also rubber-stamp
work by CCSA? and comparable national standards organizations for UK,
France, Germany, Italy, Spain, Korea, Japan, Canada, and ... ?

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

Date: Mon, 08 Nov 2010 09:17:11 +0800
From: Sean Turner <[email-masked]>
To: [email-masked]
Subject: [scap_interest] Remote Participation

In case your not at the IETF meeting you can still participate.  You can 
listen to the audio stream here:

http://videolab.uoregon.edu/events/ietf/ietf795.m3u

You can also join the discussion via jabber:

[email-masked]

spt

From: "Natale, Bob" <[email-masked]>
To: Stephen Hanna <[email-masked]>
Date: Fri, 5 Nov 2010 02:20:51 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Questions from David Harrington

Hi,

I don't speak at any level for MITRE, NSA, NIST, or anyone else other than =
myself, but I'd like to provide some preliminary feedback to David's concer=
ns ... hopefully, more authoritative individuals will speak up on behalf of=
 the organizations cited in David's questions.

- My understanding is that you should think of the existing SCAP work as "r=
ough consensus and running code".
- Many of the SCAP components are publicly available via nist.gov and MITRE=
's "making security measurable" site (http://msm.mitre.org).
- There is a lot more vendor support for some of the constituent SCAP stand=
ards in major COTS products than might be apparent w/o some investigation.
- The IETF should feel free to extend or refine existing SCAP standards and=
 public implementations as it deems best for the Internet community.  Ideal=
ly, however, we'd seek a highly collaborative approach between Internet, us=
er community, and industry on this particular front.
- MITRE is a federally funded R&D center (FFRDC) working in the public inte=
rest as a trusted advisor to its sponsors, and as an FFRDC is "prohibited f=
rom manufacturing products, competing with industry, or working for [e.g., =
representing]  commercial companies,".

Cheers,
BobN

-----Original Message-----
From: [email-masked] [mailto:[email-masked]=
] On Behalf Of Stephen Hanna
Sent: Friday, November 05, 2010 12:45 AM
To: [email-masked]
Subject: [scap_interest] Questions from David Harrington

David Harrington sent me some questions about SCAP and the SCAP BOF
recently. These questions (included below) are thought-provoking.
They should get some good discussions going on this list.

Since I'm not an SCAP expert, I don't have answers to all of these
myself. I have asked some SCAP experts to answer them. Please use
a separate thread for each question so that people can follow the
discussions more easily.

Thanks,

Steve Hanna

-----------

To help the BOF organizers, I have some basic questions I would like
to have answered during the BOF (and on the mailing list)

1) NIST is a national standardization organization. Is NIST/Mitre/DHS
willing to give change control
to IETF to develop this into an international standard?=20

2) Will the the NVD be made available for use with the international
standard, by the whole IETF community? What requirements must be met
to be allowed to access the NVD database?

3) various proposals to standardize IDS-related technologies have
failed in IETF, mostly
because the industry players seem not very interested in standards.
Major players use their vulnerability and signature libraries as
value-add features. They seem to develop proprietary protocols to suit
their specific applications. Why will this be different?

4) In the past, IDS work has not been considered IETF work; IDS
vendors tend to have their own security-related fora for sharing
information. NEA has been brought into the IETF from the TSG, and the
IEEE has created the Industry Connections Security Group that focuses
on standardizing malware definitions.  I personally would love to have
that community come into the IETF and use the IETF process for
**developing** the specifications, not just for approving the
specifications after they're done. Is the industry seriously
interested in participating in the IETF, or will they continue to
create multiple security fora to develop specifications and then bring
their specifications to the IETF for approval as RFCs?

5) The web page says "leaders in the SCAP community (including NIST,
NSA, MITRE, and commercial vendors) have decided to explore taking the
most stable and successful SCAP specifications to the IETF for
adoption as Standards Track RFCs." Are these leaders expecting the
IETF to rubber-stamp these mature/stable/successful specifications? I
am especially concerned by the explanation that this BOF is to
"explore whether the IETF would be an appropriate venue for such
standardization ***when ready***."  (emphasis mine). We have working
groups explicitly to do the development work, not to accept
specifications when ready.

6) Much of the SCAP standards are agreed-upon definitions, schemas,
etc. These apparently are registered with Mitre. The listshow.net web
page discusses this: "Formats for the existing enumerations such as
CVE and CCE are good candidates as well. Note we are only talking
about the actual enumeration formats, not the operational
uses/administration of the enumerations. That would remain outside the
IETF, as it is today."
Does this mean IANA would not administer the relevant registries for
these IETF standards? If not, how would the registrations be
administered, and who controls them? What are the requirements
(comparable to RFC5226)?

7) the web site says "We will continue to use this [open contribution]
model for the development of new SCAP specifications and
capabilities." Does this mean the SCAP community will work outside the
WG to continue development of SCAP proposals? The IETF has rules it
follows about things like downrefs, backwards compatibility,
interoperability requirements, etc. What happens if SCAP-developed
specifications do not interoperate properly with IETF standards
developed by the SCAP WG, because SCAP decides to use different rules?

8) I have concerns this appears to be a request to rubber-stamp a
national standard to make it an international standard. So if the IETF
rubber-stamps this work from NIST, will the IETF also rubber-stamp
work by CCSA? and comparable national standards organizations for UK,
France, Germany, Italy, Spain, Korea, Japan, Canada, and ... ?

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

From: Stephen Hanna <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 5 Nov 2010 00:45:26 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [scap_interest] Questions from David Harrington

David Harrington sent me some questions about SCAP and the SCAP BOF
recently. These questions (included below) are thought-provoking.
They should get some good discussions going on this list.

Since I'm not an SCAP expert, I don't have answers to all of these
myself. I have asked some SCAP experts to answer them. Please use
a separate thread for each question so that people can follow the
discussions more easily.

Thanks,

Steve Hanna

-----------

To help the BOF organizers, I have some basic questions I would like
to have answered during the BOF (and on the mailing list)

1) NIST is a national standardization organization. Is NIST/Mitre/DHS
willing to give change control
to IETF to develop this into an international standard?=20

2) Will the the NVD be made available for use with the international
standard, by the whole IETF community? What requirements must be met
to be allowed to access the NVD database?

3) various proposals to standardize IDS-related technologies have
failed in IETF, mostly
because the industry players seem not very interested in standards.
Major players use their vulnerability and signature libraries as
value-add features. They seem to develop proprietary protocols to suit
their specific applications. Why will this be different?

4) In the past, IDS work has not been considered IETF work; IDS
vendors tend to have their own security-related fora for sharing
information. NEA has been brought into the IETF from the TSG, and the
IEEE has created the Industry Connections Security Group that focuses
on standardizing malware definitions.  I personally would love to have
that community come into the IETF and use the IETF process for
**developing** the specifications, not just for approving the
specifications after they're done. Is the industry seriously
interested in participating in the IETF, or will they continue to
create multiple security fora to develop specifications and then bring
their specifications to the IETF for approval as RFCs?

5) The web page says "leaders in the SCAP community (including NIST,
NSA, MITRE, and commercial vendors) have decided to explore taking the
most stable and successful SCAP specifications to the IETF for
adoption as Standards Track RFCs." Are these leaders expecting the
IETF to rubber-stamp these mature/stable/successful specifications? I
am especially concerned by the explanation that this BOF is to
"explore whether the IETF would be an appropriate venue for such
standardization ***when ready***."  (emphasis mine). We have working
groups explicitly to do the development work, not to accept
specifications when ready.

6) Much of the SCAP standards are agreed-upon definitions, schemas,
etc. These apparently are registered with Mitre. The listshow.net web
page discusses this: "Formats for the existing enumerations such as
CVE and CCE are good candidates as well. Note we are only talking
about the actual enumeration formats, not the operational
uses/administration of the enumerations. That would remain outside the
IETF, as it is today."
Does this mean IANA would not administer the relevant registries for
these IETF standards? If not, how would the registrations be
administered, and who controls them? What are the requirements
(comparable to RFC5226)?

7) the web site says "We will continue to use this [open contribution]
model for the development of new SCAP specifications and
capabilities." Does this mean the SCAP community will work outside the
WG to continue development of SCAP proposals? The IETF has rules it
follows about things like downrefs, backwards compatibility,
interoperability requirements, etc. What happens if SCAP-developed
specifications do not interoperate properly with IETF standards
developed by the SCAP WG, because SCAP decides to use different rules?

8) I have concerns this appears to be a request to rubber-stamp a
national standard to make it an international standard. So if the IETF
rubber-stamps this work from NIST, will the IETF also rubber-stamp
work by CCSA? and comparable national standards organizations for UK,
France, Germany, Italy, Spain, Korea, Japan, Canada, and ... ?