Subject: Re: [scap_interest] SCE XCCDF
From: "Chernin, Michael A." <[email-masked]>
To: "[email-masked]" <[email-masked]>, David Solin <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 24 Feb 2012 17:54:37 +0000
List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." <scap_interest.ietf.org>

As a standards content consumer, I would prefer we implement whatever needs to be improved within the OVAL language. As to what needs to be improved, we should probably compile a list and discuss it.

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust & Clearing Corporation
O: 813-470-2173

> -----Original Message-----
> From: [email-masked] [mailto:scap_interest-
> [email-masked]] On Behalf Of Chandrashekhar B
> Sent: Friday, February 24, 2012 12:14 PM
> To: David Solin; [email-masked]; [email-masked]
> Subject: Re: [scap_interest] SCE XCCDF
> 
> This is an alternative option to cases where OVAL cannot be used to as a
> checking language. But there will always be confusion when to use what as
> the capabilities of OVAL improve. There is certainly one use case, to develop
> remote checks to determine vulnerabilities, assuming OVAL is not meant for
> that. Any effort to standardize this interface is good.
> 
> Thanks,
> Chandra.
> Sent from BlackBerry(r) on Airtel
> 
> -----Original Message-----
> From: David Solin <[email-masked]>
> Sender: [email-masked]
> Date: Fri, 24 Feb 2012 09:54:33
> To: <[email-masked]>
> Subject: Re: [scap_interest] SCE XCCDF
> 
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest
> 
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest
<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>

Sensitivity: Normal
Importance: Normal
To: "David Solin" <[email-masked]>, [email-masked], [email-masked]
From: "Chandrashekhar B" <[email-masked]>
Date: Fri, 24 Feb 2012 17:14:19 +0000
Subject: Re: [scap_interest] SCE XCCDF
Reply-To: [email-masked]

Sender: David Solin <[email-masked]>
Date: Fri, 24 Feb 2012 09:54:33 -0600
From: David Solin <[email-masked]>
Organization: jOVAL
To: [email-masked]
Subject: Re: [scap_interest] SCE XCCDF

This is a multi-part message in MIME format.
--------------050409050609040008060300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks for forwarding this Luis, it's very interesting!

We're planning on bundling an XCCDF interpreter with the next release of 
jOVAL, and this would be a great capability to add to that support.  To 
that end, I've reached out to Peter Vrabec to discuss the reporting 
format, and adding variable exports to the "specification" (which seems 
like it would be very easy to do).

Regards,
--David Solin

-- 

jOVAL.org: OVAL implemented in Java.
/Scan any machine from any machine. For free!/
Learn More <http://www.joval.org> | Features 
<http://www.joval.org/features/> | Download 
<http://www.joval.org/download/>

On 2/24/2012 8:57 AM, Luis Nunez wrote:
> Link is some interesting and innovated work coming out of the open-scap.org project.  New release includes Script Check Engine (SCE) for XCCDF.
>
> http://pvrabec.livejournal.com/887.html
>
> -ln
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest

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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Thanks for forwarding this Luis, it's very interesting!<br>
    <br>
    We're planning on bundling an XCCDF interpreter with the next
    release of jOVAL, and this would be a great capability to add to
    that support.&nbsp; To that end, I've reached out to Peter Vrabec to
    discuss the reporting format, and adding variable exports to the
    "specification" (which seems like it would be very easy to do).<br>
    <br>
    Regards,<br>
    --David Solin<br>
    <br>
    <div class="moz-signature">-- <br>
      <p style="color: #333; font: normal 11px/16px 'Droid Sans', Arial,
        sans-serif;"> <span style="font-size:14px;line-height:18px;">jOVAL.org:
          OVAL implemented in Java.</span><br>
        <i style="font-size:12px">Scan any machine from any machine. For
          free!</i><br>
        <a style="color:#360;" href="http://www.joval.org">Learn More</a>
        | <a style="color:#360;" href="http://www.joval.org/features/">Features</a>
        | <a style="color:#360;" href="http://www.joval.org/download/">Download</a>
      </p>
    </div>
    <br>
    <br>
    On 2/24/2012 8:57 AM, Luis Nunez wrote:
    <blockquote
      cite="mid:[email-masked]"
      type="cite">
      <pre wrap="">Link is some interesting and innovated work coming out of the open-scap.org project.  New release includes Script Check Engine (SCE) for XCCDF.

<a class="moz-txt-link-freetext" href="http://pvrabec.livejournal.com/887.html">http://pvrabec.livejournal.com/887.html</a>

-ln
_______________________________________________
scap_interest mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a>
</pre>
    </blockquote>
    <br>
    <br>
  </body>
</html>

--------------050409050609040008060300--

From: Luis Nunez <[email-masked]>
Date: Fri, 24 Feb 2012 09:57:02 -0500
To: [email-masked]
Subject: [scap_interest] SCE XCCDF

Link is some interesting and innovated work coming out of the open-scap.org project.  New release includes Script Check Engine (SCE) for XCCDF.

http://pvrabec.livejournal.com/887.html

-ln

From: <[email-masked]>
To: <[email-masked]>
Date: Thu, 23 Feb 2012 12:37:53 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [scap_interest] RSA Security Automation Status and Planning Meeting

--_000_CB6BC7812D21Dkentlandfieldmcafeecom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,

There is a meeting to discuss SCAP and security automation efforts happening at RSA. The meeting is being held at  nCircle Headquarters. Thanks to Tim Keanini for hosting us. nCircle HQ is located a couple of blocks from the Moscone Center.

               Date: Monday February 27th
               Time: 3:00pm - 4:00 pm Pacific
               Location:
                                nCircle HQ
                               101 Second St,  Suite 400
                               San Francisco, CA 94105
               Instructions:
                              Come up to 4th floor and ring the bell on the door for the
                              receptionist, no need to check in on the first floor other than
                              to say you are going to nCircle.

Hope to see you there.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

--_000_CB6BC7812D21Dkentlandfieldmcafeecom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-family: 'Times New Roman', sans-serif; "><div><div><div><div>All,</div><div><br><span>There is a meeting to discuss SCAP and security automation efforts happening at RSA. The</span><span>&nbsp;meeting is being held at &nbsp;nCircle Headquarters. Thanks to Tim Keanini for hosting us.&nbsp;</span><span>nCircle HQ is located a couple of blocks from the Moscone Center.</span><br><span></span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Date: Monday February 27th</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Time: 3:00pm - 4:00 pm Pacific</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Location:</span><br><span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; nCircle HQ</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;101 Second St, &nbsp;Suite 400</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;San Francisco, CA 94105</span><br><span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Instructions:&nbsp;</span></div><div><span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Come up to 4th floor and ring the bell on the door for the&nbsp;</span></div><div><span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; r</span><span>eceptionist, no need to check in on the first floor&nbsp;</span><span>other than&nbsp;</span></div><div><span>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; to say you are going to nCircle.</span><br></div></div><div><span><br></span></div><div><span>Hope to see you there.</span></div><div><span><br></span></div><div><div><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Kent Landfield</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Director Content Strategy, Architecture and Standards</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>McAfee | An Intel Company</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">5000 Headquarters Dr.</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Plano, Texas 75024</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Direct: +1.972.963.7096&nbsp;</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Mobile: +1.817.637.8026</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Web:&nbsp;</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><a href="http://www.mcafee.com/" style="color: rgb(96, 106, 113) !important; ">www.mcafee.com</a></span></div></div></div></div></body></html>

--_000_CB6BC7812D21Dkentlandfieldmcafeecom_--

Sender: David Solin <[email-masked]>
Date: Tue, 21 Feb 2012 23:28:00 -0600
From: David Solin <[email-masked]>
Organization: jOVAL
To: "Waltermire, David A." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] The Context Concept

This is a multi-part message in MIME format.
--------------060209020000000908020304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Isn't this exactly what CIM is for?  CIM makes it possible to organize 
assets across many dimensions, including customer-defined "service" 
dimensions, that could easily serve as references for targeting 
purposes.  I can imagine mapping services with profiles, or more 
generally, CIM graph queries with profiles.

I've never understood what purpose AI is supposed to serve when CIM has 
been around for much longer, is already fairly well-adopted by CMDB 
vendors, and addresses the asset management problem domain quite well.

Anyway, just my $.02.

Regards,
--David Solin

-- 

jOVAL.org: OVAL implemented in Java.
/Scan any machine from any machine. For free!/
Learn More <http://www.joval.org> | Features 
<http://www.joval.org/features/> | Download 
<http://www.joval.org/download/>

On 2/21/2012 12:46 PM, Waltermire, David A. wrote:
>
> There are a variety of use cases that can benefit from synthesizing 
> asset technical information (e.g., IPs, network address, default 
> gateways, machine accessable asset tags, configurations) with 
> organizational information (e.g., device role, criticality, etc).  For 
> example, if you can generate a network graph of devices and their 
> connections, and combine that with firewall rules and other topology 
> concerns to determine visibility between hosts, you can then perform 
> attack graph analysis to determine at what points a security related 
> change will provide the greatest security benefit.  This can be one 
> method used to prioritize the implementation of various security 
> controls.  As Karen Scarfone pointed out earlier, this is also needed 
> to support host-, network-, and system-oriented metrics starting with 
> things like CVSS and CCSS scores and utilizing the composition of 
> software on hosts and hosts on networks to support roll-up.
>
> This and similar use cases are supported by asset identification, but 
> require greater formalization around asset data management to enable 
> implementation neutral, interoperable approaches.
>
> Sincerely,
>
> David Waltermire
>
> *From:[email-masked] 
> [mailto:[email-masked]] *On Behalf Of *Luis Nunez
> *Sent:* Tuesday, February 21, 2012 1:23 PM
> *To:* Chernin, Michael A.
> *Cc:* [email-masked]
> *Subject:* Re: [scap_interest] The Context Concept
>
> We also need to look at vulnerabilities as it applies an environment. 
>  An inherent vulnerability may have differing levels of exposure 
> depending on what, where and how the node is deployed.
>
> We maybe able to leverage Asset Identification (AI) to correlate what 
> role the node is playing in the environment (endpoint, Server, 
> Inter-networking Device,..) and determine level of exposure.  The 
> level of risk could also be applied depending on where the node is 
> situated.
>
> - Directly connected to internet.
>
> - DMZ controlled
>
> - Internal Network
>
> - Secure enclave
>
> -ln
>
> On Feb 21, 2012, at 9:47 AM, Chernin, Michael A. wrote:
>
>
>
> I agree that when dealing with "threats" that context matters. 
> However, vulnerabilities alone do not imply or guarantee there is an 
> associated threat or risk.
>
> In my perfect world there would be a threat indicator standard that 
> links to a structured threat standard that then could describe the 
> CVEs used. This would allow us to continue doing vulnerability 
> management by exposure (no threat context) or by specific threat 
> (which provides context).
>
> Aharon
>
> DTCC Non-Confidential (White)
> ---------------------------------------------------
> Michael "Aharon" Chernin
> Security Automation Program Manager
> Corporate Information Security -Depository Trust & Clearing Corporation
> O: 813-470-2173
>
> *From:[email-masked] 
> <mailto:[email-masked]>[mailto:[email-masked]]*On 
> Behalf Of*Jerome Athias
> *Sent:*Saturday, February 18, 2012 2:03 PM
> *To:[email-masked] <mailto:[email-masked]>
> *Subject:*[scap_interest] The Context Concept
>
> In a private discussion I had at ToorCon 9, with Matt Miller (skape);
> we came to the conclusion that a key (and unresolved) point of 
> automation is the (automatic) definition of the Context in which you 
> are where dealing with a vulnerability (threat).
> It was also identified (validated?), and introduced by Druid.
> And then, the Druid's work was related (validated?) at FRHACK 01 by 
> Rodrigo Branco (bsdaemon).
>
> /Situation awareness 
> (http://en.wikipedia.org/wiki/Situation_awareness) should be taken 
> into account.//
> /Maybe search for "military situational awareness"./
>
> /My 2 dirhams/
> //JA//
>
>
> _____________________________________________________________
> DTCC DISCLAIMER: This email and any files transmitted with it are 
> confidential and intended solely for the use of the individual or 
> entity to whom they are addressed. If you have received this email in 
> error, please notify us immediately and delete the email and any 
> attachments from your system. The recipient should check this email 
> and any attachments for the presence of viruses. The company accepts 
> no liability for any damage caused by any virus transmitted by this 
> email._______________________________________________
> scap_interest mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/scap_interest
>
>
>
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest

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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Isn't this exactly what CIM is for?&nbsp; CIM makes it possible to
    organize assets across many dimensions, including customer-defined
    "service" dimensions, that could easily serve as references for
    targeting purposes.&nbsp; I can imagine mapping services with profiles,
    or more generally, CIM graph queries with profiles.<br>
    <br>
    I've never understood what purpose AI is supposed to serve when CIM
    has been around for much longer, is already fairly well-adopted by
    CMDB vendors, and addresses the asset management problem domain
    quite well.<br>
    <br>
    Anyway, just my $.02.<br>
    <br>
    Regards,<br>
    --David Solin<br>
    <br>
    <div class="moz-signature">-- <br>
      <p style="color: #333; font: normal 11px/16px 'Droid Sans', Arial,
        sans-serif;"> <span style="font-size:14px;line-height:18px;">jOVAL.org:
          OVAL implemented in Java.</span><br>
        <i style="font-size:12px">Scan any machine from any machine. For
          free!</i><br>
        <a style="color:#360;" href="http://www.joval.org">Learn More</a>
        | <a style="color:#360;" href="http://www.joval.org/features/">Features</a>
        | <a style="color:#360;" href="http://www.joval.org/download/">Download</a>
      </p>
    </div>
    <br>
    <br>
    On 2/21/2012 12:46 PM, Waltermire, David A. wrote:
    <blockquote
cite="mid:[email-masked]"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Word 12 (filtered
        medium)">
      <base href="x-msg://309/">
      <style><!--
/* Font Definitions */
@font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.apple-tab-span
	{mso-style-name:apple-tab-span;}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.apple-converted-space
	{mso-style-name:apple-converted-space;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">There
            are a variety of use cases that can benefit from
            synthesizing asset technical information (e.g., IPs, network
            address, default gateways, machine accessable asset tags,
            configurations) with organizational information (e.g.,
            device role, criticality, etc).&nbsp; For example, if you can
            generate a network graph of devices and their connections,
            and combine that with firewall rules and other topology
            concerns to determine visibility between hosts, you can then
            perform attack graph analysis to determine at what points a
            security related change will provide the greatest security
            benefit.&nbsp; This can be one method used to prioritize the
            implementation of various security controls.&nbsp; As Karen
            Scarfone pointed out earlier, this is also needed to support
            host-, network-, and system-oriented metrics starting with
            things like CVSS and CCSS scores and utilizing the
            composition of software on hosts and hosts on networks to
            support roll-up.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">This
            and similar use cases are supported by asset identification,
            but require greater formalization around asset data
            management to enable implementation neutral, interoperable
            approaches.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div>
          <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Sincerely,</span><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p>
          <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">David
              Waltermire</span><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p>
        </div>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div style="border:none;border-left:solid blue 1.5pt;padding:0in
          0in 0in 4.0pt">
          <div>
            <div style="border:none;border-top:solid #B5C4DF
              1.0pt;padding:3.0pt 0in 0in 0in">
              <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">
                  <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
                  [<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>] <b>On Behalf
                    Of </b>Luis Nunez<br>
                  <b>Sent:</b> Tuesday, February 21, 2012 1:23 PM<br>
                  <b>To:</b> Chernin, Michael A.<br>
                  <b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
                  <b>Subject:</b> Re: [scap_interest] The Context
                  Concept<o:p></o:p></span></p>
            </div>
          </div>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal">We also need to look at vulnerabilities
            as it applies an environment. &nbsp;An inherent vulnerability may
            have differing levels of exposure depending on what, where
            and how the node is deployed.&nbsp;<o:p></o:p></p>
          <div>
            <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          </div>
          <div>
            <p class="MsoNormal">We maybe able to leverage Asset
              Identification (AI) to correlate what role the node is
              playing in the environment (endpoint, Server,
              Inter-networking Device,..) and determine level of
              exposure. &nbsp;The level of risk could also be applied
              depending on where the node is situated.<o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><span class="apple-tab-span">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              </span>- Directly connected to internet.<o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><span class="apple-tab-span">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              </span>- DMZ controlled&nbsp;<o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><span class="apple-tab-span">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              </span>- Internal Network<o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><span class="apple-tab-span">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
              </span>- Secure enclave<o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          </div>
          <div>
            <p class="MsoNormal">-ln<o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
            <div>
              <div>
                <p class="MsoNormal">On Feb 21, 2012, at 9:47 AM,
                  Chernin, Michael A. wrote:<o:p></o:p></p>
              </div>
              <p class="MsoNormal"><br>
                <br>
                <o:p></o:p></p>
              <div>
                <div>
                  <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">I
                      agree that when dealing with &#8220;threats&#8221; that
                      context matters. However, vulnerabilities alone do
                      not imply or guarantee there is an associated
                      threat or risk.</span><span style="color:black"><o:p></o:p></span></p>
                </div>
                <div>
                  <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span
                      style="color:black"><o:p></o:p></span></p>
                </div>
                <div>
                  <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">In
                      my perfect world there would be a threat indicator
                      standard that links to a structured threat
                      standard that then could describe the CVEs used.
                      This would allow us to continue doing
                      vulnerability management by exposure (no threat
                      context) or by specific threat (which provides
                      context).</span><span style="color:black"><o:p></o:p></span></p>
                </div>
                <div>
                  <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span
                      style="color:black"><o:p></o:p></span></p>
                </div>
                <div>
                  <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Aharon</span><span
                      style="color:black"><o:p></o:p></span></p>
                </div>
                <div>
                  <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span
                      style="color:black"><o:p></o:p></span></p>
                </div>
                <div>
                  <div>
                    <p class="MsoNormal"><span
style="font-size:9.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">DTCC
                        Non-Confidential (White)<br>
---------------------------------------------------<br>
                        Michael "Aharon" Chernin<br>
                        Security Automation Program Manager<br>
                        Corporate Information Security -Depository Trust
                        &amp; Clearing Corporation<br>
                        O: 813-470-2173</span><span style="color:black"><o:p></o:p></span></p>
                  </div>
                </div>
                <div>
                  <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span
                      style="color:black"><o:p></o:p></span></p>
                </div>
                <div style="border:none;border-left:solid blue
                  1.5pt;padding:0in 0in 0in
                  4.0pt;border-width:initial;border-color:initial">
                  <div>
                    <div style="border:none;border-top:solid #B5C4DF
                      1.0pt;padding:3.0pt 0in 0in
                      0in;border-width:initial;border-color:initial">
                      <div>
                        <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span
                            class="apple-converted-space"><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">&nbsp;</span></span><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"><a
                              moz-do-not-send="true"
                              href="mailto:[email-masked]">[email-masked]</a><span
                              class="apple-converted-space">&nbsp;</span>[<a
                              moz-do-not-send="true"
                              href="mailto:[email-masked]">mailto:[email-masked]</a>]<span
                              class="apple-converted-space">&nbsp;</span><b>On
                              Behalf Of<span
                                class="apple-converted-space">&nbsp;</span></b>Jerome
                            Athias<br>
                            <b>Sent:</b><span
                              class="apple-converted-space">&nbsp;</span>Saturday,
                            February 18, 2012 2:03 PM<br>
                            <b>To:</b><span
                              class="apple-converted-space">&nbsp;</span><a
                              moz-do-not-send="true"
                              href="mailto:[email-masked]">[email-masked]</a><br>
                            <b>Subject:</b><span
                              class="apple-converted-space">&nbsp;</span>[scap_interest]
                            The Context Concept</span><span
                            style="color:black"><o:p></o:p></span></p>
                      </div>
                    </div>
                  </div>
                  <div>
                    <p class="MsoNormal"><span style="color:black">&nbsp;<o:p></o:p></span></p>
                  </div>
                  <p class="MsoNormal" style="margin-bottom:12.0pt"><span
                      style="color:black">In a private discussion I had
                      at ToorCon 9, with Matt Miller (skape);<br>
                      we came to the conclusion that a key (and
                      unresolved) point of automation is the (automatic)
                      definition of the Context in which you are where
                      dealing with a vulnerability (threat).<br>
                      It was also identified (validated?), and
                      introduced by Druid.<br>
                      And then, the Druid's work was related
                      (validated?) at FRHACK 01 by Rodrigo Branco
                      (bsdaemon).<br>
                      <br>
                      <em>Situation awareness (<a moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/Situation_awareness">http://en.wikipedia.org/wiki/Situation_awareness</a>)
                        should be taken into account.</em><i><br>
                        <em>Maybe search for "military situational
                          awareness".</em><br>
                        <br>
                        <em>My 2 dirhams</em><br>
                        <em>/JA</em></i><o:p></o:p></span></p>
                </div>
                <p class="MsoNormal"><span
style="font-size:13.5pt;font-family:&quot;Helvetica&quot;,&quot;sans-serif&quot;"><br>
_____________________________________________________________<span
                      class="apple-converted-space">&nbsp;</span></span><span
style="font-size:10.0pt;font-family:&quot;Helvetica&quot;,&quot;sans-serif&quot;"><br>
                    DTCC DISCLAIMER: This email and any files
                    transmitted with it are confidential and intended
                    solely for the use of the individual or entity to
                    whom they are addressed. If you have received this
                    email in error, please notify us immediately and
                    delete the email and any attachments from your
                    system. The recipient should check this email and
                    any attachments for the presence of viruses. The
                    company accepts no liability for any damage caused
                    by any virus transmitted by this email.</span><span
style="font-size:13.5pt;font-family:&quot;Helvetica&quot;,&quot;sans-serif&quot;">_______________________________________________<br>
                    scap_interest mailing list<br>
                    <a moz-do-not-send="true"
                      href="mailto:[email-masked]">[email-masked]</a><br>
                    <a moz-do-not-send="true"
                      href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a><o:p></o:p></span></p>
              </div>
            </div>
            <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
scap_interest mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------060209020000000908020304--

From: Adam Montville <[email-masked]>
To: "Waltermire, David A." <[email-masked]>, Luis Nunez <[email-masked]>, "Chernin, Michael A." <[email-masked]>
Date: Tue, 21 Feb 2012 18:53:22 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] The Context Concept

Perhaps we should discuss what "risk" means in the grand scheme of things.  Measuring a level of risk based on location is just one way to do it.  I'm not sure where to start that discussion, but we should be thinking in terms of enabling risk-immature and risk-mature organizations to benefit equally by providing a blend of qualitative and quantitative techniques over a spectrum of risk management capabilities.

Adam

From: "Waltermire, David A." <[email-masked]<mailto:[email-masked]>>
Date: Tue, 21 Feb 2012 13:46:06 -0500
To: Luis Nunez <[email-masked]<mailto:[email-masked]>>, "Chernin, Michael A." <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] The Context Concept

There are a variety of use cases that can benefit from synthesizing asset technical information (e.g., IPs, network address, default gateways, machine accessable asset tags, configurations) with organizational information (e.g., device role, criticality, etc).  For example, if you can generate a network graph of devices and their connections, and combine that with firewall rules and other topology concerns to determine visibility between hosts, you can then perform attack graph analysis to determine at what points a security related change will provide the greatest security benefit.  This can be one method used to prioritize the implementation of various security controls.  As Karen Scarfone pointed out earlier, this is also needed to support host-, network-, and system-oriented metrics starting with things like CVSS and CCSS scores and utilizing the composition of software on hosts and hosts on networks to support roll-up.

This and similar use cases are supported by asset identification, but require greater formalization around asset data management to enable implementation neutral, interoperable approaches.

Sincerely,
David Waltermire

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Luis Nunez
Sent: Tuesday, February 21, 2012 1:23 PM
To: Chernin, Michael A.
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [scap_interest] The Context Concept

We also need to look at vulnerabilities as it applies an environment.  An inherent vulnerability may have differing levels of exposure depending on what, where and how the node is deployed.

We maybe able to leverage Asset Identification (AI) to correlate what role the node is playing in the environment (endpoint, Server, Inter-networking Device,..) and determine level of exposure.  The level of risk could also be applied depending on where the node is situated.
          - Directly connected to internet.
          - DMZ controlled
          - Internal Network
          - Secure enclave

-ln

On Feb 21, 2012, at 9:47 AM, Chernin, Michael A. wrote:

I agree that when dealing with �threats� that context matters. However, vulnerabilities alone do not imply or guarantee there is an associated threat or risk.

In my perfect world there would be a threat indicator standard that links to a structured threat standard that then could describe the CVEs used. This would allow us to continue doing vulnerability management by exposure (no threat context) or by specific threat (which provides context).

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust & Clearing Corporation
O: 813-470-2173

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jerome Athias
Sent: Saturday, February 18, 2012 2:03 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [scap_interest] The Context Concept

In a private discussion I had at ToorCon 9, with Matt Miller (skape);
we came to the conclusion that a key (and unresolved) point of automation is the (automatic) definition of the Context in which you are where dealing with a vulnerability (threat).
It was also identified (validated?), and introduced by Druid.
And then, the Druid's work was related (validated?) at FRHACK 01 by Rodrigo Branco (bsdaemon).

Situation awareness (http://en.wikipedia.org/wiki/Situation_awareness) should be taken into account.
Maybe search for "military situational awareness".

My 2 dirhams
/JA

_____________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email._______________________________________________
scap_interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scap_interest

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

From: "Waltermire, David A." <[email-masked]>
To: Luis Nunez <[email-masked]>, "Chernin, Michael A." <[email-masked]>
Date: Tue, 21 Feb 2012 13:46:06 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] The Context Concept

--_000_D7A0423E5E193F40BE6E94126930C4930B93F67E0AMBCLUSTERxcha_
Content-Type: text/plain; charset="us-ascii"

There are a variety of use cases that can benefit from synthesizing asset technical information (e.g., IPs, network address, default gateways, machine accessable asset tags, configurations) with organizational information (e.g., device role, criticality, etc).  For example, if you can generate a network graph of devices and their connections, and combine that with firewall rules and other topology concerns to determine visibility between hosts, you can then perform attack graph analysis to determine at what points a security related change will provide the greatest security benefit.  This can be one method used to prioritize the implementation of various security controls.  As Karen Scarfone pointed out earlier, this is also needed to support host-, network-, and system-oriented metrics starting with things like CVSS and CCSS scores and utilizing the composition of software on hosts and hosts on networks to support roll-up.

This and similar use cases are supported by asset identification, but require greater formalization around asset data management to enable implementation neutral, interoperable approaches.

Sincerely,
David Waltermire

From: [email-masked] [mailto:[email-masked]] On Behalf Of Luis Nunez
Sent: Tuesday, February 21, 2012 1:23 PM
To: Chernin, Michael A.
Cc: [email-masked]
Subject: Re: [scap_interest] The Context Concept

We also need to look at vulnerabilities as it applies an environment.  An inherent vulnerability may have differing levels of exposure depending on what, where and how the node is deployed.

We maybe able to leverage Asset Identification (AI) to correlate what role the node is playing in the environment (endpoint, Server, Inter-networking Device,..) and determine level of exposure.  The level of risk could also be applied depending on where the node is situated.
          - Directly connected to internet.
          - DMZ controlled
          - Internal Network
          - Secure enclave

-ln

On Feb 21, 2012, at 9:47 AM, Chernin, Michael A. wrote:

I agree that when dealing with "threats" that context matters. However, vulnerabilities alone do not imply or guarantee there is an associated threat or risk.

In my perfect world there would be a threat indicator standard that links to a structured threat standard that then could describe the CVEs used. This would allow us to continue doing vulnerability management by exposure (no threat context) or by specific threat (which provides context).

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust & Clearing Corporation
O: 813-470-2173

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jerome Athias
Sent: Saturday, February 18, 2012 2:03 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [scap_interest] The Context Concept

In a private discussion I had at ToorCon 9, with Matt Miller (skape);
we came to the conclusion that a key (and unresolved) point of automation is the (automatic) definition of the Context in which you are where dealing with a vulnerability (threat).
It was also identified (validated?), and introduced by Druid.
And then, the Druid's work was related (validated?) at FRHACK 01 by Rodrigo Branco (bsdaemon).

Situation awareness (http://en.wikipedia.org/wiki/Situation_awareness) should be taken into account.
Maybe search for "military situational awareness".

My 2 dirhams
/JA

_____________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email._______________________________________________
scap_interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scap_interest

--_000_D7A0423E5E193F40BE6E94126930C4930B93F67E0AMBCLUSTERxcha_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: base64

--_000_D7A0423E5E193F40BE6E94126930C4930B93F67E0AMBCLUSTERxcha_--

From: Luis Nunez <[email-masked]>
Date: Tue, 21 Feb 2012 13:23:23 -0500
To: "Chernin, Michael A." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] The Context Concept

--Apple-Mail=_ACF3B984-10B7-4242-84C6-1A5A14CEA285
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

We also need to look at vulnerabilities as it applies an environment.  An inherent vulnerability may have differing levels of exposure depending on what, where and how the node is deployed. 

We maybe able to leverage Asset Identification (AI) to correlate what role the node is playing in the environment (endpoint, Server, Inter-networking Device,..) and determine level of exposure.  The level of risk could also be applied depending on where the node is situated.
	- Directly connected to internet.
	- DMZ controlled 
	- Internal Network
	- Secure enclave

-ln

On Feb 21, 2012, at 9:47 AM, Chernin, Michael A. wrote:

> I agree that when dealing with �threats� that context matters. However, vulnerabilities alone do not imply or guarantee there is an associated threat or risk.
>  
> In my perfect world there would be a threat indicator standard that links to a structured threat standard that then could describe the CVEs used. This would allow us to continue doing vulnerability management by exposure (no threat context) or by specific threat (which provides context).
>  
> Aharon
>  
> DTCC Non-Confidential (White)
> ---------------------------------------------------
> Michael "Aharon" Chernin
> Security Automation Program Manager
> Corporate Information Security -Depository Trust & Clearing Corporation
> O: 813-470-2173
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jerome Athias
> Sent: Saturday, February 18, 2012 2:03 PM
> To: [email-masked]
> Subject: [scap_interest] The Context Concept
>  
> In a private discussion I had at ToorCon 9, with Matt Miller (skape);
> we came to the conclusion that a key (and unresolved) point of automation is the (automatic) definition of the Context in which you are where dealing with a vulnerability (threat).
> It was also identified (validated?), and introduced by Druid.
> And then, the Druid's work was related (validated?) at FRHACK 01 by Rodrigo Branco (bsdaemon).
> 
> Situation awareness (http://en.wikipedia.org/wiki/Situation_awareness) should be taken into account.
> Maybe search for "military situational awareness".
> 
> My 2 dirhams
> /JA
> 
> 
> _____________________________________________________________ 
> DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email._______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest

--Apple-Mail=_ACF3B984-10B7-4242-84C6-1A5A14CEA285
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><base href="x-msg://309/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">We also need to look at vulnerabilities as it applies an environment. &nbsp;An inherent vulnerability may have differing levels of exposure depending on what, where and how the node is deployed.&nbsp;<div><br></div><div>We maybe able to leverage Asset Identification (AI) to correlate what role the node is playing in the environment (endpoint, Server, Inter-networking Device,..) and determine level of exposure. &nbsp;The level of risk could also be applied depending on where the node is situated.</div><div><span class="Apple-tab-span" style="white-space:pre">	</span>- Directly connected to internet.</div><div><span class="Apple-tab-span" style="white-space:pre">	</span>- DMZ controlled&nbsp;</div><div><span class="Apple-tab-span" style="white-space:pre">	</span>- Internal Network</div><div><span class="Apple-tab-span" style="white-space:pre">	</span>- Secure enclave</div><div><br></div><div><br></div><div>-ln</div><div><br><div><div>On Feb 21, 2012, at 9:47 AM, Chernin, Michael A. wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div bgcolor="white" lang="EN-US" link="blue" vlink="purple"><div class="WordSection1" style="page: WordSection1; "><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">I agree that when dealing with �threats� that context matters. However, vulnerabilities alone do not imply or guarantee there is an associated threat or risk.<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">In my perfect world there would be a threat indicator standard that links to a structured threat standard that then could describe the CVEs used. This would allow us to continue doing vulnerability management by exposure (no threat context) or by specific threat (which provides context).<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Aharon<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; "><span style="font-size: 9pt; font-family: Calibri, sans-serif; ">DTCC Non-Confidential (White)<br>---------------------------------------------------<br>Michael "Aharon" Chernin<br>Security Automation Program Manager<br>Corporate Information Security -Depository Trust &amp; Clearing Corporation<br>O: 813-470-2173</span><span style="font-size: 9pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p></o:p></span></div></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div style="border-top-style: none; border-right-style: none; border-bottom-style: none; border-width: initial; border-color: initial; border-left-style: solid; border-left-color: blue; border-left-width: 1.5pt; padding-top: 0in; padding-right: 0in; padding-bottom: 0in; padding-left: 4pt; "><div><div style="border-right-style: none; border-bottom-style: none; border-left-style: none; border-width: initial; border-color: initial; border-top-style: solid; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding-top: 3pt; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; "><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; "><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: windowtext; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: windowtext; "><span class="Apple-converted-space">&nbsp;</span><a href="mailto:[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><span class="Apple-converted-space">&nbsp;</span>[mailto:[email-masked]]<span class="Apple-converted-space">&nbsp;</span><b>On Behalf Of<span class="Apple-converted-space">&nbsp;</span></b>Jerome Athias<br><b>Sent:</b><span class="Apple-converted-space">&nbsp;</span>Saturday, February 18, 2012 2:03 PM<br><b>To:</b><span class="Apple-converted-space">&nbsp;</span><a href="mailto:[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><br><b>Subject:</b><span class="Apple-converted-space">&nbsp;</span>[scap_interest] The Context Concept<o:p></o:p></span></div></div></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; "><o:p>&nbsp;</o:p></div><p class="MsoNormal" style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 12pt; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; ">In a private discussion I had at ToorCon 9, with Matt Miller (skape);<br>we came to the conclusion that a key (and unresolved) point of automation is the (automatic) definition of the Context in which you are where dealing with a vulnerability (threat).<br>It was also identified (validated?), and introduced by Druid.<br>And then, the Druid's work was related (validated?) at FRHACK 01 by Rodrigo Branco (bsdaemon).<br><br><em>Situation awareness (<a href="http://en.wikipedia.org/wiki/Situation_awareness" style="color: blue; text-decoration: underline; ">http://en.wikipedia.org/wiki/Situation_awareness</a>) should be taken into account.</em><i><br><em>Maybe search for "military situational awareness".</em><br><br><em>My 2 dirhams</em><br><em>/JA</em></i><o:p></o:p></p></div></div><br>_____________________________________________________________<span class="Apple-converted-space">&nbsp;</span><font size="2"><br>DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.</font>_______________________________________________<br>scap_interest mailing list<br><a href="mailto:[email-masked]" style="color: blue; text-decoration: underline; ">[email-masked]</a><br><a href="https://www.ietf.org/mailman/listinfo/scap_interest" style="color: blue; text-decoration: underline; ">https://www.ietf.org/mailman/listinfo/scap_interest</a></div></span></blockquote></div><br></div></body></html>
--Apple-Mail=_ACF3B984-10B7-4242-84C6-1A5A14CEA285--

From: "Chernin, Michael A." <[email-masked]>
To: Jerome Athias <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 21 Feb 2012 14:47:30 +0000
Accept-Language: en-US
Subject: Re: [scap_interest] The Context Concept

--_000_E3EFB6C0D90F82478AF227AA85ECF38015AE1F55SXEMBP01corpdtc_
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I agree that when dealing with "threats" that context matters. However, vulnerabilities alone do not imply or guarantee there is an associated threat or risk.

In my perfect world there would be a threat indicator standard that links to a structured threat standard that then could describe the CVEs used. This would allow us to continue doing vulnerability management by exposure (no threat context) or by specific threat (which provides context).

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust & Clearing Corporation
O: 813-470-2173

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jerome Athias
Sent: Saturday, February 18, 2012 2:03 PM
To: [email-masked]
Subject: [scap_interest] The Context Concept

In a private discussion I had at ToorCon 9, with Matt Miller (skape);
we came to the conclusion that a key (and unresolved) point of automation is the (automatic) definition of the Context in which you are where dealing with a vulnerability (threat).
It was also identified (validated?), and introduced by Druid.
And then, the Druid's work was related (validated?) at FRHACK 01 by Rodrigo Branco (bsdaemon).

Situation awareness (http://en.wikipedia.org/wiki/Situation_awareness) should be taken into account.
Maybe search for "military situational awareness".

My 2 dirhams
/JA

<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>
--_000_E3EFB6C0D90F82478AF227AA85ECF38015AE1F55SXEMBP01corpdtc_
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.st
	{mso-style-name:st;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">I agree that when dealing with &#8220;threats&#8221; that context matters. However, vulnerabilities alone do not imply or guarantee there is an associated threat or risk.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">In my perfect world there would be a threat indicator standard that links to a structured threat standard that then could describe the CVEs used. This would
 allow us to continue doing vulnerability management by exposure (no threat context) or by specific threat (which provides context).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Aharon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">DTCC Non-Confidential (White)<br>
---------------------------------------------------<br>
Michael &quot;Aharon&quot; Chernin<br>
Security Automation Program Manager<br>
Corporate Information Security -Depository Trust &amp; Clearing Corporation<br>
O: 813-470-2173</span><span style="font-size:9.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext"> [email-masked] [mailto:[email-masked]]
<b>On Behalf Of </b>Jerome Athias<br>
<b>Sent:</b> Saturday, February 18, 2012 2:03 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> [scap_interest] The Context Concept<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">In a private discussion I had at ToorCon 9, with Matt Miller (skape);<br>
we came to the conclusion that a key (and unresolved) point of automation is the (automatic) definition of the Context in which you are where dealing with a vulnerability (threat).<br>
It was also identified (validated?), and introduced by Druid.<br>
And then, the Druid's work was related (validated?) at FRHACK 01 by Rodrigo Branco (bsdaemon).<br>
<br>
<em>Situation awareness (<a href="http://en.wikipedia.org/wiki/Situation_awareness">http://en.wikipedia.org/wiki/Situation_awareness</a>) should be taken into account.</em><i><br>
<em>Maybe search for &quot;military situational awareness&quot;.</em><br>
<br>
<em>My 2 dirhams</em><br>
<em>/JA</em></i><o:p></o:p></p>
</div>
</div>
</body>
</html>

<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.</FONT>
--_000_E3EFB6C0D90F82478AF227AA85ECF38015AE1F55SXEMBP01corpdtc_--

From: "Schmidt, Charles M." <[email-masked]>
To: "Waltermire, David A." <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 20 Feb 2012 23:43:38 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: [scap_interest] Targeting assessments (Was "RE: Checking language needs")

------=_NextPart_000_0005_01CCEFF7.299716F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello all,

Just to follow up a bit on this thread, particularly on
scheduling/targeting/applicability testing of assessments. These topics have
all been touched on, to a greater or lesser extent, in the XCCDF
discussions. I add these comments mostly to give a little perspective - not to
say that the issues have been decided for good. In general the core question
came down to "what belongs at the XCCDF level vs. what belongs above it."
One of the use scenarios for XCCDF is to have Benchmarks published by some
vendor/authority and then used by many parties. XCCDF incorporates specific
structure to control local tailoring of a published Benchmark, but the
intent is that users should not need to go in and start manually re-writing
the Benchmark's XML before they can use it. Because of this, when the topic
of "scheduling" was raised, the community felt that this would be very
enterprise-specific and, as such, should not be embedded into an XCCDF
document - scheduling requirements from a third party would likely need to
be re-written or new structures would have to be added to XCCDF to allow
enterprise tailoring of scheduling details. The community felt that it would
make more sense for scheduling information to be stored at a level above
XCCDF (either in an even higher-level standard that was used to control
enterprise assessment, or simply in the vendor-proprietary solutions that
did this job).

Using the same yardstick, one can see that applicability, as Dave very
nicely describes it, belongs in XCCDF because that is not going to change
across enterprises - an XP assessment question is always going to be an XP
assessment question no matter who runs it. However, as noted previously,
while XCCDF does a decent job of indicating platform applicability (through
CPE references), there are other types of applicability that it does not
handle as well. These include technical role-based applicability (e.g.,
"these checks are for web-servers", "these checks are for workstations with
high-security requirements") and human role-based applicability (e.g.,
"these questions are for the department web developers"). We did have a
discussion of this gap at a developer session last year, but didn't get too
far. We noted that there were, in effect, two distinct ways in XCCDF to
denote applicability of a set of checks: the automatic CPE applicability
tests (based on platform) and the manual selection of an XCCDF
Profile. The former represent binary applicability (either the target
machine has IE10 installed or it doesn't) while the latter covers set-based
applicability (where a set of Rules might be relevant to several roles). At
the XCCDF developer session we discussed how it might be possible to allow
the automatic selection of a Profile. Briefly, the community considered this
as two problems: labeling of Profiles to designate their roles, and then
automated procedures that mapped a target to a set of roles. Creating
universally meaningful systems for either of these problems was a
significant challenge and, to my knowledge, there hasn't been progress on
this since that meeting.

Targeting then is the ugly step-child of applicability and
enterprise-specific customization. The naive solution would be the
scatter-shot approach: send the XCCDF-based assessment to every possible
target and let applicability checks (and here I am assuming that the
automated Profile selection problem has been solved) ensure that the right
combination of Rules runs on every target. However, this assumes that every
target needs to get assessed on the same schedule, that the XCCDF document
has some applicable checks for every target, and/or that the enterprise's
network can handle a lot of unnecessary traffic. A more, well, targeted
approach to targeting would be the marriage of some higher-level structure
(such as is used to control the scheduling) with some enterprise-internal
tracking system that maps targets (human or platform) to specific XCCDF
Benchmarks so that targets are sent the appropriate assessments at the
appropriate intervals. This, however, suggests a mechanism operating above
the level of the XCCDF Benchmark itself. In our developer discussion, the
example was given of a database that mapped network resources to the
appropriate Benchmark(s).

In the end this all comes down to the overall architecture that XCCDF is
intended to support - what exists above it and what exists below it (the
latter being related to Kent's thread on Checking language needs, which is a
whole other topic). There is currently an SCAP architecture in which XCCDF
is placed and this works well, but, as noted by many of the other messages
on this thread, there are still several open issues. Thus, while solving
many of the challenges outlinedin this and preceding threads are probably
long-term goals, consideration of the higher-level model (or "contracts" 
between
components, as Dave described them) into which we want any proposed XCCDF
standard to reside is probably something good to hash out at the very
beginning of any broadly-scoped effort.

Charles

>-----Original Message-----
>From: [email-masked] [mailto:scap_interest-
>[email-masked]] On Behalf Of Waltermire, David A.
>Sent: Tuesday, February 14, 2012 3:48 PM
>To: Adam Montville; [email-masked];
>[email-masked]
>Cc: [email-masked]
>Subject: Re: [scap_interest] Checking language needs
>
>The issues we are discussing can be grouped into the following separate,
but
>related functional areas.  Each should be treated as a separate concern.
Here
>are some ideas on how to parse out each area:
>
>1) Defining a "checking design pattern" - This de facto pattern is used
without
>a formal specification in many specifications including: XCCDF and the CPE
>2.3 Applicability Language.  If we define the pattern properly,
establishing a
>contract between checking clients and checking systems, we can stabilize
our
>existing uses and provide a new foundation for additional checking uses
>cases.  This may also have the effect of stimulating novel checking
solutions
>for mobile and network devices.  It may also make sense to look at breaking
>up the logical evaluation capabilities that share some commonality across
>XCCDF, OVAL and OCIL into a separate specification.  We have talked in the
>past about using the results of one check system to drive the behavior of
>another.  This type of approach might provide a mechanism to support that.
>
>2) Enterprise targeting of assets - We currently have no standardized way
to
>associate a checklist and/or a collection of checks with a set of assets
that
>need to be interrogated to determine compliance.  This is definitely a
>problem for OCIL, but the approach is not formalized for OVAL checks
either.
>The closest thing we have is the applicability approach used in XCCDF which
>is not a targeting solution.  I would argue that applicability is something
>altogether different from targeting.  Applicability allows machine readable
>guidance to be pre-qualified as being purposed for scanning specific
>software.  What we desire from a targeting perspective is assignment of a
>checklist to a collection of assets that contain the applicable software.
>Applicability can be used to determine what CAN be assigned, but it is not
>THE assignment.  It serves a separate purpose.  If we confound
applicability
>and assignment, we risk creating checklists that are specific to an asset
>instead of bei
> ng applicable to many assets.  This will hinder content reuse and
exacerbate
>content management challenges.
>
>Instead, it might be better to develop a new higher-level concept that
>enables definition of organizational digital policy that links rules in a
>checklist or checks to the appropriate assets that need to be assessed
>perhaps using ai:asset constructs.  For OCIL the asset in question could be
the
>systems admin that is responsible for a set of hosts.  For OVAL the asset
>mapping might be to a domain server that provides group policy for a
>collection of hosts, or a directory server that provides authentication
>capabilities.  This policy can also indicate the frequency, conditions and
>timing of assessments, allowing automated tasks to be dispatched based on
>this information to enact the policy.
>
>3) Tasking and scheduling - Based on the digital policy from the previous
>item, automated tasks can be created external to scanning applications to
>instruct them to perform a single scan, a recurring scan, establish a
schedule
>based on a calendar or other conditions (e.g., CPU utilization, network
load,
>etc).  By defining tasking as a separate concern from the assessment
content,
>an organization will have the ability to orchestrate the assessment of a
>checklists or a collection of checks against many different sets of assets
(e.g.,
>people, systems, networks, devices) using independent tasks.  They can also
>use the same standardized approach to orchestrate different scanning
>solutions within their environments. This further promotes content reuse
>and avoids the need to customize content for a specific scanning task or
>solution.
>
>My hope is that the MILE GRC Exchange specification can be shapped to
>support a high-level framework that allows detailed task messages to be
>exchanged using more specialized models (e.g., assessment, remdiation,
>etc.) as GRC message payloads.
>
>Dave Waltermire
>
>
>-----Original Message-----
>From: [email-masked] [mailto:scap_interest-
>[email-masked]] On Behalf Of Adam Montville
>Sent: Tuesday, February 14, 2012 3:50 PM
>To: [email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: Re: [scap_interest] Checking language needs
>
>Kent,
>
>I think scheduling should be a separate concern, but can see targeting
being
>embedded in the checking system, much as it is today in OVAL (in a way, the
>inventory definitions perform the targeting for technical checks).  If we
were
>to leverage Asset Identification, the targeting could be handled in some
>cases with a simple ai:asset reference - a person is targeted as the owner
of
>the given system.
>
>Adam
>
>From: kent_landfield
><[email-masked]<mailto:[email-masked]>>
>Date: Tue, 14 Feb 2012 14:30:27 -0600
>To:
><[email-masked]<mailto:[email-masked]
>m>>
>Cc: <[email-masked]<mailto:[email-masked]>>
>Subject: Re: [scap_interest] Checking language needs
>
>Thanks Karen!  I'll take you up on that!
>
>From the standpoint of what should be included beyond the actual
>integration issues, should this document, in addition to integration,
discuss
>issues such as targeting and scheduling for interrogative checking systems
>like OCIL or would folks consider that a separate issue to be dealt with
>somewhere else?
>
>Thoughts?
>
>Kent Landfield
>Director Content Strategy, Architecture and Standards
>
>McAfee | An Intel Company
>5000 Headquarters Dr.
>Plano, Texas 75024
>
>Direct: +1.972.963.7096
>Mobile: +1.817.637.8026
>Web: www.mcafee.com<http://www.mcafee.com/>
>
>From: Karen Scarfone
><[email-masked]<mailto:[email-masked]
>m>>
>Date: Tue, 14 Feb 2012 14:11:21 -0600
>To: Kent Landfield
><[email-masked]<mailto:[email-masked]>>
>Cc: "[email-masked]<mailto:[email-masked]>"
><[email-masked]<mailto:[email-masked]>>
>Subject: Re: [scap_interest] Checking language needs
>
>Kent,
>
>I'd be happy to help with the publication/editing side of specification
>development.
>
>
>Karen
>
>On Tue, Feb 14, 2012 at 3:02 PM,
><[email-masked]<mailto:[email-masked]>>
>wrote:
>All,
>
>One of the missing pieces we have right now is a standardized approach to
>developing new checking languages.  Within fielded XCCDF-enabled
>products today there are multiple checking languages in use. One of them
>grew up with XCCDF (OVAL) and another (OCIL) was developed without much
>concern for how it might be called and used from XCCDF.  The later's
>adoption rate has been seriously impacted because of that.  Additionally,
>vendors have at times introduced their own checking mechanisms to support
>customer needs that could not be supported with the existing checking
>languages.  Scripting is also being done directly from XCCDF benchmarks by
>multiple vendor products.
>
>As we are starting to expand security automation uses, it is important we
>enable innovative approaches to check execution. Not everything can be
>done using the existing model and existing means.  Continuous monitoring
>uses are going to require more flexibility by requiring different means to
>check certain areas than exist today.  Forcing implementers to have to dig
>thru the XCCDF specification to have to figure out how to properly
integrate
>with it is an inhibitor. We need to foster alternative means so integrating
>into the the existing security automation architectures and products is not
so
>daunting.  Even in areas where something as simple as scripting is used, I
>would be very surprised if two existing implementations could execute the
>same script content because of incompatible implementation approaches.
>Yes, OVAL is interoperable today but we need to make sure additional
>checking languages have that same potential for interoperability.
>
>From my perspective, the key to the success in fielding a useful framework
is
>assuring the right building blocks are in place.  We need to be able to
>leverage those building blocks to expand standards based security
>automation. It is important we document the proper way to develop new
>checking mechanisms if we are to have content and solutions that
>interoperate effectively.  By specifying the practices and items  new
checking
>languages need to support, we can expand what is possible with security
>automation using already fielded tools and environments.
>
>I am looking for interest here and for those that might want to help me in
>producing this draft specification.
>
>Kent Landfield
>Director Content Strategy, Architecture and Standards
>
>McAfee | An Intel Company
>5000 Headquarters Dr.
>Plano, Texas 75024
>
>Direct: +1.972.963.7096
>Mobile: +1.817.637.8026
>Web: www.mcafee.com<http://www.mcafee.com/>
>
>_______________________________________________
>scap_interest mailing list
>[email-masked]<mailto:[email-masked]>
>https://www.ietf.org/mailman/listinfo/scap_interest
>
>
>
>
>--
>Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
>[email-masked]<mailto:[email-masked]
>m>   (703)401-1018
>
>_______________________________________________ scap_interest mailing
>list [email-masked]<mailto:[email-masked]>
>https://www.ietf.org/mailman/listinfo/scap_interest
>
>_______________________________________________
>scap_interest mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/scap_interest
>_______________________________________________
>scap_interest mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/scap_interest

------=_NextPart_000_0005_01CCEFF7.299716F0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

AAAAAAA
------=_NextPart_000_0005_01CCEFF7.299716F0--

From: "Schmidt, Charles M." <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 20 Feb 2012 16:04:54 +0000
Accept-Language: en-US
Subject: [scap_interest] XCCDF going forward

------=_NextPart_000_0068_01CCEFB7.11E7CF80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello all,

Adam's original announcement specifically mentioned XCCDF 1.2.1 as something
to discuss at the upcoming side meeting. I wanted to add a few comments
along those lines.

First, NIST has a publicly accessible issue tracker where I have collected
the suggestions people have provided as to changes to the XCCDF language.
The list of open (and one re-opened) issues can be accessed here:
http://services.nvd.nist.gov/jira/browse/XCCDF#selectedTab=com.atlassian.jir
a.plugin.system.project%3Aissues-panel
(Please note this is just a public repository of raised issues. The site
does not support public discussion - we have been using the XCCDF mailing
list for that.) The issues covered in this repository range from minor
tweaks and fixes (XCCDF-93 "Make the Benchmark status property optional" and
XCCDF-83 "Reconcile 'hidden' and 'selected' properties") to items that would
significantly change the structure of the language (XCCDF-62 "Merge Value
functionality into Rules", and XCCDF-76 "XCCDF as a high-level result
aggregator"). I imagine that most of these items would be too far in the
weeds for an initial side-meeting, but I thought it might be useful to note
what sort of things the XCCDF community has been considering.

Charles

------=_NextPart_000_0068_01CCEFB7.11E7CF80
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

AAAAAAA
------=_NextPart_000_0068_01CCEFB7.11E7CF80--

Date: Sat, 18 Feb 2012 19:36:12 +0000
From: Jerome Athias <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [scap_interest] Centralized Standard Name Distribution (Neuronal approach)

Bonjour,

For the "Centralized Standard Name Distribution" problem;
I don't have the resources, and time, to try it,
but I would recommend a Neuronal approach
http://en.wikipedia.org/wiki/Neural_coding

I was validated working, ie. for automatic Captcha resolution.
And you maybe be able to construct a hierarchy in your data from this 
approach.

Voil�
/JA

From: Adam Montville <[email-masked]>
To: Jerome Athias <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sat, 18 Feb 2012 19:34:55 +0000
Accept-Language: en-US
Subject: Re: [scap_interest] The Context Concept

The importance of context extends well beyond threats and vulnerabilities as well.

Regards,

Adam

Jerome Athias <[email-masked]> wrote:

In a private discussion I had at ToorCon 9, with Matt Miller (skape);
we came to the conclusion that a key (and unresolved) point of automation is the (automatic) definition of the Context in which you are where dealing with a vulnerability (threat).
It was also identified (validated?), and introduced by Druid.
And then, the Druid's work was related (validated?) at FRHACK 01 by Rodrigo Branco (bsdaemon).

Situation awareness (http://en.wikipedia.org/wiki/Situation_awareness) should be taken into account.
Maybe search for "military situational awareness".

My 2 dirhams
/JA

Date: Sat, 18 Feb 2012 19:02:58 +0000
From: Jerome Athias <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [scap_interest] The Context Concept

This is a multi-part message in MIME format.
--------------080509080904030508060701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

In a private discussion I had at ToorCon 9, with Matt Miller (skape);
we came to the conclusion that a key (and unresolved) point of 
automation is the (automatic) definition of the Context in which you are 
where dealing with a vulnerability (threat).
It was also identified (validated?), and introduced by Druid.
And then, the Druid's work was related (validated?) at FRHACK 01 by 
Rodrigo Branco (bsdaemon).

/Situation awareness (http://en.wikipedia.org/wiki/Situation_awareness) 
should be taken into account.
Maybe search for "military situational awareness".

My 2 dirhams
/JA
/

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

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    In a private discussion I had at ToorCon 9, with Matt Miller
    (skape);<br>
    we came to the conclusion that a key (and unresolved) point of
    automation is the (automatic) definition of the Context in which you
    are where dealing with a vulnerability (threat).<br>
    It was also identified (validated?), and introduced by Druid.<br>
    And then, the Druid's work was related (validated?) at FRHACK 01 by
    Rodrigo Branco (bsdaemon).<br>
    <br>
    <span class="st"><em>Situation awareness
        (<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Situation_awareness">http://en.wikipedia.org/wiki/Situation_awareness</a>) should be
        taken into account.<br>
        Maybe search for "military situational awareness".<br>
        <br>
        My 2 dirhams<br>
        /JA<br>
      </em></span><br>
  </body>
</html>

--------------080509080904030508060701--

Date: Sat, 18 Feb 2012 15:59:14 +0000
From: Jerome Athias <[email-masked]>
To: "Waltermire, David A." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Operational Aspects

Hi there,

are you using capirca?
http://code.google.com/p/capirca/

Cheers
/JA

From: Luis Nunez <[email-masked]>
Date: Fri, 17 Feb 2012 13:38:11 -0500
To: "Schmidt, Charles M." <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Security automation and MILE

Charles,
thanks for info. and glad to see some key people working towards this.  We look forward to putting all this together.

-ln

On Feb 17, 2012, at 1:12 PM, Schmidt, Charles M. wrote:

> Hi Luis,
> 
> In fact, I am working on a TCG specification (along with Paul Sangster, Kent
> Landfield, and Steve Hanna) for exchange of SCAP information within TCG's
> Trusted Network Connect, which is NEA in the IETF. So yes - I completely
> agree that it is a natural fit and we are hoping to have a TCG spec
> outlining that fit by the end of the year. :)
> 
> Charles
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:scap_interest-
>> [email-masked]] On Behalf Of Luis Nunez
>> Sent: Friday, February 17, 2012 11:55 AM
>> To: [email-masked]>; [email-masked]
>> Cc: [email-masked]
>> Subject: Re: [scap_interest] Security automation and MILE
>> 
>> Along the lines of what Kathleen is doing.  I was wondering what are the
>> Security Automation (SCAP) connections with NEA?
>> 
>> From an endpoint assessment, SCAP is a natural fit.  Are there transport
>> specifications that a SCAP client could leverage to converse beyond a NEA
>> server?
>> 
>> thanks.
>> 
>> -ln
>> 
>> On Feb 14, 2012, at 9:47 AM, <[email-masked]>
>> <[email-masked]> wrote:
>> 
>>> Greetings,
>>> 
>>> In support of this effort, I plan to write and submit a draft very soon
> to show
>> the relevance of this work to the IETF work in MILE.  The Structured
>> Cybersecurity Information draft that extends IODEF is a very clear
>> connection.  The GRC-Exchange work is another connection point.  Once I
>> have it posted, I will share the link to this mailing list.
>>> 
>>> Best regards,
>>> Kathleen
>>> 
>>> _______________________________________________
>>> scap_interest mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/scap_interest
>> 
>> _______________________________________________
>> scap_interest mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/scap_interest

From: "Schmidt, Charles M." <[email-masked]>
To: Luis Nunez <[email-masked]>, "[email-masked]>" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 17 Feb 2012 18:12:55 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Security automation and MILE

------=_NextPart_000_0065_01CCED6D.779C9370
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Luis,

In fact, I am working on a TCG specification (along with Paul Sangster, Kent
Landfield, and Steve Hanna) for exchange of SCAP information within TCG's
Trusted Network Connect, which is NEA in the IETF. So yes - I completely
agree that it is a natural fit and we are hoping to have a TCG spec
outlining that fit by the end of the year. :)

Charles

>-----Original Message-----
>From: [email-masked] [mailto:scap_interest-
>[email-masked]] On Behalf Of Luis Nunez
>Sent: Friday, February 17, 2012 11:55 AM
>To: [email-masked]>; [email-masked]
>Cc: [email-masked]
>Subject: Re: [scap_interest] Security automation and MILE
>
>Along the lines of what Kathleen is doing.  I was wondering what are the
>Security Automation (SCAP) connections with NEA?
>
>From an endpoint assessment, SCAP is a natural fit.  Are there transport
>specifications that a SCAP client could leverage to converse beyond a NEA
>server?
>
>thanks.
>
>-ln
>
>On Feb 14, 2012, at 9:47 AM, <[email-masked]>
><[email-masked]> wrote:
>
>> Greetings,
>>
>> In support of this effort, I plan to write and submit a draft very soon
to show
>the relevance of this work to the IETF work in MILE.  The Structured
>Cybersecurity Information draft that extends IODEF is a very clear
>connection.  The GRC-Exchange work is another connection point.  Once I
>have it posted, I will share the link to this mailing list.
>>
>> Best regards,
>> Kathleen
>>
>> _______________________________________________
>> scap_interest mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/scap_interest
>
>_______________________________________________
>scap_interest mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/scap_interest

------=_NextPart_000_0065_01CCED6D.779C9370
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

AAAAAAA
------=_NextPart_000_0065_01CCED6D.779C9370--

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Fri, 17 Feb 2012 12:58:21 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: [email-masked]
Subject: Re: [scap_interest] Security automation and MILE

Hi Luis,

We will have an update to the GRC-exchange document that generalizes RID to cover the exchange of other schemas posted soon.  This is part of the MILE charter.  It may hit some of the objectives for transport, although there could be others that are extensions from NEA that I am also interested to learn about.  We should try to fit the pieces together as we evolve specifications to standards for this ecosystem.

Thanks,
Kathleen

-----Original Message-----
From: Luis Nunez [mailto:[email-masked]] 
Sent: Friday, February 17, 2012 12:55 PM
To: Moriarty, Kathleen; [email-masked]
Cc: [email-masked]
Subject: Re: [scap_interest] Security automation and MILE

Along the lines of what Kathleen is doing.  I was wondering what are the Security Automation (SCAP) connections with NEA?

>From an endpoint assessment, SCAP is a natural fit.  Are there transport specifications that a SCAP client could leverage to converse beyond a NEA server? 

thanks.

-ln

On Feb 14, 2012, at 9:47 AM, <[email-masked]> <[email-masked]> wrote:

> Greetings,
> 
> In support of this effort, I plan to write and submit a draft very soon to show the relevance of this work to the IETF work in MILE.  The Structured Cybersecurity Information draft that extends IODEF is a very clear connection.  The GRC-Exchange work is another connection point.  Once I have it posted, I will share the link to this mailing list.
> 
> Best regards,
> Kathleen
> 
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest

From: Luis Nunez <[email-masked]>
Date: Fri, 17 Feb 2012 12:54:59 -0500
To: "[email-masked]>" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [scap_interest] Security automation and MILE

Along the lines of what Kathleen is doing.  I was wondering what are the Security Automation (SCAP) connections with NEA?

From an endpoint assessment, SCAP is a natural fit.  Are there transport specifications that a SCAP client could leverage to converse beyond a NEA server? 

thanks.

-ln

On Feb 14, 2012, at 9:47 AM, <[email-masked]> <[email-masked]> wrote:

> Greetings,
> 
> In support of this effort, I plan to write and submit a draft very soon to show the relevance of this work to the IETF work in MILE.  The Structured Cybersecurity Information draft that extends IODEF is a very clear connection.  The GRC-Exchange work is another connection point.  Once I have it posted, I will share the link to this mailing list.
> 
> Best regards,
> Kathleen
> 
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest

From: Luis Nunez <[email-masked]>
Date: Fri, 17 Feb 2012 11:37:55 -0500
To: Jerome Athias <[email-masked]>
Cc: [email-masked]
Subject: Re: [scap_interest] Software Vulnerability Mitigation Automation - IVIL v1.0

I certainly see this theme of "information sharing" and"standards" emanating from US politics. I am sure similar issues are being debated else where globally. 

Thanks for providing the snap shot of the intricacies of security information.  I wanted to emphasis some of the problems we are trying solve here. We are trying to solve the problem of communicating and connecting the dots all in a cooperative and cohesive way.  So it starts with standardizing the Security Automation specifications.

I look forward to seeing more of the "vulnerability interoperability" proposal.

Thanks.

-ln

On Feb 15, 2012, at 8:11 PM, Jerome Athias wrote:

> As mentioned in the U.S. "INTERNATIONAL STRATEGY FOR CYBERSPACE"[1] document,
> we need "interoperable and secure technical standards, determined by technical experts".
> 
> I would like to introduce my vision of "Software Vulnerability Mitigation Automation"
> via IVIL v1.0 via a (incomplete) Conceptual Map.
> 
> Requirements: ~15 minutes of your time, a headset and the Bol�ro
> 
> https://corevidence.com/research/vulnerability_interoperability_ivil_v1.jpg
> 
> (I extracted some links, please see below)
> 
> 
> 
> i = x2ivil + ivil2x
> where "i" is interoperability and "x" a software (vulnerability scanner,... + waf, virtual patching system, ...)
> 
> What do you think?
> 
> Thank you.
> Best regards,
> 
> Jerome Athias - NETpeas
> VP, Director of Software Engineer
> Palo Alto - Paris - Casablanca
> http://www.netpeas.com
> 
> "The computer security is an art form. It's the ultimate martial art."
> 
> 
> 
> [1]    http://www.whitehouse.gov/blog/2011/05/16/launching-us-international-strategy-cyberspace
> IVIL-XML    http://www.cupfighter.net/index.php/2010/10/ivil-an-xml-schema-to-exchange-vulnerability-information/
> ThreadFix    http://code.google.com/p/threadfix/
> 
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest

From: Adam Montville <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 17 Feb 2012 16:00:01 +0000
Accept-Language: en-US
Subject: Re: [scap_interest] scap_interest Digest, Vol 5, Issue 19

+1

On 2/17/12 7:28 AM, "[email-masked]"
<[email-masked]> wrote:

>Hello, Rubin, Kent, all,
>
>I think interoperability testing is an important aspect of the
>standardization process.  It helps us prove out the specifications are
>well written (or that they require changes) which enables new vendors or
>implementers to code against the same specification and expect an
>interoperable implementation.
>
>This is important at each stage, from supporting data formats to the
>ability to uniformly exchanging those formats with interpretable controls
>and expected messaging patterns/flows.  The specifications for the data
>formats should go beyond schemas to cover error handling and other
>requirements for developers to enable interoperable solution development.
> When you move to transport and APIs for exchanges, this becomes more
>critical if we want to evolve the ability to support the ecosystem of
>data format specifications.  Products and use of these specifications can
>diverge by adding value in areas like data analysis and how exchanged
>data sets may be leveraged.
>
>Thank you,
>Kathleen  
>
>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Oliva, Ruben [USA]
>Sent: Friday, February 17, 2012 9:26 AM
>To: [email-masked]
>Subject: Re: [scap_interest] scap_interest Digest, Vol 5, Issue 19
>
>To all:
>
>Kent brings up a good point.
>
>Validation does not equate to interoperability.
>
>How does the community feel about an SCAP interoperability testing
>function?
>
>David Oliva
>
>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of
>[email-masked]
>Sent: Thursday, February 16, 2012 1:00 PM
>To: [email-masked]
>Subject: scap_interest Digest, Vol 5, Issue 19
>
>If you have received this digest without all the individual message
>attachments you will need to update your digest options in your list
>subscription.  To do so, go to
>
>https://www.ietf.org/mailman/listinfo/scap_interest
>
>Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME
>or Plain Text Digests?" to MIME.  You can set this option globally for
>all the list digests you receive at this point.
>
>
>
>Send scap_interest mailing list submissions to
>	[email-masked]
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	https://www.ietf.org/mailman/listinfo/scap_interest
>or, via email, send a message with subject or body 'help' to
>	[email-masked]
>
>You can reach the person managing the list at
>	[email-masked]
>
>When replying, please edit your Subject line so it is more specific than
>"Re: Contents of scap_interest digest..."
>_______________________________________________
>scap_interest mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/scap_interest
>
>_______________________________________________
>scap_interest mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/scap_interest
>

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Fri, 17 Feb 2012 10:28:21 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [scap_interest] scap_interest Digest, Vol 5, Issue 19

Hello, Rubin, Kent, all,

I think interoperability testing is an important aspect of the standardization process.  It helps us prove out the specifications are well written (or that they require changes) which enables new vendors or implementers to code against the same specification and expect an interoperable implementation. 

This is important at each stage, from supporting data formats to the ability to uniformly exchanging those formats with interpretable controls and expected messaging patterns/flows.  The specifications for the data formats should go beyond schemas to cover error handling and other requirements for developers to enable interoperable solution development.  When you move to transport and APIs for exchanges, this becomes more critical if we want to evolve the ability to support the ecosystem of data format specifications.  Products and use of these specifications can diverge by adding value in areas like data analysis and how exchanged data sets may be leveraged.  

Thank you,
Kathleen  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Oliva, Ruben [USA]
Sent: Friday, February 17, 2012 9:26 AM
To: [email-masked]
Subject: Re: [scap_interest] scap_interest Digest, Vol 5, Issue 19

To all:

Kent brings up a good point.

Validation does not equate to interoperability.

How does the community feel about an SCAP interoperability testing function?

David Oliva

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, February 16, 2012 1:00 PM
To: [email-masked]
Subject: scap_interest Digest, Vol 5, Issue 19

If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/scap_interest

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME.  You can set this option globally for all the list digests you receive at this point.

Send scap_interest mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/scap_interest
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of scap_interest digest..."
_______________________________________________
scap_interest mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/scap_interest

From: "Oliva, Ruben [USA]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 17 Feb 2012 14:25:33 +0000
Accept-Language: en-US
Subject: Re: [scap_interest] scap_interest Digest, Vol 5, Issue 19

To all:

Kent brings up a good point.

Validation does not equate to interoperability.

How does the community feel about an SCAP interoperability testing function?

David Oliva

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, February 16, 2012 1:00 PM
To: [email-masked]
Subject: scap_interest Digest, Vol 5, Issue 19

If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/scap_interest

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME.  You can set this option globally for all the list digests you receive at this point.

Send scap_interest mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/scap_interest
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of scap_interest digest..."

From: "Chandrashekhar B" <[email-masked]>
To: "'Waltermire, David A.'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Fri, 17 Feb 2012 17:42:02 +0530
Organization: SecPod Technologies
Cc: [email-masked]
Subject: Re: [scap_interest] Operational Aspects
Reply-To: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_0007_01CCED9B.790F2050
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I highlighted the interfaces to be standardized in the recent ITSAC,

http://scap.nist.gov/events/2011/itsac/presentations/day3/Basavanna%20-%20SC
AP%20Content%20Repository.pdf

Search interfaces for all SCAP elements need to be standardized along with
Client validation as Gunnar noted already. We currently have API's to do the
searches, we are considering giving an external interface through WSDL.

Chandra.

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Waltermire, David A.
Sent: Friday, February 17, 2012 12:32 AM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: Re: [scap_interest] Operational Aspects

We are continuing to work on this and I am very interested in developing
standards in this area.  I am currently working on developing an open source
prototype that can be used to evaluate standardized approaches to this
problem.  I haven't published the latest code on this yet, but the original
work we started can be found at:

http://code.google.com/p/security-automation-content-repository/

The companion presentation to Kent's from March can be found here:

http://scap.nist.gov/events/2011/saddsp/presentations/Security_Automation_Co
ntent_Repository_Demo.pdf

Dave

From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Thursday, February 16, 2012 1:46 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [scap_interest] Operational Aspects

I see the topic of Content Repository interfaces as very important item that
really should be worked here.  We have been talking about this topic for
over two years now as you both are aware.  I am including the presentation
that was given at SCAP Winter Developer Days last March that may help frame
the issues.   

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com <http://www.mcafee.com/> 

From: Luis Nunez <[email-masked]>
Date: Thu, 16 Feb 2012 11:54:21 -0600
To: Adam Montville <[email-masked]>
Cc: Kent Landfield <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [scap_interest] Operational Aspects

Since you mentioned "NVD" also known as the National Vulnerability Database.
I think at some point the IETF will be helpful in creating a protocol to
communicate with these content repositories.  Last I counted was 7 content
repositories.

In no particular order and I am sure there are more out there.

-SecPod

-Novell

-NVD

-IT Security Database

-Debian 

-Altx-soft

-ln

  

On Feb 14, 2012, at 5:18 PM, Adam Montville wrote:

Fair enough.  Just throwing things against the wall as they come to mind.

Adam

From: kent_landfield
<[email-masked]<mailto:[email-masked]
<mailto:[email-masked]%3e> >>

Date: Tue, 14 Feb 2012 15:32:38 -0600

To: Adam Montville <[email-masked]<mailto:[email-masked]
<mailto:[email-masked]%3e> >>,
<[email-masked]<mailto:[email-masked]
<mailto:[email-masked]%3e> >>

Subject: Re: [scap_interest] Operational Aspects

Adam,

We have more than enough on our plate with the specification / I-D work.
Let's see if we can deal with this in a more appropriate forum. I do not see
this as that forum.  My 2cents.

Thanks.

Kent Landfield

Director Content Strategy, Architecture and Standards

McAfee | An Intel Company

5000 Headquarters Dr.

Plano, Texas 75024

Direct: +1.972.963.7096

Mobile: +1.817.637.8026

Web: www.mcafee.com<http://www.mcafee.com/>

From: Adam Montville <[email-masked]<mailto:[email-masked]
<mailto:[email-masked]%3e> >>

Date: Tue, 14 Feb 2012 15:12:51 -0600

To: "[email-masked]<mailto:[email-masked]
<mailto:[email-masked]%3e> >"
<[email-masked]<mailto:[email-masked]
<mailto:[email-masked]%3e> >>

Subject: [scap_interest] Operational Aspects

While we're all bantering about on security automation, there's another side
to the story.  Are there any operational concerns we might address within a
WG should one be formed?  For example, we have, in the United States, NVD
hosting a repository of information.  CCE identifiers are moderated and
assigned by an operational process.  As new enumerations are published and
new types of content are conceived, it's easy to imagine the need for some
operational standardization.

Should we consider standardizing some of these processes, and if so would
the WG we seek to establish be the appropriate place for that work?

Regards,

Adam W. Montville | Security and Compliance Architect

Direct: 503 276-7661

Mobile: 360 471-7815

TRIPWIRE | Take CONTROL

http://www.tripwire.com

_______________________________________________

scap_interest mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/scap_interest

_______________________________________________

scap_interest mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/scap_interest

 

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1913 / Virus Database: 2112/4813 - Release Date: 02/16/12

------=_NextPart_000_0007_01CCED9B.790F2050
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I highlighted the interfaces to be standardized in the recent ITSAC,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><a href="http://scap.nist.gov/events/2011/itsac/presentations/day3/Basavanna%20-%20SCAP%20Content%20Repository.pdf">http://scap.nist.gov/events/2011/itsac/presentations/day3/Basavanna%20-%20SCAP%20Content%20Repository.pdf</a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Search interfaces for all SCAP elements need to be standardized along with Client validation as Gunnar noted already. We currently have API&#8217;s to do the searches, we are considering giving an external interface through WSDL.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Chandra.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> [email-masked] [mailto:[email-masked]] <b>On Behalf Of </b>Waltermire, David A.<br><b>Sent:</b> Friday, February 17, 2012 12:32 AM<br><b>To:</b> [email-masked]; [email-masked]; [email-masked]<br><b>Cc:</b> [email-masked]<br><b>Subject:</b> Re: [scap_interest] Operational Aspects<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>We are continuing to work on this and I am very interested in developing standards in this area.&nbsp; I am currently working on developing an open source prototype that can be used to evaluate standardized approaches to this problem.&nbsp; I haven&#8217;t published the latest code on this yet, but the original work we started can be found at:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><a href="http://code.google.com/p/security-automation-content-repository/">http://code.google.com/p/security-automation-content-repository/</a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The companion presentation to Kent&#8217;s from March can be found here:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><a href="http://scap.nist.gov/events/2011/saddsp/presentations/Security_Automation_Content_Repository_Demo.pdf">http://scap.nist.gov/events/2011/saddsp/presentations/Security_Automation_Content_Repository_Demo.pdf</a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Dave<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> [email-masked] [mailto:[email-masked]] <b>On Behalf Of </b>[email-masked]<br><b>Sent:</b> Thursday, February 16, 2012 1:46 PM<br><b>To:</b> [email-masked]; [email-masked]<br><b>Cc:</b> [email-masked]<br><b>Subject:</b> Re: [scap_interest] Operational Aspects<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><div><div><div><p class=MsoNormal><span style='color:black'>I see the topic of Content Repository interfaces as very important item that really should be worked here. &nbsp;We have been talking about this topic for over two years now as you both are aware. &nbsp;I am including the presentation that was given at SCAP Winter Developer Days last March that may help frame the issues. &nbsp;&nbsp;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><div><p class=MsoNormal><strong><span style='font-size:9.0pt;font-family:"Arial","sans-serif";color:#606A71'>Kent Landfield</span></strong><span style='font-size:9.0pt;font-family:"Arial","sans-serif";color:#606A71'><br><span class=apple-style-span>Director Content Strategy, Architecture and Standards</span><br><br><strong><span style='font-family:"Arial","sans-serif"'>McAfee | An Intel Company</span></strong><br><span class=apple-style-span>5000 Headquarters Dr.</span><br><span class=apple-style-span>Plano, Texas 75024</span><br><br><span class=apple-style-span>Direct: +1.972.963.7096&nbsp;</span><br><span class=apple-style-span>Mobile: +1.817.637.8026</span><br><strong><span style='font-family:"Arial","sans-serif"'>Web:&nbsp;</span></strong><span class=apple-style-span><a href="http://www.mcafee.com/">www.mcafee.com</a></span></span><span style='color:black'><o:p></o:p></span></p></div></div></div></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>From: </span></b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Luis Nunez &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><b>Date: </b>Thu, 16 Feb 2012 11:54:21 -0600<br><b>To: </b>Adam Montville &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><b>Cc: </b>Kent Landfield &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;, &quot;<a href="mailto:[email-masked]">[email-masked]</a>&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><b>Subject: </b>Re: [scap_interest] Operational Aspects<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><blockquote style='border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt' id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><div><div><p class=MsoNormal><span style='color:black'>Since you mentioned &quot;NVD&quot; also known as the National Vulnerability Database.&nbsp;&nbsp;I think at some point the IETF will be helpful in creating a protocol to communicate with these content repositories.&nbsp;&nbsp;Last I counted was 7 content repositories.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>In no particular order and I am sure there are more out there.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>-SecPod<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>-Novell<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>-NVD<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>-IT Security Database<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>-Debian <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>-Altx-soft<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>-ln<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>&nbsp;&nbsp;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>On Feb 14, 2012, at 5:18 PM, Adam Montville wrote:<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><blockquote style='border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt' id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><p class=MsoNormal><span style='color:black'>Fair enough.&nbsp;&nbsp;Just throwing things against the wall as they come to mind.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Adam<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>From: kent_landfield &lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]%3e">mailto:[email-masked]&gt;</a>&gt;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Date: Tue, 14 Feb 2012 15:32:38 -0600<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>To: Adam Montville &lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]%3e">mailto:[email-masked]&gt;</a>&gt;, &lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]%3e">mailto:[email-masked]&gt;</a>&gt;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Subject: Re: [scap_interest] Operational Aspects<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Adam,<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>We have more than enough on our plate with the specification / I-D work.&nbsp;&nbsp;Let's see if we can deal with this in a more appropriate forum. I do not see this as that forum.&nbsp;&nbsp;My 2cents&#8230;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Thanks.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Kent Landfield<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Director Content Strategy, Architecture and Standards<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>McAfee | An Intel Company<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>5000 Headquarters Dr.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Plano, Texas 75024<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Direct: +1.972.963.7096<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Mobile: +1.817.637.8026<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Web: www.mcafee.com&lt;<a href="http://www.mcafee.com/">http://www.mcafee.com/</a>&gt;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>From: Adam Montville &lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]%3e">mailto:[email-masked]&gt;</a>&gt;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Date: Tue, 14 Feb 2012 15:12:51 -0600<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>To: &quot;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]%3e">mailto:[email-masked]&gt;</a>&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]%3e">mailto:[email-masked]&gt;</a>&gt;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Subject: [scap_interest] Operational Aspects<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>While we're all bantering about on security automation, there's another side to the story.&nbsp;&nbsp;Are there any operational concerns we might address within a WG should one be formed?&nbsp;&nbsp;For example, we have, in the United States, NVD hosting a repository of information.&nbsp;&nbsp;CCE identifiers are moderated and assigned by an operational process.&nbsp;&nbsp;As new enumerations are published and new types of content are conceived, it's easy to imagine the need for some operational standardization.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Should we consider standardizing some of these processes, and if so would the WG we seek to establish be the appropriate place for that work?<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Regards,<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Adam W. Montville | Security and Compliance Architect<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Direct: 503 276-7661<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Mobile: 360 471-7815<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>TRIPWIRE | Take CONTROL<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><a href="http://www.tripwire.com">http://www.tripwire.com</a><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>_______________________________________________<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>scap_interest mailing list<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]">mailto:[email-masked]</a>&gt;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>_______________________________________________<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>scap_interest mailing list<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><a href="mailto:[email-masked]">[email-masked]</a><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a><o:p></o:p></span></p></div></blockquote><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div></div></div></blockquote><div class=MsoNormal align=center style='text-align:center'><span style='color:black'><hr size=1 width="100%" noshade style='color:#ACA899' align=center></span></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:black'>No virus found in this message.<br>Checked by AVG - <a href="http://www.avg.com">www.avg.com</a><br>Version: 2012.0.1913 / Virus Database: 2112/4813 - Release Date: 02/16/12<o:p></o:p></span></p></div></body></html>
------=_NextPart_000_0007_01CCED9B.790F2050--

From: "Waltermire, David A." <[email-masked]>
To: Adam Montville <[email-masked]>, kent_landfield <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 16 Feb 2012 21:48:57 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Operational Aspects

I will take you up on that when the time comes. ;-)

Dave

> -----Original Message-----
> From: Adam Montville [mailto:[email-masked]]
> Sent: Thursday, February 16, 2012 6:44 PM
> To: Waltermire, David A.; kent_landfield; [email-masked]
> Cc: [email-masked]
> Subject: Re: [scap_interest] Operational Aspects
> 
> I'd like to contribute to this as well - as much as I can anyway.
> 
> From: "Waltermire, David A."
> <[email-masked]<mailto:[email-masked]>>
> Date: Thu, 16 Feb 2012 14:02:04 -0500
> To: kent_landfield
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>, Adam Montville
> <[email-masked]<mailto:[email-masked]>>
> Cc: "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>
> Subject: RE: [scap_interest] Operational Aspects
> 
> We are continuing to work on this and I am very interested in
> developing standards in this area.  I am currently working on
> developing an open source prototype that can be used to evaluate
> standardized approaches to this problem.  I haven't published the
> latest code on this yet, but the original work we started can be found
> at:
> 
> http://code.google.com/p/security-automation-content-repository/
> 
> The companion presentation to Kent's from March can be found here:
> 
> http://scap.nist.gov/events/2011/saddsp/presentations/Security_Automati
> on_Content_Repository_Demo.pdf
> 
> Dave
> 
> From: [email-masked]<mailto:scap_interest-
> [email-masked]> [mailto:[email-masked]] On Behalf Of
> [email-masked]<mailto:[email-masked]>
> Sent: Thursday, February 16, 2012 1:46 PM
> To: [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> Subject: Re: [scap_interest] Operational Aspects
> 
> I see the topic of Content Repository interfaces as very important item
> that really should be worked here.  We have been talking about this
> topic for over two years now as you both are aware.  I am including the
> presentation that was given at SCAP Winter Developer Days last March
> that may help frame the issues.
> 
> Kent Landfield
> Director Content Strategy, Architecture and Standards
> 
> McAfee | An Intel Company
> 5000 Headquarters Dr.
> Plano, Texas 75024
> 
> Direct: +1.972.963.7096
> Mobile: +1.817.637.8026
> Web: www.mcafee.com<http://www.mcafee.com/>
> 
> From: Luis Nunez
> <[email-masked]<mailto:[email-masked]>>
> Date: Thu, 16 Feb 2012 11:54:21 -0600
> To: Adam Montville
> <[email-masked]<mailto:[email-masked]>>
> Cc: Kent Landfield
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>
> Subject: Re: [scap_interest] Operational Aspects
> 
> Since you mentioned "NVD" also known as the National Vulnerability
> Database.  I think at some point the IETF will be helpful in creating a
> protocol to communicate with these content repositories.  Last I
> counted was 7 content repositories.
> In no particular order and I am sure there are more out there.
> 
> -SecPod
> -Novell
> -NVD
> -IT Security Database
> -Debian
> -Altx-soft
> 
> -ln
> 
> 
> On Feb 14, 2012, at 5:18 PM, Adam Montville wrote:
> 
> Fair enough.  Just throwing things against the wall as they come to
> mind.
> Adam
> From: kent_landfield
> <[email-masked]<mailto:[email-masked]><mailto:ken
> [email-masked]><mailto:[email-masked]%3e>>
> Date: Tue, 14 Feb 2012 15:32:38 -0600
> To: Adam Montville
> <[email-masked]<mailto:[email-masked]><mailto:amontvi
> [email-masked]><mailto:[email-masked]%3e>>,
> <[email-masked]<mailto:[email-masked]><mailto:scap_inte
> [email-masked]><mailto:[email-masked]%3e>>
> Subject: Re: [scap_interest] Operational Aspects Adam, We have more
> than enough on our plate with the specification / I-D work.  Let's see
> if we can deal with this in a more appropriate forum. I do not see this
> as that forum.  My 2cents... Thanks.
> Kent Landfield
> Director Content Strategy, Architecture and Standards McAfee | An Intel
> Company
> 5000 Headquarters Dr.
> Plano, Texas 75024
> Direct: +1.972.963.7096
> Mobile: +1.817.637.8026
> Web: www.mcafee.com<http://www.mcafee.com/>
> From: Adam Montville
> <[email-masked]<mailto:[email-masked]><mailto:amontvi
> [email-masked]><mailto:[email-masked]%3e>>
> Date: Tue, 14 Feb 2012 15:12:51 -0600
> To:
> "[email-masked]<mailto:[email-masked]><mailto:scap_inte
> [email-masked]><mailto:[email-masked]%3e>"
> <[email-masked]<mailto:[email-masked]><mailto:scap_inte
> [email-masked]><mailto:[email-masked]%3e>>
> Subject: [scap_interest] Operational Aspects While we're all bantering
> about on security automation, there's another side to the story.  Are
> there any operational concerns we might address within a WG should one
> be formed?  For example, we have, in the United States, NVD hosting a
> repository of information.  CCE identifiers are moderated and assigned
> by an operational process.  As new enumerations are published and new
> types of content are conceived, it's easy to imagine the need for some
> operational standardization.
> Should we consider standardizing some of these processes, and if so
> would the WG we seek to establish be the appropriate place for that
> work?
> Regards,
> Adam W. Montville | Security and Compliance Architect
> Direct: 503 276-7661
> Mobile: 360 471-7815
> TRIPWIRE | Take CONTROL
> http://www.tripwire.com
> _______________________________________________
> scap_interest mailing list
> [email-masked]<mailto:[email-masked]><mailto:scap_inter
> [email-masked]>
> https://www.ietf.org/mailman/listinfo/scap_interest
> _______________________________________________
> scap_interest mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/scap_interest
> 
> 
> ________________________________
> No virus found in this message.
> Checked by AVG - www.avg.com<http://www.avg.com>
> Version: 2012.0.1913 / Virus Database: 2112/4813 - Release Date:
> 02/16/12

From: Adam Montville <[email-masked]>
To: "Waltermire, David A." <[email-masked]>, kent_landfield <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 16 Feb 2012 23:43:42 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Operational Aspects

I'd like to contribute to this as well � as much as I can anyway.

From: "Waltermire, David A." <[email-masked]<mailto:[email-masked]>>
Date: Thu, 16 Feb 2012 14:02:04 -0500
To: kent_landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Adam Montville <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [scap_interest] Operational Aspects

We are continuing to work on this and I am very interested in developing standards in this area.  I am currently working on developing an open source prototype that can be used to evaluate standardized approaches to this problem.  I haven�t published the latest code on this yet, but the original work we started can be found at:

http://code.google.com/p/security-automation-content-repository/

The companion presentation to Kent�s from March can be found here:

http://scap.nist.gov/events/2011/saddsp/presentations/Security_Automation_Content_Repository_Demo.pdf

Dave

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, February 16, 2012 1:46 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [scap_interest] Operational Aspects

I see the topic of Content Repository interfaces as very important item that really should be worked here.  We have been talking about this topic for over two years now as you both are aware.  I am including the presentation that was given at SCAP Winter Developer Days last March that may help frame the issues.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Luis Nunez <[email-masked]<mailto:[email-masked]>>
Date: Thu, 16 Feb 2012 11:54:21 -0600
To: Adam Montville <[email-masked]<mailto:[email-masked]>>
Cc: Kent Landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Operational Aspects

Since you mentioned "NVD" also known as the National Vulnerability Database.  I think at some point the IETF will be helpful in creating a protocol to communicate with these content repositories.  Last I counted was 7 content repositories.
In no particular order and I am sure there are more out there.

-SecPod
-Novell
-NVD
-IT Security Database
-Debian
-Altx-soft

-ln

On Feb 14, 2012, at 5:18 PM, Adam Montville wrote:

Fair enough.  Just throwing things against the wall as they come to mind.
Adam
From: kent_landfield <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Date: Tue, 14 Feb 2012 15:32:38 -0600
To: Adam Montville <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>, <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Subject: Re: [scap_interest] Operational Aspects
Adam,
We have more than enough on our plate with the specification / I-D work.  Let's see if we can deal with this in a more appropriate forum. I do not see this as that forum.  My 2cents�
Thanks.
Kent Landfield
Director Content Strategy, Architecture and Standards
McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>
From: Adam Montville <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Date: Tue, 14 Feb 2012 15:12:51 -0600
To: "[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Subject: [scap_interest] Operational Aspects
While we're all bantering about on security automation, there's another side to the story.  Are there any operational concerns we might address within a WG should one be formed?  For example, we have, in the United States, NVD hosting a repository of information.  CCE identifiers are moderated and assigned by an operational process.  As new enumerations are published and new types of content are conceived, it's easy to imagine the need for some operational standardization.
Should we consider standardizing some of these processes, and if so would the WG we seek to establish be the appropriate place for that work?
Regards,
Adam W. Montville | Security and Compliance Architect
Direct: 503 276-7661
Mobile: 360 471-7815
TRIPWIRE | Take CONTROL
http://www.tripwire.com
_______________________________________________
scap_interest mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scap_interest
_______________________________________________
scap_interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scap_interest

________________________________
No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2012.0.1913 / Virus Database: 2112/4813 - Release Date: 02/16/12

From: "Waltermire, David A." <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 16 Feb 2012 14:02:04 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Operational Aspects

--_000_D7A0423E5E193F40BE6E94126930C4930906BF334FMBCLUSTERxcha_
Content-Type: text/plain; charset="us-ascii"

We are continuing to work on this and I am very interested in developing standards in this area.  I am currently working on developing an open source prototype that can be used to evaluate standardized approaches to this problem.  I haven't published the latest code on this yet, but the original work we started can be found at:

http://code.google.com/p/security-automation-content-repository/

The companion presentation to Kent's from March can be found here:

http://scap.nist.gov/events/2011/saddsp/presentations/Security_Automation_Content_Repository_Demo.pdf

Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, February 16, 2012 1:46 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [scap_interest] Operational Aspects

I see the topic of Content Repository interfaces as very important item that really should be worked here.  We have been talking about this topic for over two years now as you both are aware.  I am including the presentation that was given at SCAP Winter Developer Days last March that may help frame the issues.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Luis Nunez <[email-masked]<mailto:[email-masked]>>
Date: Thu, 16 Feb 2012 11:54:21 -0600
To: Adam Montville <[email-masked]<mailto:[email-masked]>>
Cc: Kent Landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Operational Aspects

Since you mentioned "NVD" also known as the National Vulnerability Database.  I think at some point the IETF will be helpful in creating a protocol to communicate with these content repositories.  Last I counted was 7 content repositories.
In no particular order and I am sure there are more out there.

-SecPod
-Novell
-NVD
-IT Security Database
-Debian
-Altx-soft

-ln

On Feb 14, 2012, at 5:18 PM, Adam Montville wrote:

Fair enough.  Just throwing things against the wall as they come to mind.
Adam
From: kent_landfield <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Date: Tue, 14 Feb 2012 15:32:38 -0600
To: Adam Montville <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>, <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Subject: Re: [scap_interest] Operational Aspects
Adam,
We have more than enough on our plate with the specification / I-D work.  Let's see if we can deal with this in a more appropriate forum. I do not see this as that forum.  My 2cents...
Thanks.
Kent Landfield
Director Content Strategy, Architecture and Standards
McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>
From: Adam Montville <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Date: Tue, 14 Feb 2012 15:12:51 -0600
To: "[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Subject: [scap_interest] Operational Aspects
While we're all bantering about on security automation, there's another side to the story.  Are there any operational concerns we might address within a WG should one be formed?  For example, we have, in the United States, NVD hosting a repository of information.  CCE identifiers are moderated and assigned by an operational process.  As new enumerations are published and new types of content are conceived, it's easy to imagine the need for some operational standardization.
Should we consider standardizing some of these processes, and if so would the WG we seek to establish be the appropriate place for that work?
Regards,
Adam W. Montville | Security and Compliance Architect
Direct: 503 276-7661
Mobile: 360 471-7815
TRIPWIRE | Take CONTROL
http://www.tripwire.com
_______________________________________________
scap_interest mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scap_interest
_______________________________________________
scap_interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scap_interest

________________________________
No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2012.0.1913 / Virus Database: 2112/4813 - Release Date: 02/16/12

--_000_D7A0423E5E193F40BE6E94126930C4930906BF334FMBCLUSTERxcha_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: base64

--_000_D7A0423E5E193F40BE6E94126930C4930906BF334FMBCLUSTERxcha_--

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Thu, 16 Feb 2012 12:46:19 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: [email-masked]
Subject: Re: [scap_interest] Operational Aspects

--_004_CB62A1172C9E8kentlandfieldmcafeecom_
Content-Type: multipart/alternative;
	boundary="_000_CB62A1172C9E8kentlandfieldmcafeecom_"

--_000_CB62A1172C9E8kentlandfieldmcafeecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I see the topic of Content Repository interfaces as very important item that really should be worked here.  We have been talking about this topic for over two years now as you both are aware.  I am including the presentation that was given at SCAP Winter Developer Days last March that may help frame the issues.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Luis Nunez <[email-masked]<mailto:[email-masked]>>
Date: Thu, 16 Feb 2012 11:54:21 -0600
To: Adam Montville <[email-masked]<mailto:[email-masked]>>
Cc: Kent Landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Operational Aspects

Since you mentioned "NVD" also known as the National Vulnerability Database.  I think at some point the IETF will be helpful in creating a protocol to communicate with these content repositories.  Last I counted was 7 content repositories.
In no particular order and I am sure there are more out there.

-SecPod
-Novell
-NVD
-IT Security Database
-Debian
-Altx-soft

-ln

On Feb 14, 2012, at 5:18 PM, Adam Montville wrote:

Fair enough.  Just throwing things against the wall as they come to mind.
Adam
From: kent_landfield <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 15:32:38 -0600
To: Adam Montville <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Subject: Re: [scap_interest] Operational Aspects
Adam,
We have more than enough on our plate with the specification / I-D work.  Let's see if we can deal with this in a more appropriate forum. I do not see this as that forum.  My 2cents�
Thanks.
Kent Landfield
Director Content Strategy, Architecture and Standards
McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>
From: Adam Montville <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 15:12:51 -0600
To: "[email-masked]<mailto:[email-masked]><mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Subject: [scap_interest] Operational Aspects
While we're all bantering about on security automation, there's another side to the story.  Are there any operational concerns we might address within a WG should one be formed?  For example, we have, in the United States, NVD hosting a repository of information.  CCE identifiers are moderated and assigned by an operational process.  As new enumerations are published and new types of content are conceived, it's easy to imagine the need for some operational standardization.
Should we consider standardizing some of these processes, and if so would the WG we seek to establish be the appropriate place for that work?
Regards,
Adam W. Montville | Security and Compliance Architect
Direct: 503 276-7661
Mobile: 360 471-7815
TRIPWIRE | Take CONTROL
http://www.tripwire.com
_______________________________________________
scap_interest mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scap_interest
_______________________________________________
scap_interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scap_interest

--_000_CB62A1172C9E8kentlandfieldmcafeecom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-family: 'Times New Roman', sans-serif; "><div><div><div>I see the topic of Content Repository interfaces as very important item that really should be worked here. &nbsp;We have been talking about this topic for over two years now as you both are aware. &nbsp;I am including the presentation that was given at SCAP Winter Developer Days last March that may help frame the issues. &nbsp;&nbsp;</div><div><br></div><div><div><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Kent Landfield</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Director Content Strategy, Architecture and Standards</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>McAfee | An Intel Company</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">5000 Headquarters Dr.</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Plano, Texas 75024</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Direct: &#43;1.972.963.7096&nbsp;</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Mobile: &#43;1.817.637.8026</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Web:&nbsp;</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><a href="http://www.mcafee.com/" style="color: rgb(96, 106, 113) !important; ">www.mcafee.com</a></span></div></div></div></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Luis Nunez &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Date: </span> Thu, 16 Feb 2012 11:54:21 -0600<br><span style="font-weight:bold">To: </span> Adam Montville &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Cc: </span> Kent  Landfield &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;, &quot;<a href="mailto:[email-masked]">[email-masked]</a>&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Subject: </span> Re: [scap_interest] Operational Aspects<br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div><div>Since you mentioned &quot;NVD&quot; also known as the National Vulnerability Database.&nbsp;&nbsp;I think at some point the IETF will be helpful in creating a protocol to communicate with these content repositories.&nbsp;&nbsp;Last I counted was 7 content repositories.</div><div>In no particular order and I am sure there are more out there.</div><div><br></div><div>-SecPod</div><div>-Novell</div><div>-NVD</div><div>-IT Security Database</div><div>-Debian </div><div>-Altx-soft</div><div><br></div><div>-ln</div><div><br></div><div>&nbsp;&nbsp;</div><div>On Feb 14, 2012, at 5:18 PM, Adam Montville wrote:</div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> Fair enough.&nbsp;&nbsp;Just throwing things against the wall as they come to mind.</div><div> </div><div> Adam</div><div> </div><div> From: kent_landfield &lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&gt;</div><div> Date: Tue, 14 Feb 2012 15:32:38 -0600</div><div> To: Adam Montville &lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&gt;, &lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&gt;</div><div> Subject: Re: [scap_interest] Operational Aspects</div><div> </div><div> Adam,</div><div> </div><div> We have more than enough on our plate with the specification / I-D work.&nbsp;&nbsp;Let's see if we can deal with this in a more appropriate forum. I do not see this as that forum.&nbsp;&nbsp;My 2cents�</div><div> </div><div> Thanks.</div><div> </div><div> Kent Landfield</div><div> Director Content Strategy, Architecture and Standards</div><div> </div><div> McAfee | An Intel Company</div><div> 5000 Headquarters Dr.</div><div> Plano, Texas 75024</div><div> </div><div> Direct: &#43;1.972.963.7096</div><div> Mobile: &#43;1.817.637.8026</div><div> Web: www.mcafee.com&lt;<a href="http://www.mcafee.com/">http://www.mcafee.com/</a>&gt;</div><div> </div><div> From: Adam Montville &lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&gt;</div><div> Date: Tue, 14 Feb 2012 15:12:51 -0600</div><div> To: &quot;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&gt;</div><div> Subject: [scap_interest] Operational Aspects</div><div> </div><div> While we're all bantering about on security automation, there's another side to the story.&nbsp;&nbsp;Are there any operational concerns we might address within a WG should one be formed?&nbsp;&nbsp;For example, we have, in the United States, NVD hosting a repository of information.&nbsp;&nbsp;CCE identifiers are moderated and assigned by an operational process.&nbsp;&nbsp;As new enumerations are published and new types of content are conceived, it's easy to imagine the need for some operational standardization.</div><div> </div><div> Should we consider standardizing some of these processes, and if so would the WG we seek to establish be the appropriate place for that work?</div><div> </div><div> Regards,</div><div> </div><div> Adam W. Montville | Security and Compliance Architect</div><div> </div><div> Direct: 503 276-7661</div><div> Mobile: 360 471-7815</div><div> </div><div> TRIPWIRE | Take CONTROL</div><div> <a href="http://www.tripwire.com">http://www.tripwire.com</a></div><div> </div><div> _______________________________________________</div><div> scap_interest mailing list</div><div> <a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]">mailto:[email-masked]</a>&gt;</div><div> <a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a></div><div> </div><div> </div><div> _______________________________________________</div><div> scap_interest mailing list</div><div> <a href="mailto:[email-masked]">[email-masked]</a></div><div> <a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a></div></blockquote><div><br></div><div><br></div></div></div></blockquote></span></body></html>

--_000_CB62A1172C9E8kentlandfieldmcafeecom_--

--_004_CB62A1172C9E8kentlandfieldmcafeecom_
Content-Type: application/zip; name="AutomationContentRepositories-v2.zip"
Content-Description: AutomationContentRepositories-v2.zip
Content-Disposition: attachment;
	filename="AutomationContentRepositories-v2.zip"; sizex5528;
	creation-date="Thu, 16 Feb 2012 18:46:33 GMT";
	modification-date="Thu, 16 Feb 2012 18:46:33 GMT"
Content-Transfer-Encoding: base64

--_004_CB62A1172C9E8kentlandfieldmcafeecom_--

From: <[email-masked]>
To: <[email-masked]>
Date: Thu, 16 Feb 2012 18:25:58 +0000
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

--_000_99BE1B4FCEBDFC418F584DAE5EA8577B0FC6ADAEF6EMV33UKDYdoma_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Interoperability testing/bake offs have long been useful in fully baking standards.  Frankly when I did some in the 90s with various IPSEC product vendors, we found that even little details could be mis-interpreted.  Simple things like little or big endian numbers in IP addresses would completely blow an interoperability test.  Ditto for different interpretations of key exchange steps, etc.  It took years to work out and took pushes by groups like ANX.

With that said, the IETF has never been in the business of certifying or validating products.  Most of those initiatives are either driven by vendors (usually pushed by their customers/service providers) or directly by customers (i.e. US Government or EU standards).  I would see that as a parallel effort to moving SCAP to an IETF standard.

Thanks,

Doug Taylor, CISSP
Bid Response Center, Security Solutions Designer
+1 972 830 8959 office
+1 214 683 4789 mobile

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, February 16, 2012 12:00 PM
To: [email-masked]
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

  Would IETF also take a role in validating products?

Validated SCAP products today does not mean interoperable products and that is part of the problem existing in the community today. We have fallen into a false sense that if a product have been validated, then it is interoperable with the other SCAP products.  That is not the case.  What occurs in the validation process is a certain set of functionality and features are checked.  The entire set of specifications have not been.  For example: over two years ago there was a section of FDCC content that caused serious problem with domain controllers and affected the network in general.  A vendor found the issue, investigated what was causing the problem and then fixed and tested the solution.  The tested fix was then sent to the FDCC content maintenance team to be corrected in the FDCC content.  Instead of fixing the problem, they disabled the checks because they could not make the fix available.  The reason?  Not all vendors that were SCAP Validated had implemented the needed tests required by the OVAL specifications to use the fix...   These were core tests... That said, the validation program is now going to be testing the specifications more completely which should help.  There is a place for product capability validation and I don't see that going away anytime soon but it still does not assure interoperability.

I have been discussing interoperability testing between vendors for a while now.  That is where you see if you have real compatible products.  In that case, I give you my content and you give me your results in consumable SCAP results formats and visa versa.  The IETF's history of bake offs and interop testing between products would be a real step in the right direction.  This would also encourage vendors to implement the complete specifications in their products instead of just what is needed to "pass the test".

Interoperability is the real goal if we are looking to lay a foundation of plug and play security automation capabilities...

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Sean Turner <[email-masked]<mailto:[email-masked]>>
Date: Thu, 16 Feb 2012 06:58:06 -0600
To: Adam Montville <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Michael Aharon Chernin <[email-masked]<mailto:[email-masked]>>, Kent Landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

(assuming there is a WG) It's mostly up to the WG.  There's still
IETF-wide, IESG and external party review of WG charters.

More inline below ...

spt

On 2/15/12 11:50 AM, Adam Montville wrote:
Hi David,

I think the answer to all three of your questions is really that it's all up to the working group.  The WG has an interest in ensuring interoperability, and standards are created based on running code.  USG may continue to require validation outside the context of the WG.  Finally, as the IETF is an open organization, participation from any organization, including USG, would be welcomed.

Adam

From:<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Date: Wed, 15 Feb 2012 10:42:34 -0600
To:<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>, kent_landfield<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>,<[email-masked]<mailto:[email-masked]><mailto:[email-masked]%3e%3e,[email-masked]%3cmailto:[email-masked]%3e>>
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

Hello all:

I also believe that SCAP can be used worlwide and should be marketted accordingly.
Maybe allowing IETF to endorse them is a good idea.

I just have a few questions.

1.  Would IETF also take a role in validating products?

Some lurking greybeards may correct me, but I can't think of a time when
the IETF validated products - but maybe that depends on what you mean.
I can think of many bake-offs/interop events and reports of such events
that listed product x, y, and z and whether they interoperated on tests
a, b, and c.  If by validation you're thinking a letter/certificate from
the IETF saying product x is compliant with RFC ####, then I think that
won't happen.

2.  What mechanisms does IETF provide that encourage the cooperation needed for incorporation future specifications?

An open, consensus driven standardization process would be my answer.
List are open to anyone and drafts/RFCs are available for free.

3.  How would IETF take into account the input of U.S. Federal agencies in future specifications?

On USG participation, all participants in the IETF (including those of
the USG or any other Gov't) participate as individuals.  They're free
(in fact encouraged) to bring in-scope proposals to the WG.  Assuming
there's a debate about a particular feature/option in their proposal,
I'd expect them to defend their proposal just like everybody else does.
  Rationale like "We're the USG and you shalt do it this way" isn't
going to fly.  Rough consensus will rule the day.

David Oliva

On 02/15/12, Chernin, Michael A.<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>  wrote:

Kent, understood. Like the vendors, I do agree that certain standards need to go to IETF. But, today the only people that would be voting during IETF calls would be the federal government and security tool vendors. I am going to be hesitant in supporting a move of all standards until there are standards consumers (private sector customers) who will also be participating in IETF voting. I am trying to balance rapid development of standards using the IETF and complete vendor control of all standards. Once I see more consumer activity during voting, I will be more supportive of a large number of standards moving IETF.

I know I am early and jumping the gun on this, but I just wanted to get my story out there. At this time no standards have been specifically identified and no specific action is required at this time.

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust&  Clearing Corporation
O: 813-470-2173

From: [email-masked]<mailto:[email-masked]><mailto:[email-masked]>  [mailto:[email-masked]]
Sent: Tuesday, February 14, 2012 6:09 PM
To: Chernin, Michael A.; [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

>From my perspective TBD.

There are some that are unencumbered from and IPR perspective and those are potential candidates. Others will have to move as the appropriate consensus  is achieved and IPR issues are addressed.

The idea here from my perspective is to figure that out.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Michael Aharon Chernin<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Date: Tue, 14 Feb 2012 16:04:43 -0600
To: "[email-masked]<mailto:[email-masked]><mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]><mailto:[email-masked][email-masked]%3cmailto:[email-masked]%3e>>
Subject: [scap_interest] Scope of standards potentially moving to IETF

I am just going to jump right on out there and ask. Which standards are we looking to go to IETF? Specific SCAP standards or the entire SCAP umbrella?

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust&  Clearing Corporation
O: 813-470-2173

<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>
_______________________________________________
scap_interest mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scap_interest

________________________________

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

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

--_000_99BE1B4FCEBDFC418F584DAE5EA8577B0FC6ADAEF6EMV33UKDYdoma_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap: break-word;-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Interoperability testing/bake offs have long been useful in fully baking standards.&nbsp; Frankly when I did some in the 90s with various IPSEC product vendors, we found that even little details could be mis-interpreted.&nbsp; Simple things like little or big endian numbers in IP addresses would completely blow an interoperability test.&nbsp; Ditto for different interpretations of key exchange steps, etc.&nbsp; It took years to work out and took pushes by groups like ANX.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>With that said, the IETF has never been in the business of certifying or validating products.&nbsp; Most of those initiatives are either driven by vendors (usually pushed by their customers/service providers) or directly by customers (i.e. US Government or EU standards).&nbsp; I would see that as a parallel effort to moving SCAP to an IETF standard.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Doug Taylor, CISSP<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Bid Response Center, Security Solutions Designer<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>+1 972 830 8959 office<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>+1 214 683 4789 mobile<o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> [email-masked] [mailto:[email-masked]] <b>On Behalf Of </b>[email-masked]<br><b>Sent:</b> Thursday, February 16, 2012 12:00 PM<br><b>To:</b> [email-masked]<br><b>Subject:</b> Re: [scap_interest] Scope of standards potentially moving to IETF<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><div><div><div><blockquote style='border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in'><div><p class=MsoNormal><span style='color:black'>&nbsp; Would IETF also take a role in validating products?<o:p></o:p></span></p></div></blockquote><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div></div><div><p class=MsoNormal><span style='color:black'>Validated SCAP products today does not mean interoperable products and that is part of the problem existing in the community today. We have fallen into a false sense that if a product have been validated, then it is interoperable with the other SCAP products. &nbsp;That is not the case. &nbsp;What occurs in the validation process is a certain set of functionality and features are checked. &nbsp;The entire set of specifications have not been. &nbsp;For example: over two years ago there was a section of FDCC content that caused serious problem with domain controllers and affected the network in general. &nbsp;A vendor found the issue, investigated what was causing the problem and then fixed and tested the solution. &nbsp;The tested fix was then sent to the FDCC content maintenance team to be corrected in the FDCC content. &nbsp;Instead of fixing the problem, they disabled the checks because they could not make the fix available. &nbsp;The reason? &nbsp;Not all vendors that were SCAP Validated had implemented the needed tests required by the OVAL specifications to use the fix&#8230; &nbsp; These were core tests&#8230; That said, the validation program is now going to be testing the specifications more completely which should help. &nbsp;There is a place for product capability validation and I don't see that going away anytime soon but it still does not assure interoperability.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>I have been discussing interoperability testing between vendors for a while now. &nbsp;That is where you see if you have real compatible products. &nbsp;In that case, I give you my content and you give me your results in consumable SCAP results formats and visa versa. &nbsp;The IETF's history of bake offs and interop testing between products would be a real step in the right direction. &nbsp;This would also encourage vendors to implement the complete specifications in their products instead of just what is needed to &quot;pass the test&quot;.&nbsp;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Interoperability is the real goal if we are looking to lay a foundation of plug and play security automation capabilities&#8230;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><div><p class=MsoNormal><strong><span style='font-size:9.0pt;font-family:"Arial","sans-serif";color:#606A71'>Kent Landfield</span></strong><span style='font-size:9.0pt;font-family:"Arial","sans-serif";color:#606A71'><br><span class=apple-style-span>Director Content Strategy, Architecture and Standards</span><br><br><strong><span style='font-family:"Arial","sans-serif"'>McAfee | An Intel Company</span></strong><br><span class=apple-style-span>5000 Headquarters Dr.</span><br><span class=apple-style-span>Plano, Texas 75024</span><br><br><span class=apple-style-span>Direct: +1.972.963.7096&nbsp;</span><br><span class=apple-style-span>Mobile: +1.817.637.8026</span><br><strong><span style='font-family:"Arial","sans-serif"'>Web:&nbsp;</span></strong><span class=apple-style-span><a href="http://www.mcafee.com/">www.mcafee.com</a></span></span><span style='color:black'><o:p></o:p></span></p></div></div></div></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>From: </span></b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Sean Turner &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><b>Date: </b>Thu, 16 Feb 2012 06:58:06 -0600<br><b>To: </b>Adam Montville &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;, &quot;<a href="mailto:[email-masked]">[email-masked]</a>&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><b>Cc: </b>Michael Aharon Chernin &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;, Kent Landfield &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;, &quot;<a href="mailto:[email-masked]">[email-masked]</a>&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><b>Subject: </b>Re: [scap_interest] Scope of standards potentially moving to IETF<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><blockquote style='border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><div><div><p class=MsoNormal><span style='color:black'>(assuming there is a WG) It's mostly up to the WG.&nbsp;&nbsp;There's still <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>IETF-wide, IESG and external party review of WG charters.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>More inline below ...<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>spt<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>On 2/15/12 11:50 AM, Adam Montville wrote:<o:p></o:p></span></p></div><blockquote style='border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><p class=MsoNormal><span style='color:black'>Hi David,<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>I think the answer to all three of your questions is really that it's all up to the working group.&nbsp;&nbsp;The WG has an interest in ensuring interoperability, and standards are created based on running code.&nbsp;&nbsp;USG may continue to require validation outside the context of the WG.&nbsp;&nbsp;Finally, as the IETF is an open organization, participation from any organization, including USG, would be welcomed.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Adam<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>From:&lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]%3e">mailto:[email-masked]&gt;</a>&gt;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Date: Wed, 15 Feb 2012 10:42:34 -0600<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>To:&lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]%3e">mailto:[email-masked]&gt;</a>&gt;, kent_landfield&lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]%3e%3e,[email-masked]%3cmailto:[email-masked]%3e">mailto:[email-masked]&gt;&gt;,&lt;[email-masked]&lt;mailto:[email-masked]&gt;</a>&gt;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Subject: Re: [scap_interest] Scope of standards potentially moving to IETF<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Hello all:<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>I also believe that SCAP can be used worlwide and should be marketted accordingly.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Maybe allowing IETF to endorse them is a good idea.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>I just have a few questions.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>1.&nbsp;&nbsp;Would IETF also take a role in validating products?<o:p></o:p></span></p></div></blockquote><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Some lurking greybeards may correct me, but I can't think of a time when <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>the IETF validated products - but maybe that depends on what you mean. <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>I can think of many bake-offs/interop events and reports of such events <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>that listed product x, y, and z and whether they interoperated on tests <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>a, b, and c.&nbsp;&nbsp;If by validation you're thinking a letter/certificate from <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>the IETF saying product x is compliant with RFC ####, then I think that <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>won't happen.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><blockquote style='border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><p class=MsoNormal><span style='color:black'>2.&nbsp;&nbsp;What mechanisms does IETF provide that encourage the cooperation needed for incorporation future specifications?<o:p></o:p></span></p></div></blockquote><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>An open, consensus driven standardization process would be my answer. <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>List are open to anyone and drafts/RFCs are available for free.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><blockquote style='border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><p class=MsoNormal><span style='color:black'>3.&nbsp;&nbsp;How would IETF take into account the input of U.S. Federal agencies in future specifications?<o:p></o:p></span></p></div></blockquote><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>On USG participation, all participants in the IETF (including those of <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>the USG or any other Gov't) participate as individuals.&nbsp;&nbsp;They're free <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>(in fact encouraged) to bring in-scope proposals to the WG.&nbsp;&nbsp;Assuming <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>there's a debate about a particular feature/option in their proposal, <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>I'd expect them to defend their proposal just like everybody else does. <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>&nbsp;&nbsp;Rationale like &quot;We're the USG and you shalt do it this way&quot; isn't <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>going to fly.&nbsp;&nbsp;Rough consensus will rule the day.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><blockquote style='border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><p class=MsoNormal><span style='color:black'>David Oliva<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>On 02/15/12, Chernin, Michael A.&lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]%3e">mailto:[email-masked]&gt;</a>&gt;&nbsp;&nbsp;wrote:<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Kent, understood. Like the vendors, I do agree that certain standards need to go to IETF. But, today the only people that would be voting during IETF calls would be the federal government and security tool vendors. I am going to be hesitant in supporting a move of all standards until there are standards consumers (private sector customers) who will also be participating in IETF voting. I am trying to balance rapid development of standards using the IETF and complete vendor control of all standards. Once I see more consumer activity during voting, I will be more supportive of a large number of standards moving IETF.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>I know I am early and jumping the gun on this, but I just wanted to get my story out there. At this time no standards have been specifically identified and no specific action is required at this time.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Aharon<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>DTCC Non-Confidential (White)<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>---------------------------------------------------<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Michael &quot;Aharon&quot; Chernin<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Security Automation Program Manager<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Corporate Information Security -Depository Trust&amp;&nbsp;&nbsp;Clearing Corporation<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>O: 813-470-2173<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>From: <a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]">mailto:[email-masked]</a>&gt;&nbsp;&nbsp;[<a href="mailto:[email-masked]">mailto:[email-masked]</a>]<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Sent: Tuesday, February 14, 2012 6:09 PM<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>To: Chernin, Michael A.; <a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]">mailto:[email-masked]</a>&gt;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Subject: Re: [scap_interest] Scope of standards potentially moving to IETF<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><blockquote style='border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><p class=MsoNormal><span style='color:black'>From my perspective TBD.<o:p></o:p></span></p></div></blockquote><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>There are some that are unencumbered from and IPR perspective and those are potential candidates. Others will have to move as the appropriate consensus&nbsp;&nbsp;is achieved and IPR issues are addressed.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>The idea here from my perspective is to figure that out.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Kent Landfield<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Director Content Strategy, Architecture and Standards<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>McAfee | An Intel Company<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>5000 Headquarters Dr.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Plano, Texas 75024<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Direct: +1.972.963.7096<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Mobile: +1.817.637.8026<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Web: www.mcafee.com&lt;<a href="http://www.mcafee.com/">http://www.mcafee.com/</a>&gt;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>From: Michael Aharon Chernin&lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]%3e">mailto:[email-masked]&gt;</a>&gt;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Date: Tue, 14 Feb 2012 16:04:43 -0600<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>To: &quot;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked][email-masked]%3cmailto:[email-masked]%3e">mailto:[email-masked]&gt;&quot;&lt;[email-masked]&lt;mailto:[email-masked]&gt;</a>&gt;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Subject: [scap_interest] Scope of standards potentially moving to IETF<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>I am just going to jump right on out there and ask. Which standards are we looking to go to IETF? Specific SCAP standards or the entire SCAP umbrella?<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Aharon<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>DTCC Non-Confidential (White)<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>---------------------------------------------------<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Michael &quot;Aharon&quot; Chernin<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Security Automation Program Manager<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>Corporate Information Security -Depository Trust&amp;&nbsp;&nbsp;Clearing Corporation<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>O: 813-470-2173<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>&lt;BR&gt;_____________________________________________________________<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>&lt;FONT size=2&gt;&lt;BR&gt;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>DTCC DISCLAIMER: This email and any files transmitted with it are<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>confidential and intended solely for the use of the individual or<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>entity to whom they are addressed. If you have received this email<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>in error, please notify us immediately and delete the email and any<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>attachments from your system. The recipient should check this email<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>and any attachments for the presence of viruses.&nbsp;&nbsp;The company<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>accepts no liability for any damage caused by any virus transmitted<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>by this email.&lt;/FONT&gt;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>_______________________________________________<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>scap_interest mailing list<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]">mailto:[email-masked]</a>&gt;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>________________________________<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>_______________________________________________<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>scap_interest mailing list<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]">mailto:[email-masked]</a>&gt;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>_______________________________________________ scap_interest mailing list <a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]">mailto:[email-masked]</a>&gt;&nbsp;&nbsp;<a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>_______________________________________________<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>scap_interest mailing list<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><a href="mailto:[email-masked]">[email-masked]</a><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div></blockquote><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div></div></div></blockquote></div></body></html>
--_000_99BE1B4FCEBDFC418F584DAE5EA8577B0FC6ADAEF6EMV33UKDYdoma_--

Date: Thu, 16 Feb 2012 13:14:45 -0500
From: Gunnar Engelbach <[email-masked]>
Organization: ThreatGuard, Inc.
To: [email-masked]
Subject: Re: [scap_interest] Operational Aspects

That's an addition well worth pursuing further.  What jumps out 
immediately to me as a prerequisite is the need to be able to validate 
the authenticity of a benchmark -- that lingering benchmark signing issue.

I would also suggest considering including client validation as part of 
such a protocol.  That could easily be considered outside the scope of 
this, but some of these repositories are commercial, something I'd be 
happy to see more of, so I'd like to see a standardized method for 
validating client access.

A bit early to be going into detail on anything, but I think there are 
two things that could apply multiple places and thus should be fleshed 
out early on.

--gun

On 2/16/2012 12:54 PM, Luis Nunez wrote:
> Since you mentioned "NVD" also known as the National Vulnerability Database.  I think at some point the IETF will be helpful in creating a protocol to communicate with these content repositories.  Last I counted was 7 content repositories.
> In no particular order and I am sure there are more out there.
>
> -SecPod
> -Novell
> -NVD
> -IT Security Database
> -Debian
> -Altx-soft
>
> -ln
>
>
> On Feb 14, 2012, at 5:18 PM, Adam Montville wrote:
>
>> Fair enough.  Just throwing things against the wall as they come to mind.
>>
>> Adam
>>
>> From: kent_landfield<[email-masked]<mailto:[email-masked]>>
>> Date: Tue, 14 Feb 2012 15:32:38 -0600
>> To: Adam Montville<[email-masked]<mailto:[email-masked]>>,<[email-masked]<mailto:[email-masked]>>
>> Subject: Re: [scap_interest] Operational Aspects
>>
>> Adam,
>>
>> We have more than enough on our plate with the specification / I-D work.  Let's see if we can deal with this in a more appropriate forum. I do not see this as that forum.  My 2cents�
>>
>> Thanks.
>>
>> Kent Landfield
>> Director Content Strategy, Architecture and Standards
>>
>> McAfee | An Intel Company
>> 5000 Headquarters Dr.
>> Plano, Texas 75024
>>
>> Direct: +1.972.963.7096
>> Mobile: +1.817.637.8026
>> Web: www.mcafee.com<http://www.mcafee.com/>
>>
>> From: Adam Montville<[email-masked]<mailto:[email-masked]>>
>> Date: Tue, 14 Feb 2012 15:12:51 -0600
>> To: "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>
>> Subject: [scap_interest] Operational Aspects
>>
>> While we're all bantering about on security automation, there's another side to the story.  Are there any operational concerns we might address within a WG should one be formed?  For example, we have, in the United States, NVD hosting a repository of information.  CCE identifiers are moderated and assigned by an operational process.  As new enumerations are published and new types of content are conceived, it's easy to imagine the need for some operational standardization.
>>
>> Should we consider standardizing some of these processes, and if so would the WG we seek to establish be the appropriate place for that work?
>>
>> Regards,
>>
>> Adam W. Montville | Security and Compliance Architect
>>
>> Direct: 503 276-7661
>> Mobile: 360 471-7815
>>
>> TRIPWIRE | Take CONTROL
>> http://www.tripwire.com
>>
>> _______________________________________________
>> scap_interest mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/scap_interest
>>
>>
>> _______________________________________________
>> scap_interest mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/scap_interest
>
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest

From: <[email-masked]>
To: <[email-masked]>
Date: Thu, 16 Feb 2012 11:59:49 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

--_000_CB6299732C9A5kentlandfieldmcafeecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

  Would IETF also take a role in validating products?

Validated SCAP products today does not mean interoperable products and that is part of the problem existing in the community today. We have fallen into a false sense that if a product have been validated, then it is interoperable with the other SCAP products.  That is not the case.  What occurs in the validation process is a certain set of functionality and features are checked.  The entire set of specifications have not been.  For example: over two years ago there was a section of FDCC content that caused serious problem with domain controllers and affected the network in general.  A vendor found the issue, investigated what was causing the problem and then fixed and tested the solution.  The tested fix was then sent to the FDCC content maintenance team to be corrected in the FDCC content.  Instead of fixing the problem, they disabled the checks because they could not make the fix available.  The reason?  Not all vendors that were SCAP Validated had implemented the needed tests required by the OVAL specifications to use the fix�   These were core tests� That said, the validation program is now going to be testing the specifications more completely which should help.  There is a place for product capability validation and I don't see that going away anytime soon but it still does not assure interoperability.

I have been discussing interoperability testing between vendors for a while now.  That is where you see if you have real compatible products.  In that case, I give you my content and you give me your results in consumable SCAP results formats and visa versa.  The IETF's history of bake offs and interop testing between products would be a real step in the right direction.  This would also encourage vendors to implement the complete specifications in their products instead of just what is needed to "pass the test".

Interoperability is the real goal if we are looking to lay a foundation of plug and play security automation capabilities�

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Sean Turner <[email-masked]<mailto:[email-masked]>>
Date: Thu, 16 Feb 2012 06:58:06 -0600
To: Adam Montville <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Michael Aharon Chernin <[email-masked]<mailto:[email-masked]>>, Kent Landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

(assuming there is a WG) It's mostly up to the WG.  There's still
IETF-wide, IESG and external party review of WG charters.

More inline below ...

spt

On 2/15/12 11:50 AM, Adam Montville wrote:
Hi David,

I think the answer to all three of your questions is really that it's all up to the working group.  The WG has an interest in ensuring interoperability, and standards are created based on running code.  USG may continue to require validation outside the context of the WG.  Finally, as the IETF is an open organization, participation from any organization, including USG, would be welcomed.

Adam

From:<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Date: Wed, 15 Feb 2012 10:42:34 -0600
To:<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>, kent_landfield<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>,<[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

Hello all:

I also believe that SCAP can be used worlwide and should be marketted accordingly.
Maybe allowing IETF to endorse them is a good idea.

I just have a few questions.

1.  Would IETF also take a role in validating products?

Some lurking greybeards may correct me, but I can't think of a time when
the IETF validated products - but maybe that depends on what you mean.
I can think of many bake-offs/interop events and reports of such events
that listed product x, y, and z and whether they interoperated on tests
a, b, and c.  If by validation you're thinking a letter/certificate from
the IETF saying product x is compliant with RFC ####, then I think that
won't happen.

2.  What mechanisms does IETF provide that encourage the cooperation needed for incorporation future specifications?

An open, consensus driven standardization process would be my answer.
List are open to anyone and drafts/RFCs are available for free.

3.  How would IETF take into account the input of U.S. Federal agencies in future specifications?

On USG participation, all participants in the IETF (including those of
the USG or any other Gov't) participate as individuals.  They're free
(in fact encouraged) to bring in-scope proposals to the WG.  Assuming
there's a debate about a particular feature/option in their proposal,
I'd expect them to defend their proposal just like everybody else does.
  Rationale like "We're the USG and you shalt do it this way" isn't
going to fly.  Rough consensus will rule the day.

David Oliva

On 02/15/12, Chernin, Michael A.<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>  wrote:

Kent, understood. Like the vendors, I do agree that certain standards need to go to IETF. But, today the only people that would be voting during IETF calls would be the federal government and security tool vendors. I am going to be hesitant in supporting a move of all standards until there are standards consumers (private sector customers) who will also be participating in IETF voting. I am trying to balance rapid development of standards using the IETF and complete vendor control of all standards. Once I see more consumer activity during voting, I will be more supportive of a large number of standards moving IETF.

I know I am early and jumping the gun on this, but I just wanted to get my story out there. At this time no standards have been specifically identified and no specific action is required at this time.

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust&  Clearing Corporation
O: 813-470-2173

From: [email-masked]<mailto:[email-masked]><mailto:[email-masked]>  [mailto:[email-masked]]
Sent: Tuesday, February 14, 2012 6:09 PM
To: Chernin, Michael A.; [email-masked]<mailto:[email-masked]><mailto:[email-masked]>
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

>From my perspective TBD.

There are some that are unencumbered from and IPR perspective and those are potential candidates. Others will have to move as the appropriate consensus  is achieved and IPR issues are addressed.

The idea here from my perspective is to figure that out.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Michael Aharon Chernin<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 16:04:43 -0600
To: "[email-masked]<mailto:[email-masked]><mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>
Subject: [scap_interest] Scope of standards potentially moving to IETF

I am just going to jump right on out there and ask. Which standards are we looking to go to IETF? Specific SCAP standards or the entire SCAP umbrella?

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust&  Clearing Corporation
O: 813-470-2173

<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>
_______________________________________________
scap_interest mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scap_interest

________________________________

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

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

--_000_CB6299732C9A5kentlandfieldmcafeecom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-family: 'Times New Roman', sans-serif; "><div><div><div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="border-left-color: rgb(181, 196, 223); border-left-width: 5px; border-left-style: solid; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 5px; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 5px; "><div>&nbsp; Would IETF also take a role in validating products?</div></blockquote><div><br></div></div><div>Validated SCAP products today does not mean interoperable products and that is part of the problem existing in the community today. We have fallen into a false sense that if a product have been validated, then it is interoperable with the other SCAP products. &nbsp;That is not the case. &nbsp;What occurs in the validation process is a certain set of functionality and features are checked. &nbsp;The entire set of specifications have not been. &nbsp;For example: over two years ago there was a section of FDCC content that caused serious problem with domain controllers and affected the network in general. &nbsp;A vendor found the issue, investigated what was causing the problem and then fixed and tested the solution. &nbsp;The tested fix was then sent to the FDCC content maintenance team to be corrected in the FDCC content. &nbsp;Instead of fixing the problem, they disabled the checks because they could not make the fix available. &nbsp;The reason? &nbsp;Not all vendors that were SCAP Validated had implemented the needed tests required by the OVAL specifications to use the fix� &nbsp; These were core tests� That said, the validation program is now going to be testing the specifications more completely which should help. &nbsp;There is a place for product capability validation and I don't see that going away anytime soon but it still does not assure interoperability.</div><div><br></div><div>I have been discussing interoperability testing between vendors for a while now. &nbsp;That is where you see if you have real compatible products. &nbsp;In that case, I give you my content and you give me your results in consumable SCAP results formats and visa versa. &nbsp;The IETF's history of bake offs and interop testing between products would be a real step in the right direction. &nbsp;This would also encourage vendors to implement the complete specifications in their products instead of just what is needed to &quot;pass the test&quot;.&nbsp;</div><div><br></div><div>Interoperability is the real goal if we are looking to lay a foundation of plug and play security automation capabilities�</div><div><br></div><div><div><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Kent Landfield</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Director Content Strategy, Architecture and Standards</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>McAfee | An Intel Company</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">5000 Headquarters Dr.</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Plano, Texas 75024</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Direct: &#43;1.972.963.7096&nbsp;</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Mobile: &#43;1.817.637.8026</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Web:&nbsp;</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><a href="http://www.mcafee.com/" style="color: rgb(96, 106, 113) !important; ">www.mcafee.com</a></span></div></div></div></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Sean Turner &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Date: </span> Thu, 16 Feb 2012 06:58:06 -0600<br><span style="font-weight:bold">To: </span> Adam Montville &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;, &quot;<a href="mailto:[email-masked]">[email-masked]</a>&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Cc: </span> Michael Aharon Chernin &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;, Kent  Landfield &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;, &quot;<a href="mailto:[email-masked]">[email-masked]</a>&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Subject: </span> Re: [scap_interest] Scope of standards potentially moving to IETF<br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div><div>(assuming there is a WG) It's mostly up to the WG.&nbsp;&nbsp;There's still </div><div>IETF-wide, IESG and external party review of WG charters.</div><div><br></div><div>More inline below ...</div><div><br></div><div>spt</div><div><br></div><div>On 2/15/12 11:50 AM, Adam Montville wrote:</div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> Hi David,</div><div><br></div><div> I think the answer to all three of your questions is really that it's all up to the working group.&nbsp;&nbsp;The WG has an interest in ensuring interoperability, and standards are created based on running code.&nbsp;&nbsp;USG may continue to require validation outside the context of the WG.&nbsp;&nbsp;Finally, as the IETF is an open organization, participation from any organization, including USG, would be welcomed.</div><div><br></div><div> Adam</div><div><br></div><div> From:&lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&gt;</div><div> Date: Wed, 15 Feb 2012 10:42:34 -0600</div><div> To:&lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&gt;, kent_landfield&lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;&gt;,&lt;[email-masked]&lt;mailto:[email-masked]&gt;">mailto:[email-masked]&gt;&gt;,&lt;[email-masked]&lt;mailto:[email-masked]&gt;</a>&gt;</div><div> Subject: Re: [scap_interest] Scope of standards potentially moving to IETF</div><div><br></div><div> Hello all:</div><div><br></div><div> I also believe that SCAP can be used worlwide and should be marketted accordingly.</div><div> Maybe allowing IETF to endorse them is a good idea.</div><div><br></div><div> I just have a few questions.</div><div><br></div><div> 1.&nbsp;&nbsp;Would IETF also take a role in validating products?</div></blockquote><div><br></div><div>Some lurking greybeards may correct me, but I can't think of a time when </div><div>the IETF validated products - but maybe that depends on what you mean. </div><div>I can think of many bake-offs/interop events and reports of such events </div><div>that listed product x, y, and z and whether they interoperated on tests </div><div>a, b, and c.&nbsp;&nbsp;If by validation you're thinking a letter/certificate from </div><div>the IETF saying product x is compliant with RFC ####, then I think that </div><div>won't happen.</div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> 2.&nbsp;&nbsp;What mechanisms does IETF provide that encourage the cooperation needed for incorporation future specifications?</div></blockquote><div><br></div><div>An open, consensus driven standardization process would be my answer. </div><div>List are open to anyone and drafts/RFCs are available for free.</div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> 3.&nbsp;&nbsp;How would IETF take into account the input of U.S. Federal agencies in future specifications?</div></blockquote><div><br></div><div>On USG participation, all participants in the IETF (including those of </div><div>the USG or any other Gov't) participate as individuals.&nbsp;&nbsp;They're free </div><div>(in fact encouraged) to bring in-scope proposals to the WG.&nbsp;&nbsp;Assuming </div><div>there's a debate about a particular feature/option in their proposal, </div><div>I'd expect them to defend their proposal just like everybody else does. </div><div>&nbsp;&nbsp;Rationale like &quot;We're the USG and you shalt do it this way&quot; isn't </div><div>going to fly.&nbsp;&nbsp;Rough consensus will rule the day.</div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> David Oliva</div><div><br></div><div> On 02/15/12, Chernin, Michael A.&lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&gt;&nbsp;&nbsp;wrote:</div><div><br></div><div> Kent, understood. Like the vendors, I do agree that certain standards need to go to IETF. But, today the only people that would be voting during IETF calls would be the federal government and security tool vendors. I am going to be hesitant in supporting a move of all standards until there are standards consumers (private sector customers) who will also be participating in IETF voting. I am trying to balance rapid development of standards using the IETF and complete vendor control of all standards. Once I see more consumer activity during voting, I will be more supportive of a large number of standards moving IETF.</div><div><br></div><div> I know I am early and jumping the gun on this, but I just wanted to get my story out there. At this time no standards have been specifically identified and no specific action is required at this time.</div><div><br></div><div> Aharon</div><div><br></div><div> DTCC Non-Confidential (White)</div><div> ---------------------------------------------------</div><div> Michael &quot;Aharon&quot; Chernin</div><div> Security Automation Program Manager</div><div> Corporate Information Security -Depository Trust&amp;&nbsp;&nbsp;Clearing Corporation</div><div> O: 813-470-2173</div><div><br></div><div> From: <a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]">mailto:[email-masked]</a>&gt;&nbsp;&nbsp;[<a href="mailto:[email-masked]">mailto:[email-masked]</a>]</div><div> Sent: Tuesday, February 14, 2012 6:09 PM</div><div> To: Chernin, Michael A.; <a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]">mailto:[email-masked]</a>&gt;</div><div> Subject: Re: [scap_interest] Scope of standards potentially moving to IETF</div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> From my perspective TBD.</div></blockquote><div><br></div><div> There are some that are unencumbered from and IPR perspective and those are potential candidates. Others will have to move as the appropriate consensus&nbsp;&nbsp;is achieved and IPR issues are addressed.</div><div><br></div><div> The idea here from my perspective is to figure that out.</div><div><br></div><div> Kent Landfield</div><div> Director Content Strategy, Architecture and Standards</div><div><br></div><div> McAfee | An Intel Company</div><div> 5000 Headquarters Dr.</div><div> Plano, Texas 75024</div><div><br></div><div> Direct: &#43;1.972.963.7096</div><div> Mobile: &#43;1.817.637.8026</div><div> Web: www.mcafee.com&lt;<a href="http://www.mcafee.com/">http://www.mcafee.com/</a>&gt;</div><div><br></div><div> From: Michael Aharon Chernin&lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&gt;</div><div> Date: Tue, 14 Feb 2012 16:04:43 -0600</div><div> To: &quot;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;&quot;&lt;[email-masked]&lt;mailto:[email-masked]&gt;">mailto:[email-masked]&gt;&quot;&lt;[email-masked]&lt;mailto:[email-masked]&gt;</a>&gt;</div><div> Subject: [scap_interest] Scope of standards potentially moving to IETF</div><div><br></div><div> I am just going to jump right on out there and ask. Which standards are we looking to go to IETF? Specific SCAP standards or the entire SCAP umbrella?</div><div><br></div><div> Aharon</div><div><br></div><div> DTCC Non-Confidential (White)</div><div> ---------------------------------------------------</div><div> Michael &quot;Aharon&quot; Chernin</div><div> Security Automation Program Manager</div><div> Corporate Information Security -Depository Trust&amp;&nbsp;&nbsp;Clearing Corporation</div><div> O: 813-470-2173</div><div><br></div><div> &lt;BR&gt;_____________________________________________________________</div><div> &lt;FONT size=2&gt;&lt;BR&gt;</div><div> DTCC DISCLAIMER: This email and any files transmitted with it are</div><div> confidential and intended solely for the use of the individual or</div><div> entity to whom they are addressed. If you have received this email</div><div> in error, please notify us immediately and delete the email and any</div><div> attachments from your system. The recipient should check this email</div><div> and any attachments for the presence of viruses.&nbsp;&nbsp;The company</div><div> accepts no liability for any damage caused by any virus transmitted</div><div> by this email.&lt;/FONT&gt;</div><div> _______________________________________________</div><div> scap_interest mailing list</div><div> <a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]">mailto:[email-masked]</a>&gt;</div><div> <a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a></div><div><br></div><div><br></div><div> ________________________________</div><div><br></div><div> _______________________________________________</div><div> scap_interest mailing list</div><div> <a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]">mailto:[email-masked]</a>&gt;</div><div> <a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a></div><div> _______________________________________________ scap_interest mailing list <a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]">mailto:[email-masked]</a>&gt;&nbsp;&nbsp;<a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a></div><div><br></div><div> _______________________________________________</div><div> scap_interest mailing list</div><div> <a href="mailto:[email-masked]">[email-masked]</a></div><div> <a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a></div><div><br></div></blockquote><div><br></div></div></div></blockquote></span></body></html>

--_000_CB6299732C9A5kentlandfieldmcafeecom_--

From: Adam Montville <[email-masked]>
To: Luis Nunez <[email-masked]>
Date: Thu, 16 Feb 2012 17:56:22 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Operational Aspects

Red Hat might have one for their systems as well.

Also, I think that continuous monitoring has an important role to play
here with their content repository interface specifications.

Adam

On 2/16/12 9:54 AM, "Luis Nunez" <[email-masked]> wrote:

>Since you mentioned "NVD" also known as the National Vulnerability
>Database.  I think at some point the IETF will be helpful in creating a
>protocol to communicate with these content repositories.  Last I counted
>was 7 content repositories.
>In no particular order and I am sure there are more out there.
>
>-SecPod
>-Novell
>-NVD
>-IT Security Database
>-Debian 
>-Altx-soft
>
>-ln
>
>  
>On Feb 14, 2012, at 5:18 PM, Adam Montville wrote:
>
>> Fair enough.  Just throwing things against the wall as they come to
>>mind.
>> 
>> Adam
>> 
>> From: kent_landfield
>><[email-masked]<mailto:[email-masked]>>
>> Date: Tue, 14 Feb 2012 15:32:38 -0600
>> To: Adam Montville
>><[email-masked]<mailto:[email-masked]>>,
>><[email-masked]<mailto:[email-masked]>>
>> Subject: Re: [scap_interest] Operational Aspects
>> 
>> Adam,
>> 
>> We have more than enough on our plate with the specification / I-D
>>work.  Let's see if we can deal with this in a more appropriate forum. I
>>do not see this as that forum.  My 2cents�
>> 
>> Thanks.
>> 
>> Kent Landfield
>> Director Content Strategy, Architecture and Standards
>> 
>> McAfee | An Intel Company
>> 5000 Headquarters Dr.
>> Plano, Texas 75024
>> 
>> Direct: +1.972.963.7096
>> Mobile: +1.817.637.8026
>> Web: www.mcafee.com<http://www.mcafee.com/>
>> 
>> From: Adam Montville
>><[email-masked]<mailto:[email-masked]>>
>> Date: Tue, 14 Feb 2012 15:12:51 -0600
>> To: "[email-masked]<mailto:[email-masked]>"
>><[email-masked]<mailto:[email-masked]>>
>> Subject: [scap_interest] Operational Aspects
>> 
>> While we're all bantering about on security automation, there's another
>>side to the story.  Are there any operational concerns we might address
>>within a WG should one be formed?  For example, we have, in the United
>>States, NVD hosting a repository of information.  CCE identifiers are
>>moderated and assigned by an operational process.  As new enumerations
>>are published and new types of content are conceived, it's easy to
>>imagine the need for some operational standardization.
>> 
>> Should we consider standardizing some of these processes, and if so
>>would the WG we seek to establish be the appropriate place for that work?
>> 
>> Regards,
>> 
>> Adam W. Montville | Security and Compliance Architect
>> 
>> Direct: 503 276-7661
>> Mobile: 360 471-7815
>> 
>> TRIPWIRE | Take CONTROL
>> http://www.tripwire.com
>> 
>> _______________________________________________
>> scap_interest mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/scap_interest
>> 
>> 
>> _______________________________________________
>> scap_interest mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/scap_interest
>
>

From: Luis Nunez <[email-masked]>
Date: Thu, 16 Feb 2012 12:54:21 -0500
To: Adam Montville <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Operational Aspects

Since you mentioned "NVD" also known as the National Vulnerability Database.  I think at some point the IETF will be helpful in creating a protocol to communicate with these content repositories.  Last I counted was 7 content repositories.
In no particular order and I am sure there are more out there.

-SecPod
-Novell
-NVD
-IT Security Database
-Debian 
-Altx-soft

-ln

On Feb 14, 2012, at 5:18 PM, Adam Montville wrote:

> Fair enough.  Just throwing things against the wall as they come to mind.
> 
> Adam
> 
> From: kent_landfield <[email-masked]<mailto:[email-masked]>>
> Date: Tue, 14 Feb 2012 15:32:38 -0600
> To: Adam Montville <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
> Subject: Re: [scap_interest] Operational Aspects
> 
> Adam,
> 
> We have more than enough on our plate with the specification / I-D work.  Let's see if we can deal with this in a more appropriate forum. I do not see this as that forum.  My 2cents�
> 
> Thanks.
> 
> Kent Landfield
> Director Content Strategy, Architecture and Standards
> 
> McAfee | An Intel Company
> 5000 Headquarters Dr.
> Plano, Texas 75024
> 
> Direct: +1.972.963.7096
> Mobile: +1.817.637.8026
> Web: www.mcafee.com<http://www.mcafee.com/>
> 
> From: Adam Montville <[email-masked]<mailto:[email-masked]>>
> Date: Tue, 14 Feb 2012 15:12:51 -0600
> To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> Subject: [scap_interest] Operational Aspects
> 
> While we're all bantering about on security automation, there's another side to the story.  Are there any operational concerns we might address within a WG should one be formed?  For example, we have, in the United States, NVD hosting a repository of information.  CCE identifiers are moderated and assigned by an operational process.  As new enumerations are published and new types of content are conceived, it's easy to imagine the need for some operational standardization.
> 
> Should we consider standardizing some of these processes, and if so would the WG we seek to establish be the appropriate place for that work?
> 
> Regards,
> 
> Adam W. Montville | Security and Compliance Architect
> 
> Direct: 503 276-7661
> Mobile: 360 471-7815
> 
> TRIPWIRE | Take CONTROL
> http://www.tripwire.com
> 
> _______________________________________________
> scap_interest mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/scap_interest
> 
> 
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest

Date: Thu, 16 Feb 2012 07:58:06 -0500
From: Sean Turner <[email-masked]>
To: Adam Montville <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

(assuming there is a WG) It's mostly up to the WG.  There's still 
IETF-wide, IESG and external party review of WG charters.

More inline below ...

spt

On 2/15/12 11:50 AM, Adam Montville wrote:
> Hi David,
>
> I think the answer to all three of your questions is really that it's all up to the working group.  The WG has an interest in ensuring interoperability, and standards are created based on running code.  USG may continue to require validation outside the context of the WG.  Finally, as the IETF is an open organization, participation from any organization, including USG, would be welcomed.
>
> Adam
>
> From:<[email-masked]<mailto:[email-masked]>>
> Date: Wed, 15 Feb 2012 10:42:34 -0600
> To:<[email-masked]<mailto:[email-masked]>>, kent_landfield<[email-masked]<mailto:[email-masked]>>,<[email-masked]<mailto:[email-masked]>>
> Subject: Re: [scap_interest] Scope of standards potentially moving to IETF
>
> Hello all:
>
> I also believe that SCAP can be used worlwide and should be marketted accordingly.
> Maybe allowing IETF to endorse them is a good idea.
>
> I just have a few questions.
>
> 1.  Would IETF also take a role in validating products?

Some lurking greybeards may correct me, but I can't think of a time when 
the IETF validated products - but maybe that depends on what you mean. 
I can think of many bake-offs/interop events and reports of such events 
that listed product x, y, and z and whether they interoperated on tests 
a, b, and c.  If by validation you're thinking a letter/certificate from 
the IETF saying product x is compliant with RFC ####, then I think that 
won't happen.

> 2.  What mechanisms does IETF provide that encourage the cooperation needed for incorporation future specifications?

An open, consensus driven standardization process would be my answer. 
List are open to anyone and drafts/RFCs are available for free.

> 3.  How would IETF take into account the input of U.S. Federal agencies in future specifications?

On USG participation, all participants in the IETF (including those of 
the USG or any other Gov't) participate as individuals.  They're free 
(in fact encouraged) to bring in-scope proposals to the WG.  Assuming 
there's a debate about a particular feature/option in their proposal, 
I'd expect them to defend their proposal just like everybody else does. 
  Rationale like "We're the USG and you shalt do it this way" isn't 
going to fly.  Rough consensus will rule the day.

> David Oliva
>
> On 02/15/12, Chernin, Michael A.<[email-masked]<mailto:[email-masked]>>  wrote:
>
> Kent, understood. Like the vendors, I do agree that certain standards need to go to IETF. But, today the only people that would be voting during IETF calls would be the federal government and security tool vendors. I am going to be hesitant in supporting a move of all standards until there are standards consumers (private sector customers) who will also be participating in IETF voting. I am trying to balance rapid development of standards using the IETF and complete vendor control of all standards. Once I see more consumer activity during voting, I will be more supportive of a large number of standards moving IETF.
>
> I know I am early and jumping the gun on this, but I just wanted to get my story out there. At this time no standards have been specifically identified and no specific action is required at this time.
>
> Aharon
>
> DTCC Non-Confidential (White)
> ---------------------------------------------------
> Michael "Aharon" Chernin
> Security Automation Program Manager
> Corporate Information Security -Depository Trust&  Clearing Corporation
> O: 813-470-2173
>
> From: [email-masked]<mailto:[email-masked]>  [mailto:[email-masked]]
> Sent: Tuesday, February 14, 2012 6:09 PM
> To: Chernin, Michael A.; [email-masked]<mailto:[email-masked]>
> Subject: Re: [scap_interest] Scope of standards potentially moving to IETF
>
>> From my perspective TBD.
>
> There are some that are unencumbered from and IPR perspective and those are potential candidates. Others will have to move as the appropriate consensus  is achieved and IPR issues are addressed.
>
> The idea here from my perspective is to figure that out.
>
> Kent Landfield
> Director Content Strategy, Architecture and Standards
>
> McAfee | An Intel Company
> 5000 Headquarters Dr.
> Plano, Texas 75024
>
> Direct: +1.972.963.7096
> Mobile: +1.817.637.8026
> Web: www.mcafee.com<http://www.mcafee.com/>
>
> From: Michael Aharon Chernin<[email-masked]<mailto:[email-masked]>>
> Date: Tue, 14 Feb 2012 16:04:43 -0600
> To: "[email-masked]<mailto:[email-masked]>"<[email-masked]<mailto:[email-masked]>>
> Subject: [scap_interest] Scope of standards potentially moving to IETF
>
> I am just going to jump right on out there and ask. Which standards are we looking to go to IETF? Specific SCAP standards or the entire SCAP umbrella?
>
> Aharon
>
> DTCC Non-Confidential (White)
> ---------------------------------------------------
> Michael "Aharon" Chernin
> Security Automation Program Manager
> Corporate Information Security -Depository Trust&  Clearing Corporation
> O: 813-470-2173
>
> <BR>_____________________________________________________________
> <FONT size=2><BR>
> DTCC DISCLAIMER: This email and any files transmitted with it are
> confidential and intended solely for the use of the individual or
> entity to whom they are addressed. If you have received this email
> in error, please notify us immediately and delete the email and any
> attachments from your system. The recipient should check this email
> and any attachments for the presence of viruses.  The company
> accepts no liability for any damage caused by any virus transmitted
> by this email.</FONT>
> _______________________________________________
> scap_interest mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/scap_interest
>
>
> ________________________________
>
> _______________________________________________
> scap_interest mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/scap_interest
> _______________________________________________ scap_interest mailing list [email-masked]<mailto:[email-masked]>  https://www.ietf.org/mailman/listinfo/scap_interest
>
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest
>

From: <[email-masked]>
To: <[email-masked]>
Date: Thu, 16 Feb 2012 07:53:31 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [scap_interest] IETF 83 meeting

Hello,

SACM was approved to host a 'side meeting' at the next IETF meeting, IETF 83, Paris France.  The side meeting will be used to help the group determine our scope of work as we work towards a charter.  Initial work items and drafts will be discussed as described in the BOF related messages.  We are not sure what time slot we will be assigned for the side meeting.  It may happen on Sunday, March25th prior to the Welcome Reception.  For those new to the IETF, there are several introductory sessions that take place on Sunday and are very helpful to learning more about the IETF.  I highly recommend attending these sessions.

We may also be assigned an evening slot during the week.  We will let everyone know when the meeting will take place as soon as we know.

MILE and NEA have related work, so you may want to consider attending those sessions as well as any others that peak your interest.  The IETF covers a broad range of topics.  You may want to look at the list of working groups in advance and read some documents to have an understanding of the various sessions.  It is a great learning opportunity on cutting edge work.

We look forward to seeing you at this and other meetings that week!

Thank you,
Kathleen

Date: Thu, 16 Feb 2012 01:11:53 +0000
From: Jerome Athias <[email-masked]>
To: [email-masked]
Subject: [scap_interest] Software Vulnerability Mitigation Automation - IVIL v1.0

As mentioned in the U.S. "INTERNATIONAL STRATEGY FOR CYBERSPACE"[1] 
document,
we need "interoperable and secure technical standards, determined by 
technical experts".

I would like to introduce my vision of "Software Vulnerability 
Mitigation Automation"
via IVIL v1.0 via a (incomplete) Conceptual Map.

Requirements: ~15 minutes of your time, a headset and the Bol�ro

https://corevidence.com/research/vulnerability_interoperability_ivil_v1.jpg

(I extracted some links, please see below)

i = x2ivil + ivil2x
where "i" is interoperability and "x" a software (vulnerability 
scanner,... + waf, virtual patching system, ...)

What do you think?

Thank you.
Best regards,

Jerome Athias - NETpeas
VP, Director of Software Engineer
Palo Alto - Paris - Casablanca
http://www.netpeas.com

"The computer security is an art form. It's the ultimate martial art."

[1]   
  http://www.whitehouse.gov/blog/2011/05/16/launching-us-international-strategy-cyberspace
IVIL-XML   
  http://www.cupfighter.net/index.php/2010/10/ivil-an-xml-schema-to-exchange-vulnerability-information/
ThreadFix    http://code.google.com/p/threadfix/

From: Adam Montville <[email-masked]>
To: Dorian Cougias <[email-masked]>
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Just throwing this out there: Compliance Frameworks

Excellent!  Good to have you here.

From: Dorian Cougias <[email-masked]<mailto:[email-masked]>>
Date: Wed, 15 Feb 2012 09:03:43 -0800
To: Adam Montville <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, kent_landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Just throwing this out there: Compliance Frameworks

Yes. I've signed up on the list and will contribute as much as you'd like.

This might dovetail in very well with our Online Mapping Tool effort we are beginning to release this year.

Dorian J. Cougias
Compliance Scientist
Unified Compliance Framework

---- On Wed, 15 Feb 2012 08:53:02 -0800 Adam Montville<[email-masked]<mailto:[email-masked]>> wrote ----

Can we then expect that UCF will be contributing to the effort? I think our thoughts with respect to representing frameworks and controls would be well-informed by UCF's experience.

Adam

From: Dorian Cougias <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Date: Wed, 15 Feb 2012 08:08:28 -0800
To: Adam Montville <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>, kent_landfield <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Subject: Re: FW: [scap_interest] Just throwing this out there: Compliance Frameworks

Date: Wed, 15 Feb 2012 09:03:43 -0800
From: Dorian Cougias <[email-masked]>
To: Adam Montville <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Just throwing this out there: Compliance Frameworks

------=_Part_15078_1417880183.1329325423466
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Yes. I've signed up on the list and will contribute as much as you'd like.

This might dovetail in very well with our Online Mapping Tool effort we are beginning to release this year.

Dorian J. Cougias
Compliance Scientist
Unified Compliance Framework

---- On Wed, 15 Feb 2012 08:53:02 -0800 Adam Montville&lt;[email-masked]&gt; wrote ---- 

Can we then expect that UCF will be contributing to the effort? I think our thoughts with respect to representing frameworks and controls would be well-informed by UCF's experience. 
 
Adam 
 
From: Dorian Cougias &lt;[email-masked]&lt;mailto:[email-masked]&gt;&gt; 
Date: Wed, 15 Feb 2012 08:08:28 -0800 
To: Adam Montville &lt;[email-masked]&lt;mailto:[email-masked]&gt;&gt; 
Cc: &lt;[email-masked]&lt;mailto:[email-masked]&gt;&gt;, &lt;[email-masked]&lt;mailto:[email-masked]&gt;&gt;, kent_landfield &lt;[email-masked]&lt;mailto:[email-masked]&gt;&gt;, &lt;[email-masked]&lt;mailto:[email-masked]&gt;&gt; 
Subject: Re: FW: [scap_interest] Just throwing this out there: Compliance Frameworks 

------=_Part_15078_1417880183.1329325423466
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style='font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif;'>Yes. I've signed up on the list and will contribute as much as you'd like.<br><br><div id=""><div>This might dovetail in very well with our Online Mapping Tool effort we are beginning to release this year.</div><div><br></div><div>Dorian J. Cougias</div><div>Compliance Scientist</div><div>Unified Compliance Framework</div></div><br><div id="1"><br>---- On Wed, 15 Feb 2012 08:53:02 -0800 <b>Adam Montville&lt;<a href='mailto:[email-masked]' target='_blank'>[email-masked]</a>&gt;</b> wrote ---- <br></div><br><blockquote style="border-left: 1px solid #0000FF; padding-left: 6px;">Can we then expect that UCF will be contributing to the effort?  I think our thoughts with respect to representing frameworks and controls would be well-informed by UCF's experience. <br> <br>Adam <br> <br>From: Dorian Cougias &lt;<a href="mailto:[email-masked]" target="_blank" mailid="dcougias%40unifiedcompliance.com" subj="">[email-masked]</a>&lt;mailto:[email-masked]&gt;&gt; <br>Date: Wed, 15 Feb 2012 08:08:28 -0800 <br>To: Adam Montville &lt;<a href="mailto:[email-masked]" target="_blank" mailid="amontville%40tripwire.com" subj="">[email-masked]</a>&lt;mailto:[email-masked]&gt;&gt; <br>Cc: &lt;<a href="mailto:[email-masked]" target="_blank" mailid="CCI%40disa.mil" subj="">[email-masked]</a>&lt;mailto:[email-masked]&gt;&gt;, &lt;<a href="mailto:[email-masked]" target="_blank" mailid="scap_interest%40ietf.org" subj="">[email-masked]</a>&lt;mailto:[email-masked]&gt;&gt;, kent_landfield &lt;<a href="mailto:[email-masked]" target="_blank" mailid="kent_landfield%40mcafee.com" subj="">[email-masked]</a>&lt;mailto:[email-masked]&gt;&gt;, &lt;<a href="mailto:[email-masked]" target="_blank" mailid="cisaacs%40unifiedcompliance.com" subj="">[email-masked]</a>&lt;mailto:[email-masked]&gt;&gt; <br>Subject: Re: FW: [scap_interest] Just throwing this out there: Compliance Frameworks <br> <br> <br></blockquote><br></div></body></html>
------=_Part_15078_1417880183.1329325423466--

From: Adam Montville <[email-masked]>
To: Dorian Cougias <[email-masked]>
Date: Wed, 15 Feb 2012 16:53:02 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Just throwing this out there: Compliance Frameworks

Can we then expect that UCF will be contributing to the effort?  I think our thoughts with respect to representing frameworks and controls would be well-informed by UCF's experience.

Adam

From: Dorian Cougias <[email-masked]<mailto:[email-masked]>>
Date: Wed, 15 Feb 2012 08:08:28 -0800
To: Adam Montville <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, kent_landfield <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Subject: Re: FW: [scap_interest] Just throwing this out there: Compliance Frameworks

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Wed, 15 Feb 2012 10:50:02 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

--_000_CB613BFC2C758kentlandfieldmcafeecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Aharon,

Please take a look at the http://www.ietf.org/tao.html.  At the IETF, those who participate do so as individuals.  You can participate (you are now) and make your opinion's known.  And when we get to a point where we are actually making decisions, your opinion and all who are participating, regardless of what they do in the outside world,  are accounted for�

One of the more important things those joining from the SCAP community need to do is to make sure and learn how the IETF works.

The document above will help�

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Michael Aharon Chernin <[email-masked]<mailto:[email-masked]>>
Date: Wed, 15 Feb 2012 08:53:02 -0600
To: Kent Landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [scap_interest] Scope of standards potentially moving to IETF

Kent, understood. Like the vendors, I do agree that certain standards need to go to IETF. But, today the only people that would be voting during IETF calls would be the federal government and security tool vendors. I am going to be hesitant in supporting a move of all standards until there are standards consumers (private sector customers) who will also be participating in IETF voting. I am trying to balance rapid development of standards using the IETF and complete vendor control of all standards. Once I see more consumer activity during voting, I will be more supportive of a large number of standards moving IETF.

I know I am early and jumping the gun on this, but I just wanted to get my story out there. At this time no standards have been specifically identified and no specific action is required at this time.

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust & Clearing Corporation
O: 813-470-2173

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, February 14, 2012 6:09 PM
To: Chernin, Michael A.; [email-masked]<mailto:[email-masked]>
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

>From my perspective TBD.

There are some that are unencumbered from and IPR perspective and those are potential candidates. Others will have to move as the appropriate consensus  is achieved and IPR issues are addressed.

The idea here from my perspective is to figure that out.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Michael Aharon Chernin <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 16:04:43 -0600
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [scap_interest] Scope of standards potentially moving to IETF

I am just going to jump right on out there and ask. Which standards are we looking to go to IETF? Specific SCAP standards or the entire SCAP umbrella?

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust & Clearing Corporation
O: 813-470-2173

<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>
_______________________________________________
scap_interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scap_interest

--_000_CB613BFC2C758kentlandfieldmcafeecom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-family: 'Times New Roman', sans-serif; "><div><div><div>Aharon,</div><div><br></div><div>Please take a look at the&nbsp;<a href="http://www.ietf.org/tao.html">http://www.ietf.org/tao.html</a>. &nbsp;At the IETF, those who participate do so as individuals. &nbsp;You can participate (you are now) and make your opinion's known. &nbsp;And when we get to a point where we are actually making decisions, your opinion and all who are participating, regardless of what they do in the outside world, &nbsp;are accounted for�&nbsp;</div><div><br></div><div>One of the more important things those joining from the SCAP community need to do is to make sure and learn how the IETF works.</div><div><br></div><div>The document above will help�</div><div><br></div><div><div><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Kent Landfield</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Director Content Strategy, Architecture and Standards</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>McAfee | An Intel Company</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">5000 Headquarters Dr.</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Plano, Texas 75024</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Direct: &#43;1.972.963.7096&nbsp;</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Mobile: &#43;1.817.637.8026</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Web:&nbsp;</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><a href="http://www.mcafee.com/" style="color: rgb(96, 106, 113) !important; ">www.mcafee.com</a></span></div></div></div></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Michael Aharon Chernin &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Date: </span> Wed, 15 Feb 2012 08:53:02 -0600<br><span style="font-weight:bold">To: </span> Kent  Landfield &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;, &quot;<a href="mailto:[email-masked]">[email-masked]</a>&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Subject: </span> RE: [scap_interest] Scope of standards potentially moving to IETF<br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><meta name="Generator" content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">Kent, understood. Like the vendors, I do agree that certain standards need to go to IETF. But, today the only people that would be voting during IETF calls
 would be the federal government and security tool vendors. I am going to be hesitant in supporting a move of all standards until there are standards consumers (private sector customers) who will also be participating in IETF voting. I am trying to balance
 rapid development of standards using the IETF and complete vendor control of all standards. Once I see more consumer activity during voting, I will be more supportive of a large number of standards moving IETF.<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">I know I am early and jumping the gun on this, but I just wanted to get my story out there. At this time no standards have been specifically identified and
 no specific action is required at this time.<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">Aharon<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p><div><p class="MsoNormal"><span style="font-size: 9pt; color: black; font-family: Calibri, sans-serif; ">DTCC Non-Confidential (White)<br>
---------------------------------------------------<br>
Michael &quot;Aharon&quot; Chernin<br>
Security Automation Program Manager<br>
Corporate Information Security -Depository Trust &amp; Clearing Corporation<br>
O: 813-470-2173</span><span style="font-size: 9pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p></o:p></span></p></div><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "> <a href="mailto:[email-masked]">[email-masked]</a> [<a href="mailto:[email-masked]">mailto:[email-masked]</a>]
<br><b>Sent:</b> Tuesday, February 14, 2012 6:09 PM<br><b>To:</b> Chernin, Michael A.; <a href="mailto:[email-masked]">[email-masked]</a><br><b>Subject:</b> Re: [scap_interest] Scope of standards potentially moving to IETF<o:p></o:p></span></p></div></div><p class="MsoNormal"><o:p>&nbsp;</o:p></p><div><div><div><p class="MsoNormal"><span style="color:black">From my perspective TBD.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">There are some that are unencumbered from and IPR perspective and those are potential candidates. Others will have to move as the appropriate consensus &nbsp;is achieved and IPR issues are addressed.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">The idea here from my perspective is to figure that out. &nbsp;<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p></div><div><div><p class="MsoNormal"><strong><span style="font-size: 9pt; color: rgb(96, 106, 113); font-family: Arial, sans-serif; ">Kent Landfield</span></strong><span style="font-size: 9pt; color: rgb(96, 106, 113); font-family: Arial, sans-serif; "><br><span class="apple-style-span">Director Content Strategy, Architecture and Standards</span><br><br><strong><span style="font-family: Arial, sans-serif; ">McAfee | An Intel Company</span></strong><br><span class="apple-style-span">5000 Headquarters Dr.</span><br><span class="apple-style-span">Plano, Texas 75024</span><br><br><span class="apple-style-span">Direct: &#43;1.972.963.7096&nbsp;</span><br><span class="apple-style-span">Mobile: &#43;1.817.637.8026</span><br><strong><span style="font-family: Arial, sans-serif; ">Web:&nbsp;</span></strong><span class="apple-style-span"><a href="http://www.mcafee.com/">www.mcafee.com</a></span></span><span style="color:black"><o:p></o:p></span></p></div></div></div></div><div><p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p></div><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size: 11pt; color: black; font-family: Calibri, sans-serif; ">From:
</span></b><span style="font-size: 11pt; color: black; font-family: Calibri, sans-serif; ">Michael Aharon Chernin &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><b>Date: </b>Tue, 14 Feb 2012 16:04:43 -0600<br><b>To: </b>&quot;<a href="mailto:[email-masked]">[email-masked]</a>&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><b>Subject: </b>[scap_interest] Scope of standards potentially moving to IETF<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p></div><blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE"><div><div><div><p class="MsoNormal"><span style="color:black">I am just going to jump right on out there and ask. Which standards are we looking to go to IETF? Specific SCAP standards or the entire SCAP umbrella?<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">Aharon<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">DTCC Non-Confidential (White)<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">---------------------------------------------------<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">Michael &quot;Aharon&quot; Chernin<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">Security Automation Program Manager<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">Corporate Information Security -Depository Trust &amp; Clearing Corporation<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">O: 813-470-2173<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">&lt;BR&gt;_____________________________________________________________<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">&lt;FONT size=2&gt;&lt;BR&gt;<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">DTCC DISCLAIMER: This email and any files transmitted with it are<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">confidential and intended solely for the use of the individual or<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">entity to whom they are addressed. If you have received this email<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">in error, please notify us immediately and delete the email and any<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">attachments from your system. The recipient should check this email<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">and any attachments for the presence of viruses.&nbsp;&nbsp;The company<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">accepts no liability for any damage caused by any virus transmitted<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">by this email.&lt;/FONT&gt;<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">_______________________________________________<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">scap_interest mailing list<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black"><a href="mailto:[email-masked]">[email-masked]</a><o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black"><a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a><o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p></div></div></div></blockquote></div></div></div></div></blockquote></span></body></html>

--_000_CB613BFC2C758kentlandfieldmcafeecom_--

From: Adam Montville <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, kent_landfield <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 15 Feb 2012 16:50:40 +0000
Accept-Language: en-US
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

Hi David,

I think the answer to all three of your questions is really that it's all up to the working group.  The WG has an interest in ensuring interoperability, and standards are created based on running code.  USG may continue to require validation outside the context of the WG.  Finally, as the IETF is an open organization, participation from any organization, including USG, would be welcomed.

Adam

From: <[email-masked]<mailto:[email-masked]>>
Date: Wed, 15 Feb 2012 10:42:34 -0600
To: <[email-masked]<mailto:[email-masked]>>, kent_landfield <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

Hello all:

I also believe that SCAP can be used worlwide and should be marketted accordingly.
Maybe allowing IETF to endorse them is a good idea.

I just have a few questions.

1.  Would IETF also take a role in validating products?
2.  What mechanisms does IETF provide that encourage the cooperation needed for incorporation future specifications?
3.  How would IETF take into account the input of U.S. Federal agencies in future specifications?

David Oliva

On 02/15/12, Chernin, Michael A.<[email-masked]<mailto:[email-masked]>> wrote:

Kent, understood. Like the vendors, I do agree that certain standards need to go to IETF. But, today the only people that would be voting during IETF calls would be the federal government and security tool vendors. I am going to be hesitant in supporting a move of all standards until there are standards consumers (private sector customers) who will also be participating in IETF voting. I am trying to balance rapid development of standards using the IETF and complete vendor control of all standards. Once I see more consumer activity during voting, I will be more supportive of a large number of standards moving IETF.

I know I am early and jumping the gun on this, but I just wanted to get my story out there. At this time no standards have been specifically identified and no specific action is required at this time.

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust & Clearing Corporation
O: 813-470-2173

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, February 14, 2012 6:09 PM
To: Chernin, Michael A.; [email-masked]<mailto:[email-masked]>
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

>From my perspective TBD.

There are some that are unencumbered from and IPR perspective and those are potential candidates. Others will have to move as the appropriate consensus  is achieved and IPR issues are addressed.

The idea here from my perspective is to figure that out.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Michael Aharon Chernin <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 16:04:43 -0600
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [scap_interest] Scope of standards potentially moving to IETF

I am just going to jump right on out there and ask. Which standards are we looking to go to IETF? Specific SCAP standards or the entire SCAP umbrella?

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust & Clearing Corporation
O: 813-470-2173

<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>
_______________________________________________
scap_interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scap_interest

________________________________

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

Date: Wed, 15 Feb 2012 10:42:34 -0600 (CST)
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

<div style="FONT-FAMILY: Arial; COLOR: #000000; FONT-SIZE: 12px"><DIV>Hello all:</DIV><DIV>&nbsp;</DIV><DIV>I also believe that SCAP can be used worlwide and should be marketted accordingly.</DIV><DIV>Maybe allowing IETF to endorse them is a good idea.</DIV><DIV>&nbsp;</DIV><DIV>I just have a few questions.</DIV><DIV>&nbsp;</DIV><DIV>1.&nbsp; Would IETF also take a role in validating products?</DIV><DIV>2.&nbsp; What mechanisms does IETF provide that encourage the cooperation needed for incorporation&nbsp;future specifications?</DIV><DIV>3.&nbsp; How would IETF take into account the input of U.S. Federal agencies in future specifications?</DIV><DIV></DIV><DIV></DIV><DIV>&nbsp;</DIV><DIV>David Oliva</DIV><DIV>&nbsp;</DIV><DIV style="MARGIN: 5px 0px; BORDER-TOP: #bcbcbc 1px solid"></DIV><SPAN style="FONT-FAMILY: arial; COLOR: #000000; FONT-SIZE: 12px">On 02/15/12, <SPAN>Chernin, Michael A.&lt;[email-masked]&gt;</SPAN> wrote:</SPAN><DIV>&nbsp;</DIV><DIV style="FONT-FAMILY: arial; COLOR: #000000; FONT-SIZE: 12px"><DIV class=WordSection1><P class=MsoNormal><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">Kent, understood. Like the vendors, I do agree that certain standards need to go to IETF. But, today the only people that would be voting during IETF calls would be the federal government and security tool vendors. I am going to be hesitant in supporting a move of all standards until there are standards consumers (private sector customers) who will also be participating in IETF voting. I am trying to balance rapid development of standards using the IETF and complete vendor control of all standards. Once I see more consumer activity during voting, I will be more supportive of a large number of standards moving IETF.</SPAN></P><P class=MsoNormal><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">&nbsp;</SPAN></P><P class=MsoNormal><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">I know I am early and jumping the gun on this, but I just wanted to get my story out there. At this time no standards have been specifically identified and no specific action is required at this time.</SPAN></P><P class=MsoNormal><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">&nbsp;</SPAN></P><P class=MsoNormal><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">Aharon</SPAN></P><P class=MsoNormal><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">&nbsp;</SPAN></P><DIV><P class=MsoNormal><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: black; FONT-SIZE: 9pt">DTCC Non-Confidential (White)<BR>---------------------------------------------------<BR>Michael "Aharon" Chernin<BR>Security Automation Program Manager<BR>Corporate Information Security -Depository Trust &amp; Clearing Corporation<BR>O: 813-470-2173</SPAN><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 9pt"></SPAN></P></DIV><P class=MsoNormal><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: #1f497d; FONT-SIZE: 11pt">&nbsp;</SPAN></P><DIV style="BORDER-BOTTOM: medium none; BORDER-LEFT: blue 1.5pt solid; PADDING-BOTTOM: 0in; PADDING-LEFT: 4pt; PADDING-RIGHT: 0in; BORDER-TOP: medium none; BORDER-RIGHT: medium none; PADDING-TOP: 0in"><DIV><DIV style="BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><P class=MsoNormal><B><SPAN style="FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt">From:</SPAN></B><SPAN style="FONT-FAMILY: 'Tahoma','sans-serif'; FONT-SIZE: 10pt"> <A class=parsedEmail href="mailto:[email-masked]" target=_blank>[email-masked]</A> [<A class=parsedLink href="mailto:[email-masked]" target=_blank>mailto:[email-masked]</A>] <BR><B>Sent:</B> Tuesday, February 14, 2012 6:09 PM<BR><B>To:</B> Chernin, Michael A.; <A class=parsedEmail href="mailto:[email-masked]" target=_blank>[email-masked]</A><BR><B>Subject:</B> Re: [scap_interest] Scope of standards potentially moving to IETF</SPAN></P></DIV></DIV><P class=MsoNormal>&nbsp;</P><DIV><DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">From my perspective TBD.</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">&nbsp;</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">There are some that are unencumbered from and IPR perspective and those are potential candidates. Others will have to move as the appropriate consensus &nbsp;is achieved and IPR issues are addressed.</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">&nbsp;</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">The idea here from my perspective is to figure that out. &nbsp;</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">&nbsp;</SPAN></P></DIV><DIV><DIV><P class=MsoNormal><STRONG><SPAN style="FONT-FAMILY: 'Arial','sans-serif'; COLOR: #606a71; FONT-SIZE: 9pt">Kent Landfield</SPAN></STRONG><SPAN style="FONT-FAMILY: 'Arial','sans-serif'; COLOR: #606a71; FONT-SIZE: 9pt"><BR><SPAN class=apple-style-span>Director Content Strategy, Architecture and Standards</SPAN><BR><BR><STRONG><SPAN style="FONT-FAMILY: 'Arial','sans-serif'">McAfee | An Intel Company</SPAN></STRONG><BR><SPAN class=apple-style-span>5000 Headquarters Dr.</SPAN><BR><SPAN class=apple-style-span>Plano, Texas 75024</SPAN><BR><BR><SPAN class=apple-style-span>Direct: +1.972.963.7096&nbsp;</SPAN><BR><SPAN class=apple-style-span>Mobile: +1.817.637.8026</SPAN><BR><STRONG><SPAN style="FONT-FAMILY: 'Arial','sans-serif'">Web:&nbsp;</SPAN></STRONG><SPAN class=apple-style-span><A href="http://www.mcafee.com/" target=_blank>www.mcafee.com</A></SPAN></SPAN><SPAN style="COLOR: black"></SPAN></P></DIV></DIV></DIV></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">&nbsp;</SPAN></P></DIV><DIV style="BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><P class=MsoNormal><B><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: black; FONT-SIZE: 11pt">From: </SPAN></B><SPAN style="FONT-FAMILY: 'Calibri','sans-serif'; COLOR: black; FONT-SIZE: 11pt">Michael Aharon Chernin &lt;<A class=parsedEmail href="mailto:[email-masked]" target=_blank>[email-masked]</A>&gt;<BR><B>Date: </B>Tue, 14 Feb 2012 16:04:43 -0600<BR><B>To: </B>"<A class=parsedEmail href="mailto:[email-masked]" target=_blank>[email-masked]</A>" &lt;<A class=parsedEmail href="mailto:[email-masked]" target=_blank>[email-masked]</A>&gt;<BR><B>Subject: </B>[scap_interest] Scope of standards potentially moving to IETF</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">&nbsp;</SPAN></P></DIV><BLOCKQUOTE style="BORDER-BOTTOM: medium none; BORDER-LEFT: #b5c4df 4.5pt solid; PADDING-BOTTOM: 0in; PADDING-LEFT: 4pt; PADDING-RIGHT: 0in; MARGIN-LEFT: 3.75pt; BORDER-TOP: medium none; MARGIN-RIGHT: 0in; BORDER-RIGHT: medium none; PADDING-TOP: 0in" id=MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE><DIV><DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">I am just going to jump right on out there and ask. Which standards are we looking to go to IETF? Specific SCAP standards or the entire SCAP umbrella?</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">&nbsp;</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">Aharon</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">&nbsp;</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">DTCC Non-Confidential (White)</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">---------------------------------------------------</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">Michael "Aharon" Chernin</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">Security Automation Program Manager</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">Corporate Information Security -Depository Trust &amp; Clearing Corporation</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">O: 813-470-2173</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">&nbsp;</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">&lt;BR&gt;_____________________________________________________________</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">&lt;FONT size=2&gt;&lt;BR&gt;</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">DTCC DISCLAIMER: This email and any files transmitted with it are</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">confidential and intended solely for the use of the individual or</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">entity to whom they are addressed. If you have received this email</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">in error, please notify us immediately and delete the email and any</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">attachments from your system. The recipient should check this email</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">and any attachments for the presence of viruses.&nbsp;&nbsp;The company</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">accepts no liability for any damage caused by any virus transmitted</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">by this email.&lt;/FONT&gt;</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">_______________________________________________</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">scap_interest mailing list</SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black"><A class=parsedEmail href="mailto:[email-masked]" target=_blank>[email-masked]</A></SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black"><A href="https://www.ietf.org/mailman/listinfo/scap_interest" target=_blank>https://www.ietf.org/mailman/listinfo/scap_interest</A></SPAN></P></DIV><DIV><P class=MsoNormal><SPAN style="COLOR: black">&nbsp;</SPAN></P></DIV></DIV></DIV></BLOCKQUOTE></DIV></DIV><BR><HR SIZE=1><BR>_______________________________________________<BR>scap_interest mailing list<BR><A class=parsedEmail href="mailto:[email-masked]" target=_blank>[email-masked]</A><BR><A class=parsedLink href="https://www.ietf.org/mailman/listinfo/scap_interest" target=_blank>https://www.ietf.org/mailman/listinfo/scap_interest</A><BR></DIV></div>

Date: Wed, 15 Feb 2012 08:08:28 -0800
From: Dorian Cougias <[email-masked]>
To: Adam Montville <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [scap_interest] FW: Just throwing this out there: Compliance Frameworks

------=_Part_10235_1835691541.1329322108785
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

We at the UCF believe that we can work together with the IETF, or any other organization, to ensure that our commercial mapping efforts and those performed in the public sector can co-exist and be mutually beneficial to each other's efforts.

Dorian J. Cougias
Compliance Scientist
Unified Compliance Framework

---- On Wed, 15 Feb 2012 06:24:33 -0800 Adam Montville &lt;[email-masked]&gt; wrote ---- 

Hello, 
 
If you're not already aware, there is an effort underway to migrate security automation development to the Internet Engineering Task Force. I have proposed that part of that effort seek to expand how frameworks can be represented. I believe that CCI and/or UCF formats may be of use and invite you to join the discussion at [email-masked]: https://www.ietf.org/mailman/listinfo/scap_interest. 
 
There is a need to accurately represent frameworks, and I'd like to see DISA and UCF join in the discussion. 
 
If you have any comments, questions, or concerns, feel free to contact me directly. 
 
Regards, 
 
Adam W. Montville | Security and Compliance Architect 
 
Direct: 503 276-7661 
Mobile: 360 471-7815 
 
TRIPWIRE | Take CONTROL 
http://www.tripwire.com 
 
From: kent_landfield &lt;[email-masked]&lt;mailto:[email-masked]&gt;&gt; 
Date: Tue, 14 Feb 2012 15:47:29 -0600 
To: Adam Montville &lt;[email-masked]&lt;mailto:[email-masked]&gt;&gt;, &lt;[email-masked]&lt;mailto:[email-masked]&gt;&gt; 
Subject: Re: [scap_interest] Just throwing this out there: Compliance Frameworks 
 
Adam, 
 
I agree that an effort such as this has great potential. Think of the content authors today. They use XML Editors or internally developed tools to create OVAL to do the compliance checking. This is very time consuming and very costly, while limiting the available checks and benchmarks. 
 
If there was a means where all regulations and security policies could be universally mapped and the specifics around them, based on individual platforms, were also attached to each unified record, it is possible to auto generate not just the benchmarks but the individual checks. Some of this research has been successful in the past. This is doable. The problem has been there is not an authoritative source for that data. 
 
Today too many people are manually writing content that could be auto generated from a database with the right schema and software. The problem though is as much on the front end as it is on the generation side. Someone needs to maintain that information or have an infrastructure put in place where guidance authors for regulations or security policies can update their information in the shared datastore. 
 
I think this is one of the missing pieces and it may be useful to have a discussion with interested parties but you would need to include participants from the two mentioned efforts below. 
 
Kent Landfield 
Director Content Strategy, Architecture and Standards 
 
McAfee | An Intel Company 
5000 Headquarters Dr. 
Plano, Texas 75024 
 
Direct: +1.972.963.7096 
Mobile: +1.817.637.8026 
Web: www.mcafee.com&lt;http://www.mcafee.com/&gt; 
 
From: Adam Montville &lt;[email-masked]&lt;mailto:[email-masked]&gt;&gt; 
Date: Tue, 14 Feb 2012 15:09:34 -0600 
To: "[email-masked]&lt;mailto:[email-masked]&gt;" &lt;[email-masked]&lt;mailto:[email-masked]&gt;&gt; 
Subject: [scap_interest] Just throwing this out there: Compliance Frameworks 
 
All, 
 
I had a brief discussion with several members of this list with respect to compliance frameworks, which met some resistance. Still, I think presenting the idea to a larger audience to solicit feedback is a good idea. 
 
>From an automation perspective, it seems that some method of being able to map benchmark-level tests to some higher level policy representation may be warranted. At the end of the day, we perform assessments to ensure that we are in a secure state – to be compliant with a particular set of policies. 
 
Is there any interest in being able to represent a compliance framework with either a new specification or potentially revitalizing and extending an existing specification (CCI: http://iase.disa.mil/stigs/cci.html), or to simply rely upon any existing commercial efforts, such as UCF (https://www.unifiedcompliance.com)? 
 
Or, is this type of representation simply not needed – there's enough there, the present demand doesn't justify the work, or something else? 
 
Thoughts? 
 
Regards, 
 
Adam W. Montville | Security and Compliance Architect 
 
Direct: 503 276-7661 
Mobile: 360 471-7815 
 
TRIPWIRE | Take CONTROL 
http://www.tripwire.com 
 
_______________________________________________ 
scap_interest mailing list 
[email-masked]&lt;mailto:[email-masked]&gt; 
https://www.ietf.org/mailman/listinfo/scap_interest 

------=_Part_10235_1835691541.1329322108785
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style='font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif;'>We at the UCF believe that we can work together with the IETF, or any other organization, to ensure that our commercial mapping efforts and those performed in the public sector can co-exist and be mutually beneficial to each other's efforts.<br><br><div id=""><div><br></div><div><br></div><div>Dorian J. Cougias</div><div>Compliance Scientist</div><div>Unified Compliance Framework</div></div><br><div id="1"><br>---- On Wed, 15 Feb 2012 06:24:33 -0800 <b>Adam Montville &lt;<a href='mailto:[email-masked]' target='_blank'>[email-masked]</a>&gt;</b> wrote ---- <br></div><br><blockquote style="border-left: 1px solid #0000FF; padding-left: 6px;">Hello, <br> <br>If you're not already aware, there is an effort underway to migrate security automation development to the Internet Engineering Task Force.  I have proposed that part of that effort seek to expand how frameworks can be represented.  I believe that CCI and/or  UCF formats may be of use and invite you to join the discussion at <a href="mailto:[email-masked]" target="_blank">[email-masked]</a>: <a href="https://www.ietf.org/mailman/listinfo/scap_interest" target="_blank">https://www.ietf.org/mailman/listinfo/scap_interest</a>. <br> <br>There is a need to accurately represent frameworks, and I'd like to see DISA and UCF join in the discussion. <br> <br>If you have any comments, questions, or concerns, feel free to contact me directly. <br> <br>Regards, <br> <br>Adam W. Montville | Security and Compliance Architect <br> <br>Direct: 503 276-7661 <br>Mobile: 360 471-7815 <br> <br>TRIPWIRE | Take CONTROL <br><a href="http://www.tripwire.com" target="_blank">http://www.tripwire.com</a> <br> <br>From: kent_landfield &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&lt;mailto:[email-masked]&gt;&gt; <br>Date: Tue, 14 Feb 2012 15:47:29 -0600 <br>To: Adam Montville &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&lt;mailto:[email-masked]&gt;&gt;, &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&lt;mailto:[email-masked]&gt;&gt; <br>Subject: Re: [scap_interest] Just throwing this out there: Compliance Frameworks <br> <br>Adam, <br> <br>I agree that an effort such as this has great potential.  Think of the content authors today. They use XML Editors or internally developed tools to create OVAL to do the compliance checking.  This is very time consuming and very costly, while limiting the available checks and benchmarks. <br> <br>If there was a means where all regulations and security policies could be universally mapped and the specifics around them, based on individual platforms, were also attached to each unified record, it is possible to auto generate not just the benchmarks but the individual checks.  Some of this research has been successful in the past.  This is doable. The problem has been there is not an authoritative source for that data. <br> <br>Today too many people are manually writing content that could be auto generated from a database with the right schema and software.  The problem though is as much on the front end as it is on the generation side.  Someone needs to maintain that information or have an infrastructure put in place where guidance authors for regulations or security policies can update their information in the shared datastore. <br> <br>I think this is one of the missing pieces and it may be useful to have a discussion with interested parties but you would need to include participants from the two mentioned efforts below. <br> <br>Kent Landfield <br>Director Content Strategy, Architecture and Standards <br> <br>McAfee | An Intel Company <br>5000 Headquarters Dr. <br>Plano, Texas 75024 <br> <br>Direct: +1.972.963.7096 <br>Mobile: +1.817.637.8026 <br>Web: www.mcafee.com&lt;<a href="http://www.mcafee.com/" target="_blank">http://www.mcafee.com/</a>&gt; <br> <br>From: Adam Montville &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&lt;mailto:[email-masked]&gt;&gt; <br>Date: Tue, 14 Feb 2012 15:09:34 -0600 <br>To: "<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&lt;mailto:[email-masked]&gt;" &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&lt;mailto:[email-masked]&gt;&gt; <br>Subject: [scap_interest] Just throwing this out there: Compliance Frameworks <br> <br>All, <br> <br>I had a brief discussion with several members of this list with respect to compliance frameworks, which met some resistance.  Still, I think presenting the idea to a larger audience to solicit feedback is a good idea. <br> <br>From an automation perspective, it seems that some method of being able to map benchmark-level tests to some higher level policy representation may be warranted.  At the end of the day, we perform assessments to ensure that we are in a secure state – to be compliant with a particular set of policies. <br> <br>Is there any interest in being able to represent a compliance framework with either a new specification or potentially revitalizing and extending an existing specification (CCI: <a href="http://iase.disa.mil/stigs/cci.html" target="_blank">http://iase.disa.mil/stigs/cci.html</a>), or to simply rely upon any existing commercial efforts, such as UCF (<a href="https://www.unifiedcompliance.com" target="_blank">https://www.unifiedcompliance.com</a>)? <br> <br>Or, is this type of representation simply not needed – there's enough there, the present demand doesn't justify the work, or something else? <br> <br>Thoughts? <br> <br>Regards, <br> <br>Adam W. Montville | Security and Compliance Architect <br> <br>Direct: 503 276-7661 <br>Mobile: 360 471-7815 <br> <br>TRIPWIRE | Take CONTROL <br><a href="http://www.tripwire.com" target="_blank">http://www.tripwire.com</a> <br> <br>_______________________________________________ <br>scap_interest mailing list <br><a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&lt;mailto:[email-masked]&gt; <br><a href="https://www.ietf.org/mailman/listinfo/scap_interest" target="_blank">https://www.ietf.org/mailman/listinfo/scap_interest</a> <br> <br> <br></blockquote><br></div></body></html>
------=_Part_10235_1835691541.1329322108785--

From: "Lloyd, Mike" <[email-masked]>
To: "'Luis Nunez'" <[email-masked]>, <[email-masked]>
Date: Wed, 15 Feb 2012 07:06:56 -0800 (PST)
Cc: [email-masked]
Subject: Re: [scap_interest] Gaps in Risk Management

------=_NextPart_000_17CC_01CCEBB0.6595A860
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

(Hopefully this is not a duplicate for most folks - I wrote a note below
while not yet a list member, but have since joined & cancelled my earlier
attempt to send.  I would be most interested in SCAP and metrics related
discussion with anyone attending either BSides or RSA in San Francisco
shortly.)

Mike

From: Lloyd, Mike [mailto:[email-masked]] 
Sent: Tuesday, February 14, 2012 3:36 PM
To: 'Luis Nunez'; [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: RE: [scap_interest] Gaps in Risk Management

Absolutely - thanks for adding me to the thread, Luis.  As Jerome noted,
I'm speaking at BSides - an event I've found can be quite worthwhile.
I'll also be speaking on the show floor at RSA (at the RedSeal Networks
booth), but the show floor talk will necessarily be much less detailed.
I'd be happy to discuss metrics with members of this group at either of
these venues, or online.

Some recent comments I made on metrics showed up here:

http://www.darkreading.com/security-monitoring/167901086/security/perimete
r-security/232600679/five-tactical-security-metrics-to-watch.html

For folks thinking about SCAP, I didn't highlight SCAP in that interview,
but I do see SCAP as a fundamental building block of the metrics I
recommend.  Specifically, correlation of CVE instances and correlation
with the CVSS framework are fundamental.  However, I find I have to build
a few layers on top of that - at first into the "environmental" component,
but eventually beyond that, because I need to generate not just metrics on
vulnerabilities, but also on hosts, and even for an entire network.

Anyone who has a BrightTalk login, or is willing to register for one, can
also review a recent webinar we recorded - a co-presentation by Mike
Rothman of Securosis (who covers general themes and difficulties) and
myself (covering our actual measurement approach, in a short segment at
the end):

http://www.brighttalk.com/webcast/7245/39267

Regards

Mike

From: Luis Nunez [mailto:[email-masked]] 
Sent: Tuesday, February 14, 2012 2:59 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Mike Lloyd
Subject: Re: [scap_interest] Gaps in Risk Management

Jerome,

great idea and thanks for mentioning this talk. It would be an interesting
discussion to have with Dr. Mike on the topic.  Lets hook up.

Since you mentioned Geer.  Here is an excellent talk Dan recent gave.
http://geer.tinho.net/geer.suitsandspooks.8ii12.txt

-ln

On Feb 14, 2012, at 5:47 PM, <[email-masked]> wrote:

Hi Jerome,

I think it is a really good idea to start from use cases and what we want
to get out of this work to drive the standards efforts.  The work being
done here should result in the ability to report on meaningful and
actionable metrics.  Brainstorming like this at the RSA Conference and on
list would be great.  Activities like this may be tied to the frameworks
as well - how do we get good risk metrics against the frameworks in which
we want to measure our security programs? 

Luis brought up CSA's control matrix, maybe we want to think about what
was done for 800-53 and how that could apply out to other frameworks like
ISO27002 +ISO27017 (Virtualization/cloud), HIPAA HITECH, etc.  performing
checks, assessing risk, and producing metrics are the drivers for these
underlying activities.

Dan Greer has some good presentations online related to metrics and is
running a series in IEE Security and Privacy on the topic as well.  I do
need to admit that I have to catch up on my reading, so I can't tell you
too much about that effort J

Any other thoughts on these topics?

Thanks,

Kathleen

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jerome Athias
Sent: Tuesday, February 14, 2012 5:34 PM
To: [email-masked]
Subject: Re: [scap_interest] Gaps in Risk Management

Hi list,

could it be possible to have a brainstorming at the RSA Conference?

or / because i identifed the following talk (at BSides San Francisco, //
free event):

Metrics That Don't Suck: A New Way To Measure Security Effectiveness ~ Dr.
Mike Lloyd

How does your organization measure and report its security posture and
performance?  Do you have spreadsheets that show how many vulnerabilities
you found last month, or how many viruses your AV system stopped? Those
numbers might pacify your management, but any security pro can tell you
that they are no way to benchmark the real work you do - or how much
danger your enterprise might be in.

Maybe the problem is that we're all trying to use the data we already have
- host metrics, network metrics, applications data - instead of building
the data we actually need.  We need metrics that show the current range of
threats, and the enterprise's exposure. We need data that shows whether
our security tools and programs are actually working or not. We need
methods for demonstrating that our security teams are performing well -
not only this month, but over a period of time.

In this thought-provoking presentation, we'll describe methods for
building an enterprise security metrics program that's completely
different from the current, sucky model of counting vulnerabilities or
numbers of patches applied. We'll outline methods for monitoring the
threat landscape, and your organization's exposure. We'll offer some best
practices for measuring the effectiveness of current security tools and
systems. Best of all, we'll outline a way to build a maturity model for
security, so that you can show your security team's performance on a
month-to-month basis, and demonstrate its continuing improvement over
time.

Want to stop reporting a bunch of crap and start building a real set of
data that accurately measures your organization's risk and its
effectiveness in controlling it?  Want to learn how to integrate security
data across hosts, networks, and applications?  Want your performance -
and your company's security posture - to be monitored using metrics that
don't suck?  Here's a chance to look at the picture from a whole new
angle.

(ref:
http://www.infosecisland.com/blogview/20057-Security-BSides-San-Francisco-
Speakers-and-Topics-Lineup.html )

I see these events as a good place to exchange our ideas.

Just my 2 cents

/JA

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

------=_NextPart_000_17CC_01CCEBB0.6595A860
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><base href="x-msg://2825/"><style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.apple-converted-space
	{mso-style-name:apple-converted-space;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle23
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(Hopefully this is not a duplicate for most folks &#8211; I wrote a note below while not yet a list member, but have since joined &amp; cancelled my earlier attempt to send.&nbsp; I would be most interested in SCAP and metrics related discussion with anyone attending either BSides or RSA in San Francisco shortly.)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Mike<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Lloyd, Mike [mailto:[email-masked]] <br><b>Sent:</b> Tuesday, February 14, 2012 3:36 PM<br><b>To:</b> 'Luis Nunez'; [email-masked]'<br><b>Cc:</b> [email-masked]'; [email-masked]'<br><b>Subject:</b> RE: [scap_interest] Gaps in Risk Management<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Absolutely &#8211; thanks for adding me to the thread, Luis.&nbsp; As Jerome noted, I&#8217;m speaking at BSides &#8211; an event I&#8217;ve found can be quite worthwhile.&nbsp; I&#8217;ll also be speaking on the show floor at RSA (at the RedSeal Networks booth), but the show floor talk will necessarily be much less detailed.&nbsp; I&#8217;d be happy to discuss metrics with members of this group at either of these venues, or online.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Some recent comments I made on metrics showed up here:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'><a href="http://www.darkreading.com/security-monitoring/167901086/security/perimeter-security/232600679/five-tactical-security-metrics-to-watch.html">http://www.darkreading.com/security-monitoring/167901086/security/perimeter-security/232600679/five-tactical-security-metrics-to-watch.html</a></span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>For folks thinking about SCAP, I didn&#8217;t highlight SCAP in that interview, but I do see SCAP as a fundamental building block of the metrics I recommend.&nbsp; Specifically, correlation of CVE instances and correlation with the CVSS framework are fundamental.&nbsp; However, I find I have to build a few layers on top of that &#8211; at first into the &#8220;environmental&#8221; component, but eventually beyond that, because I need to generate not just metrics on vulnerabilities, but also on hosts, and even for an entire network.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Anyone who has a BrightTalk login, or is willing to register for one, can also review a recent webinar we recorded &#8211; a co-presentation by Mike Rothman of Securosis (who covers general themes and difficulties) and myself (covering our actual measurement approach, in a short segment at the end):<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><a href="http://www.brighttalk.com/webcast/7245/39267">http://www.brighttalk.com/webcast/7245/39267</a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Regards<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Mike<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Luis Nunez <a href="mailto:[mailto:[email-masked]]">[mailto:[email-masked]]</a> <br><b>Sent:</b> Tuesday, February 14, 2012 2:59 PM<br><b>To:</b> <a href="mailto:[email-masked]">[email-masked]</a><br><b>Cc:</b> <a href="mailto:[email-masked]">[email-masked]</a>; <a href="mailto:[email-masked]">[email-masked]</a>; Mike Lloyd<br><b>Subject:</b> Re: [scap_interest] Gaps in Risk Management<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>Jerome,<o:p></o:p></p><div><p class=MsoNormal>great idea and thanks for mentioning this talk. It would be an interesting discussion to have with Dr. Mike on the topic. &nbsp;Lets hook up.<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>Since you mentioned Geer. &nbsp;Here is an excellent talk Dan recent gave.&nbsp;<a href="http://geer.tinho.net/geer.suitsandspooks.8ii12.txt">http://geer.tinho.net/geer.suitsandspooks.8ii12.txt</a><o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>-ln<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p><div><div><p class=MsoNormal>On Feb 14, 2012, at 5:47 PM, &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p>&nbsp;</o:p></p><div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi Jerome,</span><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;</span><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I think it is a really good idea to start from use cases and what we want to get out of this work to drive the standards efforts.&nbsp; The work being done here should result in the ability to report on meaningful and actionable metrics.&nbsp; Brainstorming like this at the RSA Conference and on list would be great.&nbsp; Activities like this may be tied to the frameworks as well &#8211; how do we get good risk metrics against the frameworks in which we want to measure our security programs?&nbsp;</span><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;</span><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Luis brought up CSA&#8217;s control matrix, maybe we want to think about what was done for 800-53 and how that could apply out to other frameworks like ISO27002 +ISO27017 (Virtualization/cloud), HIPAA HITECH, etc.&nbsp; performing checks, assessing risk, and producing metrics are the drivers for these underlying activities.</span><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;</span><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Dan Greer has some good presentations online related to metrics and is running a series in IEE Security and Privacy on the topic as well.&nbsp; I do need to admit that I have to catch up on my reading, so I can&#8217;t tell you too much about that effort<span class=apple-converted-space>&nbsp;</span></span><span style='font-size:11.0pt;font-family:Wingdings;color:#1F497D'>J</span><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;</span><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Any other thoughts on these topics?</span><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;</span><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks,</span><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Kathleen</span><span style='color:black'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;</span><span style='color:black'><o:p></o:p></span></p></div><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in;border-width:initial;border-color:initial'><div><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span class=apple-converted-space><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>&nbsp;</span></span><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'><a href="mailto:[email-masked]">[email-masked]</a> <a href="mailto:[mailto:[email-masked]]">[mailto:[email-masked]]</a><span class=apple-converted-space>&nbsp;</span><b>On Behalf Of<span class=apple-converted-space>&nbsp;</span></b>Jerome Athias<br><b>Sent:</b><span class=apple-converted-space>&nbsp;</span>Tuesday, February 14, 2012 5:34 PM<br><b>To:</b><span class=apple-converted-space>&nbsp;</span><a href="mailto:[email-masked]">[email-masked]</a><br><b>Subject:</b><span class=apple-converted-space>&nbsp;</span>Re: [scap_interest] Gaps in Risk Management</span><span style='color:black'><o:p></o:p></span></p></div></div></div><div><p class=MsoNormal><span style='color:black'>&nbsp;<o:p></o:p></span></p></div><p class=MsoNormal style='margin-bottom:12.0pt'><span style='color:black'>Hi list,<br><br>could it be possible to have a brainstorming at the RSA Conference?<br><br>or / because i identifed the following talk (at BSides San Francisco, // free event):<o:p></o:p></span></p><p><strong><u><span style='color:black'>Metrics That Don&#8217;t Suck: A New Way To Measure Security Effectiveness ~ Dr. Mike Lloyd</span></u></strong><span style='color:black'><o:p></o:p></span></p><p><span style='color:black'>How does your organization measure and report its security posture and performance?&nbsp; Do you have spreadsheets that show how many vulnerabilities you found last month, or how many viruses your AV system stopped? Those numbers might pacify your management, but any security pro can tell you that they are no way to benchmark the real work you do &#8211; or how much danger your enterprise might be in.<o:p></o:p></span></p><p><span style='color:black'>Maybe the problem is that we&#8217;re all trying to use the data we already have &#8211; host metrics, network metrics, applications data &#8211; instead of building the data we actually need.&nbsp; We need metrics that show the current range of threats, and the enterprise&#8217;s exposure. We need data that shows whether our security tools and programs are actually working or not. We need methods for demonstrating that our security teams are performing well &#8211; not only this month, but over a period of time.<o:p></o:p></span></p><p><span style='color:black'>In this thought-provoking presentation, we&#8217;ll describe methods for building an enterprise security metrics program that&#8217;s completely different from the current, sucky model of counting vulnerabilities or numbers of patches applied. We&#8217;ll outline methods for monitoring the threat landscape, and your organization&#8217;s exposure. We&#8217;ll offer some best practices for measuring the effectiveness of current security tools and systems. Best of all, we&#8217;ll outline a way to build a maturity model for security, so that you can show your security team&#8217;s performance on a month-to-month basis, and demonstrate its continuing improvement over time.<o:p></o:p></span></p><p><span style='color:black'>Want to stop reporting a bunch of crap and start building a real set of data that accurately measures your organization&#8217;s risk and its effectiveness in controlling it?&nbsp; Want to learn how to integrate security data across hosts, networks, and applications?&nbsp; Want your performance &#8211; and your company&#8217;s security posture &#8211; to be monitored using metrics that don&#8217;t suck?&nbsp; Here&#8217;s a chance to look at the picture from a whole new angle.<o:p></o:p></span></p><div><p class=MsoNormal><span style='color:black'>(ref:<span class=apple-converted-space>&nbsp;</span><a href="http://www.infosecisland.com/blogview/20057-Security-BSides-San-Francisco-Speakers-and-Topics-Lineup.html">http://www.infosecisland.com/blogview/20057-Security-BSides-San-Francisco-Speakers-and-Topics-Lineup.html</a><span class=apple-converted-space>&nbsp;</span>)<br><br>I see these events as a good place to exchange our ideas.<br><br>Just my 2 cents<br><br>/JA<o:p></o:p></span></p></div><p class=MsoNormal>_______________________________________________<br>scap_interest mailing list<br><a href="mailto:[email-masked]">[email-masked]</a><br><a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a><o:p></o:p></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div></div></body></html>
------=_NextPart_000_17CC_01CCEBB0.6595A860--

From: "Chernin, Michael A." <[email-masked]>
Accept-Language: en-US
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

--_000_E3EFB6C0D90F82478AF227AA85ECF38015ADCCE2SXEMBP01corpdtc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Kent, understood. Like the vendors, I do agree that certain standards need to go to IETF. But, today the only people that would be voting during IETF calls would be the federal government and security tool vendors. I am going to be hesitant in supporting a move of all standards until there are standards consumers (private sector customers) who will also be participating in IETF voting. I am trying to balance rapid development of standards using the IETF and complete vendor control of all standards. Once I see more consumer activity during voting, I will be more supportive of a large number of standards moving IETF.

I know I am early and jumping the gun on this, but I just wanted to get my story out there. At this time no standards have been specifically identified and no specific action is required at this time.

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust & Clearing Corporation
O: 813-470-2173

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, February 14, 2012 6:09 PM
To: Chernin, Michael A.; [email-masked]
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

>From my perspective TBD.

There are some that are unencumbered from and IPR perspective and those are potential candidates. Others will have to move as the appropriate consensus  is achieved and IPR issues are addressed.

The idea here from my perspective is to figure that out.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Michael Aharon Chernin <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 16:04:43 -0600
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [scap_interest] Scope of standards potentially moving to IETF

I am just going to jump right on out there and ask. Which standards are we looking to go to IETF? Specific SCAP standards or the entire SCAP umbrella?

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust & Clearing Corporation
O: 813-470-2173

<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>
_______________________________________________
scap_interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scap_interest

--_000_E3EFB6C0D90F82478AF227AA85ECF38015ADCCE2SXEMBP01corpdtc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Kent, understood. Like the vendors, I do agree that certain standards need to go to IETF. But, today the only people that would be voting during IETF calls
 would be the federal government and security tool vendors. I am going to be hesitant in supporting a move of all standards until there are standards consumers (private sector customers) who will also be participating in IETF voting. I am trying to balance
 rapid development of standards using the IETF and complete vendor control of all standards. Once I see more consumer activity during voting, I will be more supportive of a large number of standards moving IETF.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">I know I am early and jumping the gun on this, but I just wanted to get my story out there. At this time no standards have been specifically identified and
 no specific action is required at this time.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Aharon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">DTCC Non-Confidential (White)<br>
---------------------------------------------------<br>
Michael &quot;Aharon&quot; Chernin<br>
Security Automation Program Manager<br>
Corporate Information Security -Depository Trust &amp; Clearing Corporation<br>
O: 813-470-2173</span><span style="font-size:9.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> [email-masked] [mailto:[email-masked]]
<br>
<b>Sent:</b> Tuesday, February 14, 2012 6:09 PM<br>
<b>To:</b> Chernin, Michael A.; [email-masked]<br>
<b>Subject:</b> Re: [scap_interest] Scope of standards potentially moving to IETF<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="color:black">From my perspective TBD.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">There are some that are unencumbered from and IPR perspective and those are potential candidates. Others will have to move as the appropriate consensus &nbsp;is achieved and IPR issues are addressed.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">The idea here from my perspective is to figure that out. &nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><strong><span style="font-size:9.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#606A71">Kent Landfield</span></strong><span style="font-size:9.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#606A71"><br>
<span class="apple-style-span">Director Content Strategy, Architecture and Standards</span><br>
<br>
<strong><span style="font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">McAfee | An Intel Company</span></strong><br>
<span class="apple-style-span">5000 Headquarters Dr.</span><br>
<span class="apple-style-span">Plano, Texas 75024</span><br>
<br>
<span class="apple-style-span">Direct: &#43;1.972.963.7096&nbsp;</span><br>
<span class="apple-style-span">Mobile: &#43;1.817.637.8026</span><br>
<strong><span style="font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">Web:&nbsp;</span></strong><span class="apple-style-span"><a href="http://www.mcafee.com/">www.mcafee.com</a></span></span><span style="color:black"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">From:
</span></b><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">Michael Aharon Chernin &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<b>Date: </b>Tue, 14 Feb 2012 16:04:43 -0600<br>
<b>To: </b>&quot;<a href="mailto:[email-masked]">[email-masked]</a>&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<b>Subject: </b>[scap_interest] Scope of standards potentially moving to IETF<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<div>
<div>
<p class="MsoNormal"><span style="color:black">I am just going to jump right on out there and ask. Which standards are we looking to go to IETF? Specific SCAP standards or the entire SCAP umbrella?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Aharon<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">DTCC Non-Confidential (White)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">---------------------------------------------------<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Michael &quot;Aharon&quot; Chernin<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Security Automation Program Manager<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Corporate Information Security -Depository Trust &amp; Clearing Corporation<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">O: 813-470-2173<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">&lt;BR&gt;_____________________________________________________________<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">&lt;FONT size=2&gt;&lt;BR&gt;<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">DTCC DISCLAIMER: This email and any files transmitted with it are<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">confidential and intended solely for the use of the individual or<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">entity to whom they are addressed. If you have received this email<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">in error, please notify us immediately and delete the email and any<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">attachments from your system. The recipient should check this email<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">and any attachments for the presence of viruses.&nbsp;&nbsp;The company<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">accepts no liability for any damage caused by any virus transmitted<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">by this email.&lt;/FONT&gt;<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">_______________________________________________<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">scap_interest mailing list<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><a href="mailto:[email-masked]">[email-masked]</a><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>

--_000_E3EFB6C0D90F82478AF227AA85ECF38015ADCCE2SXEMBP01corpdtc_--

From: Adam Montville <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: [scap_interest] FW: Just throwing this out there: Compliance Frameworks

Hello,

If you're not already aware, there is an effort underway to migrate security automation development to the Internet Engineering Task Force.  I have proposed that part of that effort seek to expand how frameworks can be represented.  I believe that CCI and/or  UCF formats may be of use and invite you to join the discussion at [email-masked]: https://www.ietf.org/mailman/listinfo/scap_interest.

There is a need to accurately represent frameworks, and I'd like to see DISA and UCF join in the discussion.

If you have any comments, questions, or concerns, feel free to contact me directly.

Regards,

Adam W. Montville | Security and Compliance Architect

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

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

From: kent_landfield <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 15:47:29 -0600
To: Adam Montville <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Just throwing this out there: Compliance Frameworks

Adam,

I agree that an effort such as this has great potential.  Think of the content authors today. They use XML Editors or internally developed tools to create OVAL to do the compliance checking.  This is very time consuming and very costly, while limiting the available checks and benchmarks.

If there was a means where all regulations and security policies could be universally mapped and the specifics around them, based on individual platforms, were also attached to each unified record, it is possible to auto generate not just the benchmarks but the individual checks.  Some of this research has been successful in the past.  This is doable. The problem has been there is not an authoritative source for that data.

Today too many people are manually writing content that could be auto generated from a database with the right schema and software.  The problem though is as much on the front end as it is on the generation side.  Someone needs to maintain that information or have an infrastructure put in place where guidance authors for regulations or security policies can update their information in the shared datastore.

I think this is one of the missing pieces and it may be useful to have a discussion with interested parties but you would need to include participants from the two mentioned efforts below.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Adam Montville <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 15:09:34 -0600
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [scap_interest] Just throwing this out there: Compliance Frameworks

All,

I had a brief discussion with several members of this list with respect to compliance frameworks, which met some resistance.  Still, I think presenting the idea to a larger audience to solicit feedback is a good idea.

>From an automation perspective, it seems that some method of being able to map benchmark-level tests to some higher level policy representation may be warranted.  At the end of the day, we perform assessments to ensure that we are in a secure state � to be compliant with a particular set of policies.

Is there any interest in being able to represent a compliance framework with either a new specification or potentially revitalizing and extending an existing specification (CCI: http://iase.disa.mil/stigs/cci.html), or to simply rely upon any existing commercial efforts, such as UCF (https://www.unifiedcompliance.com)?

Or, is this type of representation simply not needed � there's enough there, the present demand doesn't justify the work, or something else?

Thoughts?

Regards,

Adam W. Montville | Security and Compliance Architect

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

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

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

From: Adam Montville <[email-masked]>
To: Luis Nunez <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 15 Feb 2012 13:57:45 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, Mike Lloyd <[email-masked]>
Subject: Re: [scap_interest] Gaps in Risk Management

Brainstorming at RSA is an excellent idea.  I'd like to additionally look at what was done with risk external to the information security domain.

From: Luis Nunez <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 17:59:26 -0500
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Mike Lloyd <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Gaps in Risk Management

Jerome,
great idea and thanks for mentioning this talk. It would be an interesting discussion to have with Dr. Mike on the topic.  Lets hook up.

Since you mentioned Geer.  Here is an excellent talk Dan recent gave. http://geer.tinho.net/geer.suitsandspooks.8ii12.txt

-ln

On Feb 14, 2012, at 5:47 PM, <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jerome,

I think it is a really good idea to start from use cases and what we want to get out of this work to drive the standards efforts.  The work being done here should result in the ability to report on meaningful and actionable metrics.  Brainstorming like this at the RSA Conference and on list would be great.  Activities like this may be tied to the frameworks as well � how do we get good risk metrics against the frameworks in which we want to measure our security programs?

Luis brought up CSA�s control matrix, maybe we want to think about what was done for 800-53 and how that could apply out to other frameworks like ISO27002 +ISO27017 (Virtualization/cloud), HIPAA HITECH, etc.  performing checks, assessing risk, and producing metrics are the drivers for these underlying activities.

Dan Greer has some good presentations online related to metrics and is running a series in IEE Security and Privacy on the topic as well.  I do need to admit that I have to catch up on my reading, so I can�t tell you too much about that effort :)

Any other thoughts on these topics?

Thanks,
Kathleen

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jerome Athias
Sent: Tuesday, February 14, 2012 5:34 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [scap_interest] Gaps in Risk Management

Hi list,

could it be possible to have a brainstorming at the RSA Conference?

or / because i identifed the following talk (at BSides San Francisco, // free event):

Metrics That Don�t Suck: A New Way To Measure Security Effectiveness ~ Dr. Mike Lloyd

How does your organization measure and report its security posture and performance?  Do you have spreadsheets that show how many vulnerabilities you found last month, or how many viruses your AV system stopped? Those numbers might pacify your management, but any security pro can tell you that they are no way to benchmark the real work you do � or how much danger your enterprise might be in.

Maybe the problem is that we�re all trying to use the data we already have � host metrics, network metrics, applications data � instead of building the data we actually need.  We need metrics that show the current range of threats, and the enterprise�s exposure. We need data that shows whether our security tools and programs are actually working or not. We need methods for demonstrating that our security teams are performing well � not only this month, but over a period of time.

In this thought-provoking presentation, we�ll describe methods for building an enterprise security metrics program that�s completely different from the current, sucky model of counting vulnerabilities or numbers of patches applied. We�ll outline methods for monitoring the threat landscape, and your organization�s exposure. We�ll offer some best practices for measuring the effectiveness of current security tools and systems. Best of all, we�ll outline a way to build a maturity model for security, so that you can show your security team�s performance on a month-to-month basis, and demonstrate its continuing improvement over time.

Want to stop reporting a bunch of crap and start building a real set of data that accurately measures your organization�s risk and its effectiveness in controlling it?  Want to learn how to integrate security data across hosts, networks, and applications?  Want your performance � and your company�s security posture � to be monitored using metrics that don�t suck?  Here�s a chance to look at the picture from a whole new angle.

(ref: http://www.infosecisland.com/blogview/20057-Security-BSides-San-Francisco-Speakers-and-Topics-Lineup.html )

I see these events as a good place to exchange our ideas.

Just my 2 cents

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

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

Date: Tue, 14 Feb 2012 18:22:46 -0500
From: Sean Turner <[email-masked]>
To: [email-masked]

I'd add copyright and change control to the list of issues to be 
considered when adopting specs.

spt

On 2/14/12 6:08 PM, [email-masked] wrote:
>  From my perspective TBD.
>
> There are some that are unencumbered from and IPR perspective and those
> are potential candidates. Others will have to move as the appropriate
> consensus is achieved and IPR issues are addressed.
>
> The idea here from my perspective is to figure that out.
>
> *Kent Landfield*
> Director Content Strategy, Architecture and Standards
>
> *McAfee | An Intel Company*
> 5000 Headquarters Dr.
> Plano, Texas 75024
>
> Direct: +1.972.963.7096
> Mobile: +1.817.637.8026
> *Web: *www.mcafee.com <http://www.mcafee.com/>
>
> From: Michael Aharon Chernin <[email-masked] <mailto:[email-masked]>>
> Date: Tue, 14 Feb 2012 16:04:43 -0600
> To: "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> Subject: [scap_interest] Scope of standards potentially moving to IETF
>
>     I am just going to jump right on out there and ask. Which standards
>     are we looking to go to IETF? Specific SCAP standards or the entire
>     SCAP umbrella?
>
>     Aharon
>
>     DTCC Non-Confidential (White)
>     ---------------------------------------------------
>     Michael "Aharon" Chernin
>     Security Automation Program Manager
>     Corporate Information Security -Depository Trust & Clearing Corporation
>     O: 813-470-2173
>
>     <BR>_____________________________________________________________
>     <FONT size=2><BR>
>     DTCC DISCLAIMER: This email and any files transmitted with it are
>     confidential and intended solely for the use of the individual or
>     entity to whom they are addressed. If you have received this email
>     in error, please notify us immediately and delete the email and any
>     attachments from your system. The recipient should check this email
>     and any attachments for the presence of viruses. The company
>     accepts no liability for any damage caused by any virus transmitted
>     by this email.</FONT>
>     _______________________________________________
>     scap_interest mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/scap_interest
>
>
>
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest

From: "Waltermire, David A." <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 14 Feb 2012 18:14:35 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Checking language needs

--_000_D7A0423E5E193F40BE6E94126930C4930906AEA3A2MBCLUSTERxcha_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

A checking client would be something like an XCCDF or a CPE Applicability Language processor.

Dave

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, February 14, 2012 5:53 PM
To: Waltermire, David A.; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [scap_interest] Checking language needs

Dave,

What is your definition of checking clients and checking systems?  I want to make sure I understand. I think we are on the same page but wanted to make sure...

Thanks.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: David Waltermire <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 15:47:44 -0600
To: Adam Montville <[email-masked]<mailto:[email-masked]>>, Kent Landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [scap_interest] Checking language needs

The issues we are discussing can be grouped into the following separate, but related functional areas.  Each should be treated as a separate concern.  Here are some ideas on how to parse out each area:

1) Defining a "checking design pattern" - This de facto pattern is used without a formal specification in many specifications including: XCCDF and the CPE 2.3 Applicability Language.  If we define the pattern properly, establishing a contract between checking clients and checking systems, we can stabilize our existing uses and provide a new foundation for additional checking uses cases.  This may also have the effect of stimulating novel checking solutions for mobile and network devices.  It may also make sense to look at breaking up the logical evaluation capabilities that share some commonality across XCCDF, OVAL and OCIL into a separate specification.  We have talked in the past about using the results of one check system to drive the behavior of another.  This type of approach might provide a mechanism to support that.

2) Enterprise targeting of assets - We currently have no standardized way to associate a checklist and/or a collection of checks with a set of assets that need to be interrogated to determine compliance.  This is definitely a problem for OCIL, but the approach is not formalized for OVAL checks either.  The closest thing we have is the applicability approach used in XCCDF which is not a targeting solution.  I would argue that applicability is something altogether different from targeting.  Applicability allows machine readable guidance to be pre-qualified as being purposed for scanning specific software.  What we desire from a targeting perspective is assignment of a checklist to a collection of assets that contain the applicable software.  Applicability can be used to determine what CAN be assigned, but it is not THE assignment.  It serves a separate purpose.  If we confound applicability and assignment, we risk creating checklists that are specific to an asset instead of being applicable to many assets.  This will hinder content reuse and exacerbate content management challenges.

Instead, it might be better to develop a new higher-level concept that enables definition of organizational digital policy that links rules in a checklist or checks to the appropriate assets that need to be assessed perhaps using ai:asset constructs.  For OCIL the asset in question could be the systems admin that is responsible for a set of hosts.  For OVAL the asset mapping might be to a domain server that provides group policy for a collection of hosts, or a directory server that provides authentication capabilities.  This policy can also indicate the frequency, conditions and timing of assessments, allowing automated tasks to be dispatched based on this information to enact the policy.

3) Tasking and scheduling - Based on the digital policy from the previous item, automated tasks can be created external to scanning applications to instruct them to perform a single scan, a recurring scan, establish a schedule based on a calendar or other conditions (e.g., CPU utilization, network load, etc).  By defining tasking as a separate concern from the assessment content, an organization will have the ability to orchestrate the assessment of a checklists or a collection of checks against many different sets of assets (e.g., people, systems, networks, devices) using independent tasks.  They can also use the same standardized approach to orchestrate different scanning solutions within their environments. This further promotes content reuse and avoids the need to customize content for a specific scanning task or solution.

My hope is that the MILE GRC Exchange specification can be shapped to support a high-level framework that allows detailed task messages to be exchanged using more specialized models (e.g., assessment, remdiation, etc.) as GRC message payloads.

Dave Waltermire

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, February 14, 2012 3:50 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [scap_interest] Checking language needs

Kent,

I think scheduling should be a separate concern, but can see targeting being embedded in the checking system, much as it is today in OVAL (in a way, the inventory definitions perform the targeting for technical checks).  If we were to leverage Asset Identification, the targeting could be handled in some cases with a simple ai:asset reference - a person is targeted as the owner of the given system.

Adam

From: kent_landfield <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Date: Tue, 14 Feb 2012 14:30:27 -0600
To: <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Cc: <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Subject: Re: [scap_interest] Checking language needs

Thanks Karen!  I'll take you up on that!

>From the standpoint of what should be included beyond the actual integration issues, should this document, in addition to integration, discuss issues such as targeting and scheduling for interrogative checking systems like OCIL or would folks consider that a separate issue to be dealt with somewhere else?

Thoughts?

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Karen Scarfone <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Date: Tue, 14 Feb 2012 14:11:21 -0600
To: Kent Landfield <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Cc: "[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>>
Subject: Re: [scap_interest] Checking language needs

Kent,

I'd be happy to help with the publication/editing side of specification development.

Karen

On Tue, Feb 14, 2012 at 3:02 PM, <[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]%3e>> wrote:
All,

One of the missing pieces we have right now is a standardized approach to developing new checking languages.  Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF.  The later's adoption rate has been seriously impacted because of that.  Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages.  Scripting is also being done directly from XCCDF benchmarks by multiple vendor products.

As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means.  Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today.  Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting.  Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches.  Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.

>From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place.  We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate effectively.  By specifying the practices and items  new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.

I am looking for interest here and for those that might want to help me in producing this draft specification.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

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

--
Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>   (703)401-1018

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

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

--_000_D7A0423E5E193F40BE6E94126930C4930906AEA3A2MBCLUSTERxcha_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: base64

--_000_D7A0423E5E193F40BE6E94126930C4930906AEA3A2MBCLUSTERxcha_--

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Tue, 14 Feb 2012 17:08:45 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [scap_interest] Scope of standards potentially moving to IETF

--_000_CB6042FB2C620kentlandfieldmcafeecom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

>From my perspective TBD.

There are some that are unencumbered from and IPR perspective and those are potential candidates. Others will have to move as the appropriate consensus  is achieved and IPR issues are addressed.

The idea here from my perspective is to figure that out.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Michael Aharon Chernin <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 16:04:43 -0600
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [scap_interest] Scope of standards potentially moving to IETF

I am just going to jump right on out there and ask. Which standards are we looking to go to IETF? Specific SCAP standards or the entire SCAP umbrella?

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust & Clearing Corporation
O: 813-470-2173

<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>
_______________________________________________
scap_interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scap_interest

--_000_CB6042FB2C620kentlandfieldmcafeecom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-family: 'Times New Roman', sans-serif; "><div><div><div>From my perspective TBD.</div><div><br></div><div>There are some that are unencumbered from and IPR perspective and those are potential candidates. Others will have to move as the appropriate consensus &nbsp;is achieved and IPR issues are addressed.</div><div><br></div><div>The idea here from my perspective is to figure that out. &nbsp;</div><div><br></div><div><div><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Kent Landfield</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Director Content Strategy, Architecture and Standards</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>McAfee | An Intel Company</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">5000 Headquarters Dr.</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Plano, Texas 75024</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Direct: +1.972.963.7096&nbsp;</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Mobile: +1.817.637.8026</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Web:&nbsp;</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><a href="http://www.mcafee.com/" style="color: rgb(96, 106, 113) !important; ">www.mcafee.com</a></span></div></div></div></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Michael Aharon Chernin &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Date: </span> Tue, 14 Feb 2012 16:04:43 -0600<br><span style="font-weight:bold">To: </span> "<a href="mailto:[email-masked]">[email-masked]</a>" &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Subject: </span> [scap_interest] Scope of standards potentially moving to IETF<br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div><div>I am just going to jump right on out there and ask. Which standards are we looking to go to IETF? Specific SCAP standards or the entire SCAP umbrella?</div><div><br></div><div>Aharon</div><div><br></div><div>DTCC Non-Confidential (White)</div><div>---------------------------------------------------</div><div>Michael "Aharon" Chernin</div><div>Security Automation Program Manager</div><div>Corporate Information Security -Depository Trust &amp; Clearing Corporation</div><div>O: 813-470-2173</div><div><br></div><div>&lt;BR&gt;_____________________________________________________________</div><div>&lt;FONT size=2&gt;&lt;BR&gt;</div><div>DTCC DISCLAIMER: This email and any files transmitted with it are</div><div>confidential and intended solely for the use of the individual or</div><div>entity to whom they are addressed. If you have received this email</div><div>in error, please notify us immediately and delete the email and any</div><div>attachments from your system. The recipient should check this email</div><div>and any attachments for the presence of viruses.&nbsp;&nbsp;The company</div><div>accepts no liability for any damage caused by any virus transmitted</div><div>by this email.&lt;/FONT&gt;</div><div>_______________________________________________</div><div>scap_interest mailing list</div><div><a href="mailto:[email-masked]">[email-masked]</a></div><div><a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a></div><div><br></div></div></div></blockquote></span></body></html>

--_000_CB6042FB2C620kentlandfieldmcafeecom_--

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Tue, 14 Feb 2012 18:03:46 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [scap_interest] Checking language needs

From: Luis Nunez <[email-masked]>
Date: Tue, 14 Feb 2012 17:59:26 -0500
To: <[email-masked]>
Cc: Mike Lloyd <[email-masked]>, [email-masked]
Subject: Re: [scap_interest] Gaps in Risk Management

--Apple-Mail=_B43A1172-4C51-406A-9595-A63EC9A9C47E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Jerome,
great idea and thanks for mentioning this talk. It would be an interesting discussion to have with Dr. Mike on the topic.  Lets hook up.

Since you mentioned Geer.  Here is an excellent talk Dan recent gave. http://geer.tinho.net/geer.suitsandspooks.8ii12.txt

-ln

On Feb 14, 2012, at 5:47 PM, <[email-masked]> wrote:

> Hi Jerome,
>  
> I think it is a really good idea to start from use cases and what we want to get out of this work to drive the standards efforts.  The work being done here should result in the ability to report on meaningful and actionable metrics.  Brainstorming like this at the RSA Conference and on list would be great.  Activities like this may be tied to the frameworks as well � how do we get good risk metrics against the frameworks in which we want to measure our security programs? 
>  
> Luis brought up CSA�s control matrix, maybe we want to think about what was done for 800-53 and how that could apply out to other frameworks like ISO27002 +ISO27017 (Virtualization/cloud), HIPAA HITECH, etc.  performing checks, assessing risk, and producing metrics are the drivers for these underlying activities.
>  
> Dan Greer has some good presentations online related to metrics and is running a series in IEE Security and Privacy on the topic as well.  I do need to admit that I have to catch up on my reading, so I can�t tell you too much about that effort J
>  
> Any other thoughts on these topics?
>  
> Thanks,
> Kathleen
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jerome Athias
> Sent: Tuesday, February 14, 2012 5:34 PM
> To: [email-masked]
> Subject: Re: [scap_interest] Gaps in Risk Management
>  
> Hi list,
> 
> could it be possible to have a brainstorming at the RSA Conference?
> 
> or / because i identifed the following talk (at BSides San Francisco, // free event):
> 
> Metrics That Don�t Suck: A New Way To Measure Security Effectiveness ~ Dr. Mike Lloyd
> 
> How does your organization measure and report its security posture and performance?  Do you have spreadsheets that show how many vulnerabilities you found last month, or how many viruses your AV system stopped? Those numbers might pacify your management, but any security pro can tell you that they are no way to benchmark the real work you do � or how much danger your enterprise might be in.
> 
> Maybe the problem is that we�re all trying to use the data we already have � host metrics, network metrics, applications data � instead of building the data we actually need.  We need metrics that show the current range of threats, and the enterprise�s exposure. We need data that shows whether our security tools and programs are actually working or not. We need methods for demonstrating that our security teams are performing well � not only this month, but over a period of time.
> 
> In this thought-provoking presentation, we�ll describe methods for building an enterprise security metrics program that�s completely different from the current, sucky model of counting vulnerabilities or numbers of patches applied. We�ll outline methods for monitoring the threat landscape, and your organization�s exposure. We�ll offer some best practices for measuring the effectiveness of current security tools and systems. Best of all, we�ll outline a way to build a maturity model for security, so that you can show your security team�s performance on a month-to-month basis, and demonstrate its continuing improvement over time.
> 
> Want to stop reporting a bunch of crap and start building a real set of data that accurately measures your organization�s risk and its effectiveness in controlling it?  Want to learn how to integrate security data across hosts, networks, and applications?  Want your performance � and your company�s security posture � to be monitored using metrics that don�t suck?  Here�s a chance to look at the picture from a whole new angle.
> 
> (ref: http://www.infosecisland.com/blogview/20057-Security-BSides-San-Francisco-Speakers-and-Topics-Lineup.html )
> 
> I see these events as a good place to exchange our ideas.
> 
> Just my 2 cents
> 
> /JA
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest

--Apple-Mail=_B43A1172-4C51-406A-9595-A63EC9A9C47E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><base href="x-msg://2825/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Jerome,<div>great idea and thanks for mentioning this talk. It would be an interesting discussion to have with Dr. Mike on the topic. &nbsp;Lets hook up.</div><div><br></div><div>Since you mentioned Geer. &nbsp;Here is an excellent talk Dan recent gave.&nbsp;<a href="http://geer.tinho.net/geer.suitsandspooks.8ii12.txt">http://geer.tinho.net/geer.suitsandspooks.8ii12.txt</a></div><div><br></div><div>-ln</div><div><br><div><div>On Feb 14, 2012, at 5:47 PM, &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div bgcolor="white" lang="EN-US" link="blue" vlink="purple"><div class="WordSection1" style="page: WordSection1; "><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Hi Jerome,<o:p></o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">I think it is a really good idea to start from use cases and what we want to get out of this work to drive the standards efforts.&nbsp; The work being done here should result in the ability to report on meaningful and actionable metrics.&nbsp; Brainstorming like this at the RSA Conference and on list would be great.&nbsp; Activities like this may be tied to the frameworks as well � how do we get good risk metrics against the frameworks in which we want to measure our security programs?&nbsp;<o:p></o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Luis brought up CSA�s control matrix, maybe we want to think about what was done for 800-53 and how that could apply out to other frameworks like ISO27002 +ISO27017 (Virtualization/cloud), HIPAA HITECH, etc.&nbsp; performing checks, assessing risk, and producing metrics are the drivers for these underlying activities.<o:p></o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Dan Greer has some good presentations online related to metrics and is running a series in IEE Security and Privacy on the topic as well.&nbsp; I do need to admit that I have to catch up on my reading, so I can�t tell you too much about that effort<span class="Apple-converted-space">&nbsp;</span></span><span style="font-size: 11pt; font-family: Wingdings; color: rgb(31, 73, 125); ">J</span><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p></o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Any other thoughts on these topics?<o:p></o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Thanks,<o:p></o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Kathleen<o:p></o:p></span></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; margin-top: 0in; margin-bottom: 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></div><div><div style="border-right-style: none; border-bottom-style: none; border-left-style: none; border-width: initial; border-color: initial; border-top-style: solid; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding-top: 3pt; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; "><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; margin-top: 0in; margin-bottom: 0.0001pt; "><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: windowtext; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: windowtext; "><span class="Apple-converted-space">&nbsp;</span><a href="mailto:[email-masked]">[email-masked]</a> [mailto:[email-masked]]<span class="Apple-converted-space">&nbsp;</span><b>On Behalf Of<span class="Apple-converted-space">&nbsp;</span></b>Jerome Athias<br><b>Sent:</b><span class="Apple-converted-space">&nbsp;</span>Tuesday, February 14, 2012 5:34 PM<br><b>To:</b><span class="Apple-converted-space">&nbsp;</span><a href="mailto:[email-masked]">[email-masked]</a><br><b>Subject:</b><span class="Apple-converted-space">&nbsp;</span>Re: [scap_interest] Gaps in Risk Management<o:p></o:p></span></div></div></div><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; margin-top: 0in; margin-bottom: 0.0001pt; "><o:p>&nbsp;</o:p></div><p class="MsoNormal" style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; margin-top: 0in; margin-bottom: 12pt; ">Hi list,<br><br>could it be possible to have a brainstorming at the RSA Conference?<br><br>or / because i identifed the following talk (at BSides San Francisco, // free event):<o:p></o:p></p><p style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; "><strong><u>Metrics That Don�t Suck: A New Way To Measure Security Effectiveness ~ Dr. Mike Lloyd</u></strong><o:p></o:p></p><p style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; ">How does your organization measure and report its security posture and performance?&nbsp; Do you have spreadsheets that show how many vulnerabilities you found last month, or how many viruses your AV system stopped? Those numbers might pacify your management, but any security pro can tell you that they are no way to benchmark the real work you do � or how much danger your enterprise might be in.<o:p></o:p></p><p style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; ">Maybe the problem is that we�re all trying to use the data we already have � host metrics, network metrics, applications data � instead of building the data we actually need.&nbsp; We need metrics that show the current range of threats, and the enterprise�s exposure. We need data that shows whether our security tools and programs are actually working or not. We need methods for demonstrating that our security teams are performing well � not only this month, but over a period of time.<o:p></o:p></p><p style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; ">In this thought-provoking presentation, we�ll describe methods for building an enterprise security metrics program that�s completely different from the current, sucky model of counting vulnerabilities or numbers of patches applied. We�ll outline methods for monitoring the threat landscape, and your organization�s exposure. We�ll offer some best practices for measuring the effectiveness of current security tools and systems. Best of all, we�ll outline a way to build a maturity model for security, so that you can show your security team�s performance on a month-to-month basis, and demonstrate its continuing improvement over time.<o:p></o:p></p><p style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; ">Want to stop reporting a bunch of crap and start building a real set of data that accurately measures your organization�s risk and its effectiveness in controlling it?&nbsp; Want to learn how to integrate security data across hosts, networks, and applications?&nbsp; Want your performance � and your company�s security posture � to be monitored using metrics that don�t suck?&nbsp; Here�s a chance to look at the picture from a whole new angle.<o:p></o:p></p><div style="margin-right: 0in; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; color: black; margin-top: 0in; margin-bottom: 0.0001pt; ">(ref:<span class="Apple-converted-space">&nbsp;</span><a href="http://www.infosecisland.com/blogview/20057-Security-BSides-San-Francisco-Speakers-and-Topics-Lineup.html" style="color: blue; text-decoration: underline; ">http://www.infosecisland.com/blogview/20057-Security-BSides-San-Francisco-Speakers-and-Topics-Lineup.html</a><span class="Apple-converted-space">&nbsp;</span>)<br><br>I see these events as a good place to exchange our ideas.<br><br>Just my 2 cents<br><br>/JA<o:p></o:p></div></div>_______________________________________________<br>scap_interest mailing list<br><a href="mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.org/mailman/listinfo/scap_interest</div></blockquote></div><br></div></body></html>
--Apple-Mail=_B43A1172-4C51-406A-9595-A63EC9A9C47E--

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Tue, 14 Feb 2012 16:53:14 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: [email-masked]
Subject: Re: [scap_interest] Checking language needs

--_000_CB6034F82C592kentlandfieldmcafeecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Dave,

What is your definition of checking clients and checking systems?  I want to make sure I understand. I think we are on the same page but wanted to make sure�

Thanks.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: David Waltermire <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 15:47:44 -0600
To: Adam Montville <[email-masked]<mailto:[email-masked]>>, Kent Landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [scap_interest] Checking language needs

The issues we are discussing can be grouped into the following separate, but related functional areas.  Each should be treated as a separate concern.  Here are some ideas on how to parse out each area:

1) Defining a "checking design pattern" - This de facto pattern is used without a formal specification in many specifications including: XCCDF and the CPE 2.3 Applicability Language.  If we define the pattern properly, establishing a contract between checking clients and checking systems, we can stabilize our existing uses and provide a new foundation for additional checking uses cases.  This may also have the effect of stimulating novel checking solutions for mobile and network devices.  It may also make sense to look at breaking up the logical evaluation capabilities that share some commonality across XCCDF, OVAL and OCIL into a separate specification.  We have talked in the past about using the results of one check system to drive the behavior of another.  This type of approach might provide a mechanism to support that.

2) Enterprise targeting of assets - We currently have no standardized way to associate a checklist and/or a collection of checks with a set of assets that need to be interrogated to determine compliance.  This is definitely a problem for OCIL, but the approach is not formalized for OVAL checks either.  The closest thing we have is the applicability approach used in XCCDF which is not a targeting solution.  I would argue that applicability is something altogether different from targeting.  Applicability allows machine readable guidance to be pre-qualified as being purposed for scanning specific software.  What we desire from a targeting perspective is assignment of a checklist to a collection of assets that contain the applicable software.  Applicability can be used to determine what CAN be assigned, but it is not THE assignment.  It serves a separate purpose.  If we confound applicability and assignment, we risk creating checklists that are specific to an asset instead of being applicable to many assets.  This will hinder content reuse and exacerbate content management challenges.

Instead, it might be better to develop a new higher-level concept that enables definition of organizational digital policy that links rules in a checklist or checks to the appropriate assets that need to be assessed perhaps using ai:asset constructs.  For OCIL the asset in question could be the systems admin that is responsible for a set of hosts.  For OVAL the asset mapping might be to a domain server that provides group policy for a collection of hosts, or a directory server that provides authentication capabilities.  This policy can also indicate the frequency, conditions and timing of assessments, allowing automated tasks to be dispatched based on this information to enact the policy.

3) Tasking and scheduling - Based on the digital policy from the previous item, automated tasks can be created external to scanning applications to instruct them to perform a single scan, a recurring scan, establish a schedule based on a calendar or other conditions (e.g., CPU utilization, network load, etc).  By defining tasking as a separate concern from the assessment content, an organization will have the ability to orchestrate the assessment of a checklists or a collection of checks against many different sets of assets (e.g., people, systems, networks, devices) using independent tasks.  They can also use the same standardized approach to orchestrate different scanning solutions within their environments. This further promotes content reuse and avoids the need to customize content for a specific scanning task or solution.

My hope is that the MILE GRC Exchange specification can be shapped to support a high-level framework that allows detailed task messages to be exchanged using more specialized models (e.g., assessment, remdiation, etc.) as GRC message payloads.

Dave Waltermire

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, February 14, 2012 3:50 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [scap_interest] Checking language needs

Kent,

I think scheduling should be a separate concern, but can see targeting being embedded in the checking system, much as it is today in OVAL (in a way, the inventory definitions perform the targeting for technical checks).  If we were to leverage Asset Identification, the targeting could be handled in some cases with a simple ai:asset reference - a person is targeted as the owner of the given system.

Adam

From: kent_landfield <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 14:30:27 -0600
To: <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Subject: Re: [scap_interest] Checking language needs

Thanks Karen!  I'll take you up on that!

>From the standpoint of what should be included beyond the actual integration issues, should this document, in addition to integration, discuss issues such as targeting and scheduling for interrogative checking systems like OCIL or would folks consider that a separate issue to be dealt with somewhere else?

Thoughts?

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Karen Scarfone <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 14:11:21 -0600
To: Kent Landfield <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]><mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Subject: Re: [scap_interest] Checking language needs

Kent,

I'd be happy to help with the publication/editing side of specification development.

Karen

On Tue, Feb 14, 2012 at 3:02 PM, <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:
All,

One of the missing pieces we have right now is a standardized approach to developing new checking languages.  Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF.  The later's adoption rate has been seriously impacted because of that.  Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages.  Scripting is also being done directly from XCCDF benchmarks by multiple vendor products.

As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means.  Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today.  Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting.  Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches.  Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.

>From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place.  We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate effectively.  By specifying the practices and items  new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.

I am looking for interest here and for those that might want to help me in producing this draft specification.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

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

--
Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>   (703)401-1018

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

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

--_000_CB6034F82C592kentlandfieldmcafeecom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-family: 'Times New Roman', sans-serif; "><div><div><div>Dave,</div><div><br></div><div>What is your definition of checking clients and checking systems? &nbsp;I want to make sure I understand. I think we are on the same page but wanted to make sure�</div><div><br></div><div>Thanks.</div><div><br></div><div><div><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Kent Landfield</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Director Content Strategy, Architecture and Standards</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>McAfee | An Intel Company</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">5000 Headquarters Dr.</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Plano, Texas 75024</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Direct: &#43;1.972.963.7096&nbsp;</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Mobile: &#43;1.817.637.8026</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Web:&nbsp;</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><a href="http://www.mcafee.com/" style="color: rgb(96, 106, 113) !important; ">www.mcafee.com</a></span></div></div></div></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> David Waltermire &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Date: </span> Tue, 14 Feb 2012 15:47:44 -0600<br><span style="font-weight:bold">To: </span> Adam Montville &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;, Kent  Landfield &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;, &quot;<a href="mailto:[email-masked]">[email-masked]</a>&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Cc: </span> &quot;<a href="mailto:[email-masked]">[email-masked]</a>&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Subject: </span> RE: [scap_interest] Checking language needs<br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div><div>The issues we are discussing can be grouped into the following separate, but related functional areas.&nbsp;&nbsp;Each should be treated as a separate concern.&nbsp;&nbsp;Here are some ideas on how to parse out each area:</div><div><br></div><div>1) Defining a &quot;checking design pattern&quot; - This de facto pattern is used without a formal specification in many specifications including: XCCDF and the CPE 2.3 Applicability Language.&nbsp;&nbsp;If we define the pattern properly, establishing a contract between checking clients and checking systems, we can stabilize our existing uses and provide a new foundation for additional checking uses cases.&nbsp;&nbsp;This may also have the effect of stimulating novel checking solutions for mobile and network devices.&nbsp;&nbsp;It may also make sense to look at breaking up the logical evaluation capabilities that share some commonality across XCCDF, OVAL and OCIL into a separate specification.&nbsp;&nbsp;We have talked in the past about using the results of one check system to drive the behavior of another.&nbsp;&nbsp;This type of approach might provide a mechanism to support that.</div><div><br></div><div>2) Enterprise targeting of assets - We currently have no standardized way to associate a checklist and/or a collection of checks with a set of assets that need to be interrogated to determine compliance.&nbsp;&nbsp;This is definitely a problem for OCIL, but the approach is not formalized for OVAL checks either.&nbsp;&nbsp;The closest thing we have is the applicability approach used in XCCDF which is not a targeting solution.&nbsp;&nbsp;I would argue that applicability is something altogether different from targeting.&nbsp;&nbsp;Applicability allows machine readable guidance to be pre-qualified as being purposed for scanning specific software.&nbsp;&nbsp;What we desire from a targeting perspective is assignment of a checklist to a collection of assets that contain the applicable software.&nbsp;&nbsp;Applicability can be used to determine what CAN be assigned, but it is not THE assignment.&nbsp;&nbsp;It serves a separate purpose.&nbsp;&nbsp;If we confound applicability and assignment, we risk creating checklists that are specific to an asset instead of being applicable to many assets.&nbsp;&nbsp;This will hinder content reuse and exacerbate content management challenges.</div><div><br></div><div>Instead, it might be better to develop a new higher-level concept that enables definition of organizational digital policy that links rules in a checklist or checks to the appropriate assets that need to be assessed perhaps using ai:asset constructs.&nbsp;&nbsp;For OCIL the asset in question could be the systems admin that is responsible for a set of hosts.&nbsp;&nbsp;For OVAL the asset mapping might be to a domain server that provides group policy for a collection of hosts, or a directory server that provides authentication capabilities.&nbsp;&nbsp;This policy can also indicate the frequency, conditions and timing of assessments, allowing automated tasks to be dispatched based on this information to enact the policy.</div><div><br></div><div>3) Tasking and scheduling - Based on the digital policy from the previous item, automated tasks can be created external to scanning applications to instruct them to perform a single scan, a recurring scan, establish a schedule based on a calendar or other conditions (e.g., CPU utilization, network load, etc).&nbsp;&nbsp;By defining tasking as a separate concern from the assessment content, an organization will have the ability to orchestrate the assessment of a checklists or a collection of checks against many different sets of assets (e.g., people, systems, networks, devices) using independent tasks.&nbsp;&nbsp;They can also use the same standardized approach to orchestrate different scanning solutions within their environments. This further promotes content reuse and avoids the need to customize content for a specific scanning task or solution.</div><div><br></div><div>My hope is that the MILE GRC Exchange specification can be shapped to support a high-level framework that allows detailed task messages to be exchanged using more specialized models (e.g., assessment, remdiation, etc.) as GRC message payloads.</div><div><br></div><div>Dave Waltermire</div><div><br></div><div><br></div><div>-----Original Message-----</div><div>From: <a href="mailto:[email-masked]">[email-masked]</a> [<a href="mailto:[email-masked]">mailto:[email-masked]</a>] On Behalf Of Adam Montville</div><div>Sent: Tuesday, February 14, 2012 3:50 PM</div><div>To: <a href="mailto:[email-masked]">[email-masked]</a>; <a href="mailto:[email-masked]">[email-masked]</a></div><div>Cc: <a href="mailto:[email-masked]">[email-masked]</a></div><div>Subject: Re: [scap_interest] Checking language needs</div><div><br></div><div>Kent,</div><div><br></div><div>I think scheduling should be a separate concern, but can see targeting being embedded in the checking system, much as it is today in OVAL (in a way, the inventory definitions perform the targeting for technical checks).&nbsp;&nbsp;If we were to leverage Asset Identification, the targeting could be handled in some cases with a simple ai:asset reference - a person is targeted as the owner of the given system.</div><div><br></div><div>Adam</div><div><br></div><div>From: kent_landfield &lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&gt;</div><div>Date: Tue, 14 Feb 2012 14:30:27 -0600</div><div>To: &lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&gt;</div><div>Cc: &lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&gt;</div><div>Subject: Re: [scap_interest] Checking language needs</div><div><br></div><div>Thanks Karen!&nbsp;&nbsp;I'll take you up on that!</div><div><br></div><div>From the standpoint of what should be included beyond the actual integration issues, should this document, in addition to integration, discuss issues such as targeting and scheduling for interrogative checking systems like OCIL or would folks consider that a separate issue to be dealt with somewhere else?</div><div><br></div><div>Thoughts?</div><div><br></div><div>Kent Landfield</div><div>Director Content Strategy, Architecture and Standards</div><div><br></div><div>McAfee | An Intel Company</div><div>5000 Headquarters Dr.</div><div>Plano, Texas 75024</div><div><br></div><div>Direct: &#43;1.972.963.7096</div><div>Mobile: &#43;1.817.637.8026</div><div>Web: www.mcafee.com&lt;<a href="http://www.mcafee.com/">http://www.mcafee.com/</a>&gt;</div><div><br></div><div>From: Karen Scarfone &lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&gt;</div><div>Date: Tue, 14 Feb 2012 14:11:21 -0600</div><div>To: Kent Landfield &lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&gt;</div><div>Cc: &quot;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&gt;</div><div>Subject: Re: [scap_interest] Checking language needs</div><div><br></div><div>Kent,</div><div><br></div><div>I'd be happy to help with the publication/editing side of specification development.</div><div><br></div><div><br></div><div>Karen</div><div><br></div><div>On Tue, Feb 14, 2012 at 3:02 PM, &lt;<a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]&gt;">mailto:[email-masked]&gt;</a>&gt; wrote:</div><div>All,</div><div><br></div><div>One of the missing pieces we have right now is a standardized approach to developing new checking languages.&nbsp;&nbsp;Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF.&nbsp;&nbsp;The later's adoption rate has been seriously impacted because of that.&nbsp;&nbsp;Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages.&nbsp;&nbsp;Scripting is also being done directly from XCCDF benchmarks by multiple vendor products.</div><div><br></div><div>As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means.&nbsp;&nbsp;Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today.&nbsp;&nbsp;Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting.&nbsp;&nbsp;Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches.&nbsp;&nbsp;Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.</div><div><br></div><div>From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place.&nbsp;&nbsp;We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate effectively.&nbsp;&nbsp;By specifying the practices and items&nbsp;&nbsp;new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.</div><div><br></div><div>I am looking for interest here and for those that might want to help me in producing this draft specification.</div><div><br></div><div>Kent Landfield</div><div>Director Content Strategy, Architecture and Standards</div><div><br></div><div>McAfee | An Intel Company</div><div>5000 Headquarters Dr.</div><div>Plano, Texas 75024</div><div><br></div><div>Direct: &#43;1.972.963.7096</div><div>Mobile: &#43;1.817.637.8026</div><div>Web: www.mcafee.com&lt;<a href="http://www.mcafee.com/">http://www.mcafee.com/</a>&gt;</div><div><br></div><div>_______________________________________________</div><div>scap_interest mailing list</div><div><a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]">mailto:[email-masked]</a>&gt;</div><div><a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a></div><div><br></div><div><br></div><div><br></div><div><br></div><div>--</div><div>Karen Scarfone, Principal Consultant, Scarfone Cybersecurity</div><div><a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]">mailto:[email-masked]</a>&gt;&nbsp;&nbsp; (703)401-1018</div><div><br></div><div>_______________________________________________ scap_interest mailing list <a href="mailto:[email-masked]">[email-masked]</a>&lt;<a href="mailto:[email-masked]">mailto:[email-masked]</a>&gt; <a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a></div><div><br></div><div>_______________________________________________</div><div>scap_interest mailing list</div><div><a href="mailto:[email-masked]">[email-masked]</a></div><div><a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a></div><div><br></div></div></div></blockquote></span></body></html>

--_000_CB6034F82C592kentlandfieldmcafeecom_--

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Tue, 14 Feb 2012 17:47:51 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [scap_interest] Gaps in Risk Management

--_000_AE31510960917D478171C79369B660FA0E2F547D92MX06Acorpemcc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Jerome,

I think it is a really good idea to start from use cases and what we want to get out of this work to drive the standards efforts.  The work being done here should result in the ability to report on meaningful and actionable metrics.  Brainstorming like this at the RSA Conference and on list would be great.  Activities like this may be tied to the frameworks as well - how do we get good risk metrics against the frameworks in which we want to measure our security programs?

Luis brought up CSA's control matrix, maybe we want to think about what was done for 800-53 and how that could apply out to other frameworks like ISO27002 +ISO27017 (Virtualization/cloud), HIPAA HITECH, etc.  performing checks, assessing risk, and producing metrics are the drivers for these underlying activities.

Dan Greer has some good presentations online related to metrics and is running a series in IEE Security and Privacy on the topic as well.  I do need to admit that I have to catch up on my reading, so I can't tell you too much about that effort :)

Any other thoughts on these topics?

Thanks,
Kathleen

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jerome Athias
Sent: Tuesday, February 14, 2012 5:34 PM
To: [email-masked]
Subject: Re: [scap_interest] Gaps in Risk Management

Hi list,

could it be possible to have a brainstorming at the RSA Conference?

or / because i identifed the following talk (at BSides San Francisco, // free event):

Metrics That Don't Suck: A New Way To Measure Security Effectiveness ~ Dr. Mike Lloyd

How does your organization measure and report its security posture and performance?  Do you have spreadsheets that show how many vulnerabilities you found last month, or how many viruses your AV system stopped? Those numbers might pacify your management, but any security pro can tell you that they are no way to benchmark the real work you do - or how much danger your enterprise might be in.

Maybe the problem is that we're all trying to use the data we already have - host metrics, network metrics, applications data - instead of building the data we actually need.  We need metrics that show the current range of threats, and the enterprise's exposure. We need data that shows whether our security tools and programs are actually working or not. We need methods for demonstrating that our security teams are performing well - not only this month, but over a period of time.

In this thought-provoking presentation, we'll describe methods for building an enterprise security metrics program that's completely different from the current, sucky model of counting vulnerabilities or numbers of patches applied. We'll outline methods for monitoring the threat landscape, and your organization's exposure. We'll offer some best practices for measuring the effectiveness of current security tools and systems. Best of all, we'll outline a way to build a maturity model for security, so that you can show your security team's performance on a month-to-month basis, and demonstrate its continuing improvement over time.

Want to stop reporting a bunch of crap and start building a real set of data that accurately measures your organization's risk and its effectiveness in controlling it?  Want to learn how to integrate security data across hosts, networks, and applications?  Want your performance - and your company's security posture - to be monitored using metrics that don't suck?  Here's a chance to look at the picture from a whole new angle.
(ref: http://www.infosecisland.com/blogview/20057-Security-BSides-San-Francisco-Speakers-and-Topics-Lineup.html )

I see these events as a good place to exchange our ideas.

Just my 2 cents

/JA

--_000_AE31510960917D478171C79369B660FA0E2F547D92MX06Acorpemcc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="&#1;" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi Jerome,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I think it is a really good idea to start from use cases and what we want to get out of this work to drive the standards efforts.&nbsp; The work being done here should result in the ability to report on meaningful and actionable metrics.&nbsp; Brainstorming like this at the RSA Conference and on list would be great.&nbsp; Activities like this may be tied to the frameworks as well &#8211; how do we get good risk metrics against the frameworks in which we want to measure our security programs?&nbsp; <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Luis brought up CSA&#8217;s control matrix, maybe we want to think about what was done for 800-53 and how that could apply out to other frameworks like ISO27002 +ISO27017 (Virtualization/cloud), HIPAA HITECH, etc.&nbsp; performing checks, assessing risk, and producing metrics are the drivers for these underlying activities.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Dan Greer has some good presentations online related to metrics and is running a series in IEE Security and Privacy on the topic as well.&nbsp; I do need to admit that I have to catch up on my reading, so I can&#8217;t tell you too much about that effort </span><span style='font-size:11.0pt;font-family:Wingdings;color:#1F497D'>J</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Any other thoughts on these topics?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Kathleen<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> [email-masked] [mailto:[email-masked]] <b>On Behalf Of </b>Jerome Athias<br><b>Sent:</b> Tuesday, February 14, 2012 5:34 PM<br><b>To:</b> [email-masked]<br><b>Subject:</b> Re: [scap_interest] Gaps in Risk Management<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>Hi list,<br><br>could it be possible to have a brainstorming at the RSA Conference?<br><br>or / because i identifed the following talk (at BSides San Francisco, // free event):<o:p></o:p></p><p><strong><u>Metrics That Don&#8217;t Suck: A New Way To Measure Security Effectiveness ~ Dr. Mike Lloyd</u></strong><o:p></o:p></p><p>How does your organization measure and report its security posture and performance?&nbsp; Do you have spreadsheets that show how many vulnerabilities you found last month, or how many viruses your AV system stopped? Those numbers might pacify your management, but any security pro can tell you that they are no way to benchmark the real work you do &#8211; or how much danger your enterprise might be in.<o:p></o:p></p><p>Maybe the problem is that we&#8217;re all trying to use the data we already have &#8211; host metrics, network metrics, applications data &#8211; instead of building the data we actually need.&nbsp; We need metrics that show the current range of threats, and the enterprise&#8217;s exposure. We need data that shows whether our security tools and programs are actually working or not. We need methods for demonstrating that our security teams are performing well &#8211; not only this month, but over a period of time.<o:p></o:p></p><p>In this thought-provoking presentation, we&#8217;ll describe methods for building an enterprise security metrics program that&#8217;s completely different from the current, sucky model of counting vulnerabilities or numbers of patches applied. We&#8217;ll outline methods for monitoring the threat landscape, and your organization&#8217;s exposure. We&#8217;ll offer some best practices for measuring the effectiveness of current security tools and systems. Best of all, we&#8217;ll outline a way to build a maturity model for security, so that you can show your security team&#8217;s performance on a month-to-month basis, and demonstrate its continuing improvement over time.<o:p></o:p></p><p>Want to stop reporting a bunch of crap and start building a real set of data that accurately measures your organization&#8217;s risk and its effectiveness in controlling it?&nbsp; Want to learn how to integrate security data across hosts, networks, and applications?&nbsp; Want your performance &#8211; and your company&#8217;s security posture &#8211; to be monitored using metrics that don&#8217;t suck?&nbsp; Here&#8217;s a chance to look at the picture from a whole new angle.<o:p></o:p></p><p class=MsoNormal>(ref: <a href="http://www.infosecisland.com/blogview/20057-Security-BSides-San-Francisco-Speakers-and-Topics-Lineup.html">http://www.infosecisland.com/blogview/20057-Security-BSides-San-Francisco-Speakers-and-Topics-Lineup.html</a> )<br><br>I see these events as a good place to exchange our ideas.<br><br>Just my 2 cents<br><br>/JA<o:p></o:p></p></div></body></html>
--_000_AE31510960917D478171C79369B660FA0E2F547D92MX06Acorpemcc_--

Date: Tue, 14 Feb 2012 22:34:10 +0000
From: Jerome Athias <[email-masked]>
To: [email-masked]
Subject: Re: [scap_interest] Gaps in Risk Management

This is a multi-part message in MIME format.
--------------080603080206090806000502
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi list,

could it be possible to have a brainstorming at the RSA Conference?

or / because i identifed the following talk (at BSides San Francisco, // 
free event):

*Metrics That Don�t Suck: A New Way To Measure Security Effectiveness ~ 
Dr. Mike Lloyd*

How does your organization measure and report its security posture and 
performance?  Do you have spreadsheets that show how many 
vulnerabilities you found last month, or how many viruses your AV system 
stopped? Those numbers might pacify your management, but any security 
pro can tell you that they are no way to benchmark the real work you do 
� or how much danger your enterprise might be in.

Maybe the problem is that we�re all trying to use the data we already 
have � host metrics, network metrics, applications data � instead of 
building the data we actually need.  We need metrics that show the 
current range of threats, and the enterprise�s exposure. We need data 
that shows whether our security tools and programs are actually working 
or not. We need methods for demonstrating that our security teams are 
performing well � not only this month, but over a period of time.

In this thought-provoking presentation, we�ll describe methods for 
building an enterprise security metrics program that�s completely 
different from the current, sucky model of counting vulnerabilities or 
numbers of patches applied. We�ll outline methods for monitoring the 
threat landscape, and your organization�s exposure. We�ll offer some 
best practices for measuring the effectiveness of current security tools 
and systems. Best of all, we�ll outline a way to build a maturity model 
for security, so that you can show your security team�s performance on a 
month-to-month basis, and demonstrate its continuing improvement over time.

Want to stop reporting a bunch of crap and start building a real set of 
data that accurately measures your organization�s risk and its 
effectiveness in controlling it?  Want to learn how to integrate 
security data across hosts, networks, and applications?  Want your 
performance � and your company�s security posture � to be monitored 
using metrics that don�t suck?  Here�s a chance to look at the picture 
from a whole new angle.

(ref: 
http://www.infosecisland.com/blogview/20057-Security-BSides-San-Francisco-Speakers-and-Topics-Lineup.html 
)

I see these events as a good place to exchange our ideas.

Just my 2 cents

/JA

--------------080603080206090806000502
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi list,<br>
    <br>
    could it be possible to have a brainstorming at the RSA Conference?<br>
    <br>
    or / because i identifed the following talk (at BSides San
    Francisco, // free event):<br>
    <br>
    <p> <strong><span style="text-decoration: underline;">Metrics That
          Don�t Suck: A New Way To Measure Security Effectiveness ~ Dr.
          Mike Lloyd</span></strong></p>
    <p> How does your organization measure and report its security
      posture and performance?� Do you have spreadsheets that show how
      many vulnerabilities you found last month, or how many viruses
      your AV system stopped? Those numbers might pacify your
      management, but any security pro can tell you that they are no way
      to benchmark the real work you do � or how much danger your
      enterprise might be in.</p>
    <p> Maybe the problem is that we�re all trying to use the data we
      already have � host metrics, network metrics, applications data �
      instead of building the data we actually need.� We need metrics
      that show the current range of threats, and the enterprise�s
      exposure. We need data that shows whether our security tools and
      programs are actually working or not. We need methods for
      demonstrating that our security teams are performing well � not
      only this month, but over a period of time.</p>
    <p> In this thought-provoking presentation, we�ll describe methods
      for building an enterprise security metrics program that�s
      completely different from the current, sucky model of counting
      vulnerabilities or numbers of patches applied. We�ll outline
      methods for monitoring the threat landscape, and your
      organization�s exposure. We�ll offer some best practices for
      measuring the effectiveness of current security tools and systems.
      Best of all, we�ll outline a way to build a maturity model for
      security, so that you can show your security team�s performance on
      a month-to-month basis, and demonstrate its continuing improvement
      over time.</p>
    <p> Want to stop reporting a bunch of crap and start building a real
      set of data that accurately measures your organization�s risk and
      its effectiveness in controlling it?� Want to learn how to
      integrate security data across hosts, networks, and applications?�
      Want your performance � and your company�s security posture � to
      be monitored using metrics that don�t suck?� Here�s a chance to
      look at the picture from a whole new angle.</p>
    (ref:
    <a class="moz-txt-link-freetext" href="http://www.infosecisland.com/blogview/20057-Security-BSides-San-Francisco-Speakers-and-Topics-Lineup.html">http://www.infosecisland.com/blogview/20057-Security-BSides-San-Francisco-Speakers-and-Topics-Lineup.html</a>
    )<br>
    <br>
    I see these events as a good place to exchange our ideas.<br>
    <br>
    Just my 2 cents<br>
    <br>
    /JA<br>
  </body>
</html>

--------------080603080206090806000502--

From: Adam Montville <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Accept-Language: en-US
Subject: Re: [scap_interest] Operational Aspects

Fair enough.  Just throwing things against the wall as they come to mind.

Adam

From: kent_landfield <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 15:32:38 -0600
To: Adam Montville <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Operational Aspects

Adam,

We have more than enough on our plate with the specification / I-D work.  Let's see if we can deal with this in a more appropriate forum. I do not see this as that forum.  My 2cents�

Thanks.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Adam Montville <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 15:12:51 -0600
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [scap_interest] Operational Aspects

While we're all bantering about on security automation, there's another side to the story.  Are there any operational concerns we might address within a WG should one be formed?  For example, we have, in the United States, NVD hosting a repository of information.  CCE identifiers are moderated and assigned by an operational process.  As new enumerations are published and new types of content are conceived, it's easy to imagine the need for some operational standardization.

Should we consider standardizing some of these processes, and if so would the WG we seek to establish be the appropriate place for that work?

Regards,

Adam W. Montville | Security and Compliance Architect

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

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

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

From: "Chernin, Michael A." <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 14 Feb 2012 22:04:43 +0000
Accept-Language: en-US
Subject: [scap_interest] Scope of standards potentially moving to IETF

I am just going to jump right on out there and ask. Which standards are we looking to go to IETF? Specific SCAP standards or the entire SCAP umbrella?

Aharon

DTCC Non-Confidential (White)
---------------------------------------------------
Michael "Aharon" Chernin
Security Automation Program Manager
Corporate Information Security -Depository Trust & Clearing Corporation
O: 813-470-2173

<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Tue, 14 Feb 2012 15:57:40 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [scap_interest] Checking language needs

--_000_CB6034402C58Akentlandfieldmcafeecom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Matthew,

Great, I'll take you up on that!  I do think that we need to discuss what a specification like I suggested below would contain. I  see a few posts that suggest the need is there but we may want to discuss the focus of the document a bit more. Thoughts?

Thanks.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 15:40:43 -0600
To: Kent Landfield <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Checking language needs

(Resending after joining the mailing list officially.)

Kent,

I would like to contribute to this effort, in whatever capacity that would be valuable. I work with the products at EMC to make them secure and enable security among them and other systems, and find SCAP an important initiative and set of standards.

Thank you,

Matthew Coles | Product Security Office | RSA, the Security Division of EMC

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, February 14, 2012 3:02 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [scap_interest] Checking language needs

All,

One of the missing pieces we have right now is a standardized approach to developing new checking languages.  Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF.  The later's adoption rate has been seriously impacted because of that.  Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages.  Scripting is also being done directly from XCCDF benchmarks by multiple vendor products.

As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means.  Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today.  Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting.  Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches.  Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.

>From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place.  We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate effectively.  By specifying the practices and items  new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.

I am looking for interest here and for those that might want to help me in producing this draft specification.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

--_000_CB6034402C58Akentlandfieldmcafeecom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-family: 'Times New Roman', sans-serif; "><div><div><div>Hi Matthew,</div><div><br></div><div>Great, I'll take you up on that! &nbsp;I do think that we need to discuss what a specification like I suggested below would contain. I &nbsp;see a few posts that suggest the need is there but we may want to discuss the focus of the document a bit more. Thoughts?</div><div><br></div><div>Thanks.</div><div><br></div><div><div><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Kent Landfield</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Director Content Strategy, Architecture and Standards</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>McAfee | An Intel Company</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">5000 Headquarters Dr.</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Plano, Texas 75024</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Direct: +1.972.963.7096&nbsp;</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Mobile: +1.817.637.8026</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Web:&nbsp;</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><a href="http://www.mcafee.com/" style="color: rgb(96, 106, 113) !important; ">www.mcafee.com</a></span></div></div></div></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> "<a href="mailto:[email-masked]">[email-masked]</a>" &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Date: </span> Tue, 14 Feb 2012 15:40:43 -0600<br><span style="font-weight:bold">To: </span> Kent  Landfield &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;, "<a href="mailto:[email-masked]">[email-masked]</a>" &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Subject: </span> RE: Checking language needs<br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:d="DAV:" xmlns:repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40"><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"><meta name="Generator" content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--><div lang="EN-US" link="blue" vlink="purple" style="word-wrap: break-word;-webkit-nbsp-mode: space;-webkit-line-break: after-white-space"><div class="WordSection1"><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">(Resending after joining the mailing list officially.)<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">Kent,<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">I would like to contribute to this effort, in whatever capacity that would be valuable. I work with the products at EMC to make them secure and enable security among them and other systems, and find SCAP an important initiative and set of standards.<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">Thank you,<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p><div><p class="MsoNormal"><span style="font-size: 9pt; color: rgb(31, 73, 125); font-family: Arial, sans-serif; ">Matthew Coles | Product Security Office | RSA, the Security Division of EMC<o:p></o:p></span></p></div><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p><div><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p></div><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></p><div><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "> <a href="mailto:[email-masked]">[email-masked]</a> [<a href="mailto:[email-masked]">mailto:[email-masked]</a>] <b>On Behalf Of </b><a href="mailto:[email-masked]">[email-masked]</a><br><b>Sent:</b> Tuesday, February 14, 2012 3:02 PM<br><b>To:</b> <a href="mailto:[email-masked]">[email-masked]</a><br><b>Subject:</b> [scap_interest] Checking language needs<o:p></o:p></span></p></div></div><p class="MsoNormal"><o:p>&nbsp;</o:p></p><div><div><div><p class="MsoNormal"><span style="color:black">All,<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">One of the missing pieces we have right now is a standardized approach to developing new checking languages. &nbsp;Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF. &nbsp;The later's adoption rate has been seriously impacted because of that. &nbsp;Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages. &nbsp;Scripting is also being done directly from XCCDF benchmarks by multiple vendor products. &nbsp;<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means. &nbsp;Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today. &nbsp;Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting. &nbsp;Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches. &nbsp;Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place. &nbsp;We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate&nbsp;effectively. &nbsp;By specifying the practices and items &nbsp;new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p></div><div><p class="MsoNormal"><span style="color:black">I am looking for interest here and for those that might want to help me in producing this draft specification. &nbsp;<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p></div><div><div><p class="MsoNormal"><strong><span style="font-size: 9pt; color: rgb(96, 106, 113); font-family: Arial, sans-serif; ">Kent Landfield</span></strong><span style="font-size: 9pt; color: rgb(96, 106, 113); font-family: Arial, sans-serif; "><br><span class="apple-style-span">Director Content Strategy, Architecture and Standards</span><br><br><strong><span style="font-family: Arial, sans-serif; ">McAfee | An Intel Company</span></strong><br><span class="apple-style-span">5000 Headquarters Dr.</span><br><span class="apple-style-span">Plano, Texas 75024</span><br><br><span class="apple-style-span">Direct: +1.972.963.7096&nbsp;</span><br><span class="apple-style-span">Mobile: +1.817.637.8026</span><br><strong><span style="font-family: Arial, sans-serif; ">Web:&nbsp;</span></strong><span class="apple-style-span"><a href="http://www.mcafee.com/">www.mcafee.com</a></span></span><span style="color:black"><o:p></o:p></span></p></div></div></div></div></div></div></div></blockquote></span></body></html>

--_000_CB6034402C58Akentlandfieldmcafeecom_--

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Tue, 14 Feb 2012 15:47:29 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [scap_interest] Just throwing this out there: Compliance Frameworks

--_000_CB602F342C555kentlandfieldmcafeecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Adam,

I agree that an effort such as this has great potential.  Think of the content authors today. They use XML Editors or internally developed tools to create OVAL to do the compliance checking.  This is very time consuming and very costly, while limiting the available checks and benchmarks.

If there was a means where all regulations and security policies could be universally mapped and the specifics around them, based on individual platforms, were also attached to each unified record, it is possible to auto generate not just the benchmarks but the individual checks.  Some of this research has been successful in the past.  This is doable. The problem has been there is not an authoritative source for that data.

Today too many people are manually writing content that could be auto generated from a database with the right schema and software.  The problem though is as much on the front end as it is on the generation side.  Someone needs to maintain that information or have an infrastructure put in place where guidance authors for regulations or security policies can update their information in the shared datastore.

I think this is one of the missing pieces and it may be useful to have a discussion with interested parties but you would need to include participants from the two mentioned efforts below.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Adam Montville <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 15:09:34 -0600
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [scap_interest] Just throwing this out there: Compliance Frameworks

All,

I had a brief discussion with several members of this list with respect to compliance frameworks, which met some resistance.  Still, I think presenting the idea to a larger audience to solicit feedback is a good idea.

>From an automation perspective, it seems that some method of being able to map benchmark-level tests to some higher level policy representation may be warranted.  At the end of the day, we perform assessments to ensure that we are in a secure state � to be compliant with a particular set of policies.

Is there any interest in being able to represent a compliance framework with either a new specification or potentially revitalizing and extending an existing specification (CCI: http://iase.disa.mil/stigs/cci.html), or to simply rely upon any existing commercial efforts, such as UCF (https://www.unifiedcompliance.com)?

Or, is this type of representation simply not needed � there's enough there, the present demand doesn't justify the work, or something else?

Thoughts?

Regards,

Adam W. Montville | Security and Compliance Architect

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

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

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

--_000_CB602F342C555kentlandfieldmcafeecom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-family: 'Times New Roman', sans-serif; "><div><div><div>Adam,</div><div><br></div><div>I agree that an effort such as this has great potential. &nbsp;Think of the content authors today. They use XML Editors or internally developed tools to create OVAL to do the compliance checking. &nbsp;This is very time consuming and very costly, while limiting the available checks and benchmarks.</div><div><br></div><div>If there was a means where all regulations and security policies could be universally mapped and the specifics around them, based on individual platforms, were also attached to each unified record, it is possible to auto generate not just the benchmarks but the individual checks. &nbsp;Some of this research has been successful in the past. &nbsp;This is doable. The problem has been there is not an authoritative source for that data. &nbsp;</div><div><br></div><div>Today too many people are manually writing content that could be auto generated from a database with the right schema and software. &nbsp;The problem though is as much on the front end as it is on the generation side. &nbsp;Someone needs to maintain that information or have an infrastructure put in place where guidance authors for regulations or security policies can update their information in the shared datastore. &nbsp;</div><div><br></div><div><div>I think this is one of the missing pieces and it may be useful to have a discussion with interested parties but you would need to include participants from the two mentioned efforts below.</div></div><div><br></div><div><div><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Kent Landfield</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Director Content Strategy, Architecture and Standards</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>McAfee | An Intel Company</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">5000 Headquarters Dr.</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Plano, Texas 75024</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Direct: &#43;1.972.963.7096&nbsp;</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Mobile: &#43;1.817.637.8026</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Web:&nbsp;</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><a href="http://www.mcafee.com/" style="color: rgb(96, 106, 113) !important; ">www.mcafee.com</a></span></div></div></div></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Adam Montville &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Date: </span> Tue, 14 Feb 2012 15:09:34 -0600<br><span style="font-weight:bold">To: </span> &quot;<a href="mailto:[email-masked]">[email-masked]</a>&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Subject: </span> [scap_interest] Just throwing this out there: Compliance Frameworks<br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div><div>All,</div><div><br></div><div>I had a brief discussion with several members of this list with respect to compliance frameworks, which met some resistance.&nbsp;&nbsp;Still, I think presenting the idea to a larger audience to solicit feedback is a good idea.</div><div><br></div><div>From an automation perspective, it seems that some method of being able to map benchmark-level tests to some higher level policy representation may be warranted.&nbsp;&nbsp;At the end of the day, we perform assessments to ensure that we are in a secure state � to be compliant with a particular set of policies.</div><div><br></div><div>Is there any interest in being able to represent a compliance framework with either a new specification or potentially revitalizing and extending an existing specification (CCI: <a href="http://iase.disa.mil/stigs/cci.html">http://iase.disa.mil/stigs/cci.html</a>), or to simply rely upon any existing commercial efforts, such as UCF (<a href="https://www.unifiedcompliance.com">https://www.unifiedcompliance.com</a>)?</div><div><br></div><div>Or, is this type of representation simply not needed � there's enough there, the present demand doesn't justify the work, or something else?</div><div><br></div><div>Thoughts?</div><div><br></div><div>Regards,</div><div><br></div><div>Adam W. Montville | Security and Compliance Architect</div><div><br></div><div>Direct: 503 276-7661</div><div>Mobile: 360 471-7815</div><div><br></div><div>TRIPWIRE | Take CONTROL</div><div><a href="http://www.tripwire.com">http://www.tripwire.com</a></div><div><br></div><div>_______________________________________________</div><div>scap_interest mailing list</div><div><a href="mailto:[email-masked]">[email-masked]</a></div><div><a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a></div><div><br></div></div></div></blockquote></span></body></html>

--_000_CB602F342C555kentlandfieldmcafeecom_--

From: "Waltermire, David A." <[email-masked]>
To: Adam Montville <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 14 Feb 2012 16:47:44 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Checking language needs

The issues we are discussing can be grouped into the following separate, but related functional areas.  Each should be treated as a separate concern.  Here are some ideas on how to parse out each area:

1) Defining a "checking design pattern" - This de facto pattern is used without a formal specification in many specifications including: XCCDF and the CPE 2.3 Applicability Language.  If we define the pattern properly, establishing a contract between checking clients and checking systems, we can stabilize our existing uses and provide a new foundation for additional checking uses cases.  This may also have the effect of stimulating novel checking solutions for mobile and network devices.  It may also make sense to look at breaking up the logical evaluation capabilities that share some commonality across XCCDF, OVAL and OCIL into a separate specification.  We have talked in the past about using the results of one check system to drive the behavior of another.  This type of approach might provide a mechanism to support that.

2) Enterprise targeting of assets - We currently have no standardized way to associate a checklist and/or a collection of checks with a set of assets that need to be interrogated to determine compliance.  This is definitely a problem for OCIL, but the approach is not formalized for OVAL checks either.  The closest thing we have is the applicability approach used in XCCDF which is not a targeting solution.  I would argue that applicability is something altogether different from targeting.  Applicability allows machine readable guidance to be pre-qualified as being purposed for scanning specific software.  What we desire from a targeting perspective is assignment of a checklist to a collection of assets that contain the applicable software.  Applicability can be used to determine what CAN be assigned, but it is not THE assignment.  It serves a separate purpose.  If we confound applicability and assignment, we risk creating checklists that are specific to an asset instead of being applicable to many assets.  This will hinder content reuse and exacerbate content management challenges.

Instead, it might be better to develop a new higher-level concept that enables definition of organizational digital policy that links rules in a checklist or checks to the appropriate assets that need to be assessed perhaps using ai:asset constructs.  For OCIL the asset in question could be the systems admin that is responsible for a set of hosts.  For OVAL the asset mapping might be to a domain server that provides group policy for a collection of hosts, or a directory server that provides authentication capabilities.  This policy can also indicate the frequency, conditions and timing of assessments, allowing automated tasks to be dispatched based on this information to enact the policy.

3) Tasking and scheduling - Based on the digital policy from the previous item, automated tasks can be created external to scanning applications to instruct them to perform a single scan, a recurring scan, establish a schedule based on a calendar or other conditions (e.g., CPU utilization, network load, etc).  By defining tasking as a separate concern from the assessment content, an organization will have the ability to orchestrate the assessment of a checklists or a collection of checks against many different sets of assets (e.g., people, systems, networks, devices) using independent tasks.  They can also use the same standardized approach to orchestrate different scanning solutions within their environments. This further promotes content reuse and avoids the need to customize content for a specific scanning task or solution.

My hope is that the MILE GRC Exchange specification can be shapped to support a high-level framework that allows detailed task messages to be exchanged using more specialized models (e.g., assessment, remdiation, etc.) as GRC message payloads.

Dave Waltermire

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, February 14, 2012 3:50 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [scap_interest] Checking language needs

Kent,

I think scheduling should be a separate concern, but can see targeting being embedded in the checking system, much as it is today in OVAL (in a way, the inventory definitions perform the targeting for technical checks).  If we were to leverage Asset Identification, the targeting could be handled in some cases with a simple ai:asset reference - a person is targeted as the owner of the given system.

Adam

From: kent_landfield <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 14:30:27 -0600
To: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Checking language needs

Thanks Karen!  I'll take you up on that!

>From the standpoint of what should be included beyond the actual integration issues, should this document, in addition to integration, discuss issues such as targeting and scheduling for interrogative checking systems like OCIL or would folks consider that a separate issue to be dealt with somewhere else?

Thoughts?

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Karen Scarfone <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 14:11:21 -0600
To: Kent Landfield <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Checking language needs

Kent,

I'd be happy to help with the publication/editing side of specification development.

Karen

On Tue, Feb 14, 2012 at 3:02 PM, <[email-masked]<mailto:[email-masked]>> wrote:
All,

One of the missing pieces we have right now is a standardized approach to developing new checking languages.  Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF.  The later's adoption rate has been seriously impacted because of that.  Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages.  Scripting is also being done directly from XCCDF benchmarks by multiple vendor products.

As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means.  Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today.  Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting.  Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches.  Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.

>From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place.  We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate effectively.  By specifying the practices and items  new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.

I am looking for interest here and for those that might want to help me in producing this draft specification.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

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

--
Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
[email-masked]<mailto:[email-masked]>   (703)401-1018

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

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

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Tue, 14 Feb 2012 16:40:43 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [scap_interest] Checking language needs

------=_NextPart_000_095C_01CCEB37.64BB58F0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_095D_01CCEB37.64BB58F0"

------=_NextPart_001_095D_01CCEB37.64BB58F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

(Resending after joining the mailing list officially.)

Kent,

I would like to contribute to this effort, in whatever capacity that would
be valuable. I work with the products at EMC to make them secure and enable
security among them and other systems, and find SCAP an important initiative
and set of standards.

Thank you,

Matthew Coles | Product Security Office | RSA, the Security Division of EMC

 

 

From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Tuesday, February 14, 2012 3:02 PM
To: [email-masked]
Subject: [scap_interest] Checking language needs

All,

One of the missing pieces we have right now is a standardized approach to
developing new checking languages.  Within fielded XCCDF-enabled products
today there are multiple checking languages in use. One of them grew up with
XCCDF (OVAL) and another (OCIL) was developed without much concern for how
it might be called and used from XCCDF.  The later's adoption rate has been
seriously impacted because of that.  Additionally, vendors have at times
introduced their own checking mechanisms to support customer needs that
could not be supported with the existing checking languages.  Scripting is
also being done directly from XCCDF benchmarks by multiple vendor products.

 

As we are starting to expand security automation uses, it is important we
enable innovative approaches to check execution. Not everything can be done
using the existing model and existing means.  Continuous monitoring uses are
going to require more flexibility by requiring different means to check
certain areas than exist today.  Forcing implementers to have to dig thru
the XCCDF specification to have to figure out how to properly integrate with
it is an inhibitor. We need to foster alternative means so integrating into
the the existing security automation architectures and products is not so
daunting.  Even in areas where something as simple as scripting is used, I
would be very surprised if two existing implementations could execute the
same script content because of incompatible implementation approaches.  Yes,
OVAL is interoperable today but we need to make sure additional checking
languages have that same potential for interoperability.

>From my perspective, the key to the success in fielding a useful framework
is assuring the right building blocks are in place.  We need to be able to
leverage those building blocks to expand standards based security
automation. It is important we document the proper way to develop new
checking mechanisms if we are to have content and solutions that
interoperate effectively.  By specifying the practices and items  new
checking languages need to support, we can expand what is possible with
security automation using already fielded tools and environments.

I am looking for interest here and for those that might want to help me in
producing this draft specification.  

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096 
Mobile: +1.817.637.8026
Web: www.mcafee.com <http://www.mcafee.com/> 

------=_NextPart_001_095D_01CCEB37.64BB58F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="&#1;" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle22
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap: break-word;-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(Resending after joining the mailing list officially.)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Kent,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I would like to contribute to this effort, in whatever capacity that would be valuable. I work with the products at EMC to make them secure and enable security among them and other systems, and find SCAP an important initiative and set of standards.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thank you,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><p class=MsoNormal><span style='font-size:9.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Matthew Coles | Product Security Office | RSA, the Security Division of EMC<o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p></div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> [email-masked] [mailto:[email-masked]] <b>On Behalf Of </b>[email-masked]<br><b>Sent:</b> Tuesday, February 14, 2012 3:02 PM<br><b>To:</b> [email-masked]<br><b>Subject:</b> [scap_interest] Checking language needs<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><div><div><div><p class=MsoNormal><span style='color:black'>All,<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>One of the missing pieces we have right now is a standardized approach to developing new checking languages. &nbsp;Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF. &nbsp;The later's adoption rate has been seriously impacted because of that. &nbsp;Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages. &nbsp;Scripting is also being done directly from XCCDF benchmarks by multiple vendor products. &nbsp;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means. &nbsp;Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today. &nbsp;Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting. &nbsp;Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches. &nbsp;Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place. &nbsp;We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate&nbsp;effectively. &nbsp;By specifying the practices and items &nbsp;new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><p class=MsoNormal><span style='color:black'>I am looking for interest here and for those that might want to help me in producing this draft specification. &nbsp;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='color:black'><o:p>&nbsp;</o:p></span></p></div><div><div><p class=MsoNormal><strong><span style='font-size:9.0pt;font-family:"Arial","sans-serif";color:#606A71'>Kent Landfield</span></strong><span style='font-size:9.0pt;font-family:"Arial","sans-serif";color:#606A71'><br><span class=apple-style-span>Director Content Strategy, Architecture and Standards</span><br><br><strong><span style='font-family:"Arial","sans-serif"'>McAfee | An Intel Company</span></strong><br><span class=apple-style-span>5000 Headquarters Dr.</span><br><span class=apple-style-span>Plano, Texas 75024</span><br><br><span class=apple-style-span>Direct: +1.972.963.7096&nbsp;</span><br><span class=apple-style-span>Mobile: +1.817.637.8026</span><br><strong><span style='font-family:"Arial","sans-serif"'>Web:&nbsp;</span></strong><span class=apple-style-span><a href="http://www.mcafee.com/">www.mcafee.com</a></span></span><span style='color:black'><o:p></o:p></span></p></div></div></div></div></div></body></html>
------=_NextPart_001_095D_01CCEB37.64BB58F0--

------=_NextPart_000_095C_01CCEB37.64BB58F0
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

------=_NextPart_000_095C_01CCEB37.64BB58F0--

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Tue, 14 Feb 2012 15:32:38 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [scap_interest] Operational Aspects

--_000_CB602E892C54Fkentlandfieldmcafeecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Adam,

We have more than enough on our plate with the specification / I-D work.  Let's see if we can deal with this in a more appropriate forum. I do not see this as that forum.  My 2cents�

Thanks.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Adam Montville <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 15:12:51 -0600
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [scap_interest] Operational Aspects

While we're all bantering about on security automation, there's another side to the story.  Are there any operational concerns we might address within a WG should one be formed?  For example, we have, in the United States, NVD hosting a repository of information.  CCE identifiers are moderated and assigned by an operational process.  As new enumerations are published and new types of content are conceived, it's easy to imagine the need for some operational standardization.

Should we consider standardizing some of these processes, and if so would the WG we seek to establish be the appropriate place for that work?

Regards,

Adam W. Montville | Security and Compliance Architect

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

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

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

--_000_CB602E892C54Fkentlandfieldmcafeecom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-family: 'Times New Roman', sans-serif; "><div><div><div>Adam,</div><div><br></div><div>We have more than enough on our plate with the specification / I-D work. &nbsp;Let's see if we can deal with this in a more appropriate forum. I do not see this as that forum. &nbsp;My 2cents�</div><div><br></div><div>Thanks.</div><div><br></div><div><div><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Kent Landfield</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Director Content Strategy, Architecture and Standards</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>McAfee | An Intel Company</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">5000 Headquarters Dr.</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Plano, Texas 75024</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Direct: &#43;1.972.963.7096&nbsp;</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Mobile: &#43;1.817.637.8026</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Web:&nbsp;</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><a href="http://www.mcafee.com/" style="color: rgb(96, 106, 113) !important; ">www.mcafee.com</a></span></div></div></div></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Adam Montville &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Date: </span> Tue, 14 Feb 2012 15:12:51 -0600<br><span style="font-weight:bold">To: </span> &quot;<a href="mailto:[email-masked]">[email-masked]</a>&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Subject: </span> [scap_interest] Operational Aspects<br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div><div>While we're all bantering about on security automation, there's another side to the story.&nbsp;&nbsp;Are there any operational concerns we might address within a WG should one be formed?&nbsp;&nbsp;For example, we have, in the United States, NVD hosting a repository of information.&nbsp;&nbsp;CCE identifiers are moderated and assigned by an operational process.&nbsp;&nbsp;As new enumerations are published and new types of content are conceived, it's easy to imagine the need for some operational standardization.</div><div><br></div><div>Should we consider standardizing some of these processes, and if so would the WG we seek to establish be the appropriate place for that work?</div><div><br></div><div>Regards,</div><div><br></div><div>Adam W. Montville | Security and Compliance Architect</div><div><br></div><div>Direct: 503 276-7661</div><div>Mobile: 360 471-7815</div><div><br></div><div>TRIPWIRE | Take CONTROL</div><div><a href="http://www.tripwire.com">http://www.tripwire.com</a></div><div><br></div><div>_______________________________________________</div><div>scap_interest mailing list</div><div><a href="mailto:[email-masked]">[email-masked]</a></div><div><a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a></div><div><br></div></div></div></blockquote></span></body></html>

--_000_CB602E892C54Fkentlandfieldmcafeecom_--

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Tue, 14 Feb 2012 15:29:59 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [scap_interest] Putting SCAP to work

--_000_CB602E4C2C54Ckentlandfieldmcafeecom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Andrea,

Personally I would rather this list be about SCAP specifications and improving them, rather than specific products.  If you need to have a product dialog about PA or HBSS, I am all ears as that is my area and background. ;-) Please feel free to contact me offline. Info below.

Thanks!

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: "Kunz, Andrea A." <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 15:06:47 -0600
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [scap_interest] Putting SCAP to work

If this mail group is open to all items related to SCAP, I'd like to put in my two cents for the places where it is currently being used, or at least, where it's ready to be used.

If anyone out there has practical experience with or awareness of  the HBSS Policy Auditor and how it works with XCCDF Benchmarks and OVAL policy, I would definitely like to engage in some discourse.

Andrea

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

--_000_CB602E4C2C54Ckentlandfieldmcafeecom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-family: 'Times New Roman', sans-serif; "><div><div><div><div>Hi Andrea,</div><div><br></div><div>Personally I would rather this list be about SCAP specifications and improving them, rather than specific products. &nbsp;If you need to have a product dialog about PA or HBSS, I am all ears as that is my area and background. ;-) Please feel free to contact me offline. Info below.</div><div><br></div><div>Thanks!</div></div><div><br></div><div><div><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Kent Landfield</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Director Content Strategy, Architecture and Standards</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>McAfee | An Intel Company</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">5000 Headquarters Dr.</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Plano, Texas 75024</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Direct: +1.972.963.7096&nbsp;</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Mobile: +1.817.637.8026</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Web:&nbsp;</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><a href="http://www.mcafee.com/" style="color: rgb(96, 106, 113) !important; ">www.mcafee.com</a></span></div></div></div></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> "Kunz, Andrea A." &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Date: </span> Tue, 14 Feb 2012 15:06:47 -0600<br><span style="font-weight:bold">To: </span> "<a href="mailto:[email-masked]">[email-masked]</a>" &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Subject: </span> [scap_interest] Putting SCAP to work<br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div><div>If this mail group is open to all items related to SCAP, I'd like to put in my two cents for the places where it is currently being used, or at least, where it's ready to be used. </div><div><br></div><div>If anyone out there has practical experience with or awareness of&nbsp;&nbsp;the HBSS Policy Auditor and how it works with XCCDF Benchmarks and OVAL policy, I would definitely like to engage in some discourse.</div><div><br></div><div>Andrea</div><div><br></div><div><br></div><div>_______________________________________________</div><div>scap_interest mailing list</div><div><a href="mailto:[email-masked]">[email-masked]</a></div><div><a href="https://www.ietf.org/mailman/listinfo/scap_interest">https://www.ietf.org/mailman/listinfo/scap_interest</a></div><div><br></div></div></div></blockquote></span></body></html>

--_000_CB602E4C2C54Ckentlandfieldmcafeecom_--

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Tue, 14 Feb 2012 16:17:49 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [scap_interest] Checking language needs

--_000_A775CF577301854EBD38CC86F35FB6345D57352FA3MX21Acorpemcc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Kent,

I would like to contribute to this effort. I work with the products at EMC to make them secure and enable security among them and other systems, and find SCAP a valuable initiative and set of standards.

Matthew Coles | Product Security Office | RSA, the Security Division of EMC

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, February 14, 2012 3:02 PM
To: [email-masked]
Subject: [scap_interest] Checking language needs

All,

One of the missing pieces we have right now is a standardized approach to developing new checking languages.  Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF.  The later's adoption rate has been seriously impacted because of that.  Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages.  Scripting is also being done directly from XCCDF benchmarks by multiple vendor products.

As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means.  Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today.  Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting.  Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches.  Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.

>From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place.  We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate effectively.  By specifying the practices and items  new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.

I am looking for interest here and for those that might want to help me in producing this draft specification.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

--_000_A775CF577301854EBD38CC86F35FB6345D57352FA3MX21Acorpemcc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="&#1;" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.apple-style-span
	{mso-style-name:apple-style-span;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap: break-word;-webkit-nbsp-mode: space;-webkit-line-break: after-white-space">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Kent,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">I would like to contribute to this effort. I work with the products at EMC to make them secure and enable security among them and other systems, and find SCAP
 a valuable initiative and set of standards.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1F497D">Matthew Coles | Product Security Office | RSA, the Security Division of EMC<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> [email-masked] [mailto:[email-masked]]
<b>On Behalf Of </b>[email-masked]<br>
<b>Sent:</b> Tuesday, February 14, 2012 3:02 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> [scap_interest] Checking language needs<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="color:black">All,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">One of the missing pieces we have right now is a standardized approach to developing new checking languages. &nbsp;Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them
 grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF. &nbsp;The later's adoption rate has been seriously impacted because of that. &nbsp;Additionally, vendors have at times introduced their own
 checking mechanisms to support customer needs that could not be supported with the existing checking languages. &nbsp;Scripting is also being done directly from XCCDF benchmarks by multiple vendor products. &nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means. &nbsp;Continuous monitoring
 uses are going to require more flexibility by requiring different means to check certain areas than exist today. &nbsp;Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need
 to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting. &nbsp;Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could
 execute the same script content because of incompatible implementation approaches. &nbsp;Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place. &nbsp;We need to be able to leverage those building blocks to expand standards based security
 automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate&nbsp;effectively. &nbsp;By specifying the practices and items &nbsp;new checking languages need to support, we can expand what
 is possible with security automation using already fielded tools and environments.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">I am looking for interest here and for those that might want to help me in producing this draft specification. &nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><strong><span style="font-size:9.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#606A71">Kent Landfield</span></strong><span style="font-size:9.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#606A71"><br>
<span class="apple-style-span">Director Content Strategy, Architecture and Standards</span><br>
<br>
<strong><span style="font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">McAfee | An Intel Company</span></strong><br>
<span class="apple-style-span">5000 Headquarters Dr.</span><br>
<span class="apple-style-span">Plano, Texas 75024</span><br>
<br>
<span class="apple-style-span">Direct: &#43;1.972.963.7096&nbsp;</span><br>
<span class="apple-style-span">Mobile: &#43;1.817.637.8026</span><br>
<strong><span style="font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">Web:&nbsp;</span></strong><span class="apple-style-span"><a href="http://www.mcafee.com/">www.mcafee.com</a></span></span><span style="color:black"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_A775CF577301854EBD38CC86F35FB6345D57352FA3MX21Acorpemcc_--

From: Luis Nunez <[email-masked]>
Date: Tue, 14 Feb 2012 16:16:30 -0500
To: Adam Montville <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Just throwing this out there: Compliance Frameworks

Another reference point is the Cloud Control Matrix.  They did a excellent job of mapping many of the regulatories into a common set.
Coming out the Cloud Security Alliance it looks like it is gear towards Cloud environments.  Wondering if it could be leveraged in any environments. 

Link: https://cloudsecurityalliance.org/research/ccm/

-ln

On Feb 14, 2012, at 4:09 PM, Adam Montville wrote:

> All,
> 
> I had a brief discussion with several members of this list with respect to compliance frameworks, which met some resistance.  Still, I think presenting the idea to a larger audience to solicit feedback is a good idea.
> 
> From an automation perspective, it seems that some method of being able to map benchmark-level tests to some higher level policy representation may be warranted.  At the end of the day, we perform assessments to ensure that we are in a secure state � to be compliant with a particular set of policies.
> 
> Is there any interest in being able to represent a compliance framework with either a new specification or potentially revitalizing and extending an existing specification (CCI: http://iase.disa.mil/stigs/cci.html), or to simply rely upon any existing commercial efforts, such as UCF (https://www.unifiedcompliance.com)?
> 
> Or, is this type of representation simply not needed � there's enough there, the present demand doesn't justify the work, or something else?
> 
> Thoughts?
> 
> Regards,
> 
> Adam W. Montville | Security and Compliance Architect
> 
> Direct: 503 276-7661
> Mobile: 360 471-7815
> 
> TRIPWIRE | Take CONTROL
> http://www.tripwire.com
> 
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest

From: Adam Montville <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 14 Feb 2012 21:12:51 +0000
Accept-Language: en-US
Subject: [scap_interest] Operational Aspects

While we're all bantering about on security automation, there's another side to the story.  Are there any operational concerns we might address within a WG should one be formed?  For example, we have, in the United States, NVD hosting a repository of information.  CCE identifiers are moderated and assigned by an operational process.  As new enumerations are published and new types of content are conceived, it's easy to imagine the need for some operational standardization.

Should we consider standardizing some of these processes, and if so would the WG we seek to establish be the appropriate place for that work?

Regards,

Adam W. Montville | Security and Compliance Architect

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

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

From: Adam Montville <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 14 Feb 2012 21:09:34 +0000
Accept-Language: en-US
Subject: [scap_interest] Just throwing this out there: Compliance Frameworks

All,

I had a brief discussion with several members of this list with respect to compliance frameworks, which met some resistance.  Still, I think presenting the idea to a larger audience to solicit feedback is a good idea.

>From an automation perspective, it seems that some method of being able to map benchmark-level tests to some higher level policy representation may be warranted.  At the end of the day, we perform assessments to ensure that we are in a secure state � to be compliant with a particular set of policies.

Is there any interest in being able to represent a compliance framework with either a new specification or potentially revitalizing and extending an existing specification (CCI: http://iase.disa.mil/stigs/cci.html), or to simply rely upon any existing commercial efforts, such as UCF (https://www.unifiedcompliance.com)?

Or, is this type of representation simply not needed � there's enough there, the present demand doesn't justify the work, or something else?

Thoughts?

Regards,

Adam W. Montville | Security and Compliance Architect

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

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

From: Adam Montville <[email-masked]>
To: Karen Scarfone <[email-masked]>
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Gaps in Risk Management

Great points, Karen!  These are issues that should be discussed.  Maybe the end goal would be to get to an ability to represent risk, but the interim step is to more completely represent vulnerabilities and their relationships.  Whatever we come up with for the automation piece should certainly feed into a larger risk management picture which could take into account the "human vulnerability" measurements.  In other words, I believe that we can provide risk measurement in a modular way, where conveying misconfiguration risk would complement vulnerability risk, and vice versa, without necessarily requiring the other elements of risk management to be present � these would feed up into the risk management system.

I could see vocabulary of relationships being established as part of closing these gaps.  At the same time, we could be working to understand the variety of risk management frameworks that are out there and determine how to feed our data into those in an appropriate manner � this seems to imply a risk reporting effort of some kind.

BTW, I wholeheartedly agree that relating configuration items to other configuration items is an issue that needs to be addressed.  If we look at many control frameworks, we'll see some control with a derived requirement for "strong authentication."  What does that mean for a Windows Server 2008 box managing users with user/pass credentials?  We have to take into account not just password length, history, complexity and the like, but also account management settings (lockout, threshold and so on) and attack effectiveness as well (so it's not just relating configuration items to other configuration items).  It becomes rather complicated.

Adam

From: Karen Scarfone <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 15:57:18 -0500
To: Adam Montville <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Gaps in Risk Management

A few quick thoughts on this:

* We can't aggregate all these vulnerabilities unless we can model their relationships. For example, a particular configuration setting might nullify the applicability of a particular software flaw, and configuration settings certainly affect each other.

* There's a whole other class of vulnerabilities besides software flaws and configurations. Basically, any other vulnerability can be considered a trust misuse/abuse vulnerability: social engineering and insider attacks, for example. A risk management methodology that addresses software flaws and misconfigurations is inadequate if it doesn't capture the other vulnerabilities as well. We do have a spec, CMSS, designed to provide scoring for these vulnerabilities just like CVSS does for software flaws and CCSS does for misconfigurations. What we don't yet have is a (heaven help me) dictionary or taxonomy of CMSS vulnerabilities. (Fortunately, I'd expect this to be pretty small and straightforward to create, compared to CVE and CCE).

Karen

On Tue, Feb 14, 2012 at 3:51 PM, Adam Montville <[email-masked]<mailto:[email-masked]>> wrote:
All,

Security automation seeks to automate what we can ultimately within the framework of risk management.  Scoring is not enough to measure risk.  What appears to be needed is a method by which we can automate risk measurement.  It would be interesting to discuss various ways in which such automation might be achieved along both qualitative and quantitative lines.

The scoring methods we have in place today for vulnerabilities and configurations (CVSS and CCSS respectively) can measure risk of a particular instance of a class of concepts in our domain.  What I don't see being possible at this point is a way to measure the aggregate instances of vulnerabilities and misconfigurations for some set of assets (whether that be a single asset or a composite asset representing an entire network).

Risk management methodologies are not scarce � NIST, ISO, CobiT, OCTAVE and others all present some method of managing risk, and they are similar.  How can we apply automation in support of these various risk management methods while providing both qualitative and quantitative risk assessment under the hood?

Regards,

Adam W. Montville | Security and Compliance Architect

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

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

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

--
Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
[email-masked]<mailto:[email-masked]>   (703)401-1018

From: "Kunz, Andrea A." <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 14 Feb 2012 21:06:47 +0000
Accept-Language: en-US
Subject: [scap_interest] Putting SCAP to work

If this mail group is open to all items related to SCAP, I'd like to put in my two cents for the places where it is currently being used, or at least, where it's ready to be used. 

If anyone out there has practical experience with or awareness of  the HBSS Policy Auditor and how it works with XCCDF Benchmarks and OVAL policy, I would definitely like to engage in some discourse.

Andrea

Date: Tue, 14 Feb 2012 15:57:18 -0500
From: Karen Scarfone <[email-masked]>
To: Adam Montville <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Gaps in Risk Management

--e89a8f2348ab2fcbf804b8f2d76d
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

A few quick thoughts on this:

* We can't aggregate all these vulnerabilities unless we can model their
relationships. For example, a particular configuration setting might
nullify the applicability of a particular software flaw, and configuration
settings certainly affect each other.

* There's a whole other class of vulnerabilities besides software flaws and
configurations. Basically, any other vulnerability can be considered a
trust misuse/abuse vulnerability: social engineering and insider attacks,
for example. A risk management methodology that addresses software flaws
and misconfigurations is inadequate if it doesn't capture the other
vulnerabilities as well. We do have a spec, CMSS, designed to provide
scoring for these vulnerabilities just like CVSS does for software flaws
and CCSS does for misconfigurations. What we don't yet have is a (heaven
help me) dictionary or taxonomy of CMSS vulnerabilities. (Fortunately, I'd
expect this to be pretty small and straightforward to create, compared to
CVE and CCE).

Karen

On Tue, Feb 14, 2012 at 3:51 PM, Adam Montville <[email-masked]>wrote:

> All,
>
> Security automation seeks to automate what we can ultimately within the
> framework of risk management.  Scoring is not enough to measure risk.  What
> appears to be needed is a method by which we can automate risk measurement.
>  It would be interesting to discuss various ways in which such automation
> might be achieved along both qualitative and quantitative lines.
>
> The scoring methods we have in place today for vulnerabilities and
> configurations (CVSS and CCSS respectively) can measure risk of a
> particular instance of a class of concepts in our domain.  What I don't see
> being possible at this point is a way to measure the aggregate instances of
> vulnerabilities and misconfigurations for some set of assets (whether that
> be a single asset or a composite asset representing an entire network).
>
> Risk management methodologies are not scarce � NIST, ISO, CobiT, OCTAVE
> and others all present some method of managing risk, and they are similar.
>  How can we apply automation in support of these various risk management
> methods while providing both qualitative and quantitative risk assessment
> under the hood?
>
> Regards,
>
> Adam W. Montville | Security and Compliance Architect
>
> Direct: 503 276-7661
> Mobile: 360 471-7815
>
> TRIPWIRE | Take CONTROL
> http://www.tripwire.com
>
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest
>

-- 
Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
[email-masked]   (703)401-1018

--e89a8f2348ab2fcbf804b8f2d76d
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

A few quick thoughts on this:<div><br></div><div>* We can&#39;t aggregate all these vulnerabilities unless we can model their relationships. For example, a particular configuration setting might nullify the applicability of a particular software flaw, and configuration settings certainly affect each other.</div>
<div><br></div><div>* There&#39;s a whole other class of vulnerabilities besides software flaws and configurations. Basically, any other vulnerability can be considered a trust misuse/abuse vulnerability: social engineering and insider attacks, for example. A risk management methodology that addresses software flaws and misconfigurations is inadequate if it doesn&#39;t capture the other vulnerabilities as well. We do have a spec, CMSS, designed to provide scoring for these vulnerabilities just like CVSS does for software flaws and CCSS does for misconfigurations. What we don&#39;t yet have is a (heaven help me) dictionary or taxonomy of CMSS vulnerabilities. (Fortunately, I&#39;d expect this to be pretty small and straightforward to create, compared to CVE and CCE).</div>
<div><br><br>Karen</div><div><br><div class="gmail_quote">On Tue, Feb 14, 2012 at 3:51 PM, Adam Montville <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
All,<br>
<br>
Security automation seeks to automate what we can ultimately within the framework of risk management. �Scoring is not enough to measure risk. �What appears to be needed is a method by which we can automate risk measurement. �It would be interesting to discuss various ways in which such automation might be achieved along both qualitative and quantitative lines.<br>

<br>
The scoring methods we have in place today for vulnerabilities and configurations (CVSS and CCSS respectively) can measure risk of a particular instance of a class of concepts in our domain. �What I don&#39;t see being possible at this point is a way to measure the aggregate instances of vulnerabilities and misconfigurations for some set of assets (whether that be a single asset or a composite asset representing an entire network).<br>

<br>
Risk management methodologies are not scarce � NIST, ISO, CobiT, OCTAVE and others all present some method of managing risk, and they are similar. �How can we apply automation in support of these various risk management methods while providing both qualitative and quantitative risk assessment under the hood?<br>

<br>
Regards,<br>
<br>
Adam W. Montville | Security and Compliance Architect<br>
<br>
Direct: 503 276-7661<br>
Mobile: 360 471-7815<br>
<br>
TRIPWIRE | Take CONTROL<br>
<a href="http://www.tripwire.com" target="_blank">http://www.tripwire.com</a><br>
<br>
_______________________________________________<br>
scap_interest mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/scap_interest" target="_blank">https://www.ietf.org/mailman/listinfo/scap_interest</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Karen Scarfone, Principal Consultant, Scarfone Cybersecurity<br><a href="mailto:[email-masked]" target="_blank">[email-masked]</a>�� (703)401-1018<br>
<br>
</div>

--e89a8f2348ab2fcbf804b8f2d76d--

From: Adam Montville <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 14 Feb 2012 20:51:03 +0000
Accept-Language: en-US
Subject: [scap_interest] Gaps in Risk Management

All,

Security automation seeks to automate what we can ultimately within the framework of risk management.  Scoring is not enough to measure risk.  What appears to be needed is a method by which we can automate risk measurement.  It would be interesting to discuss various ways in which such automation might be achieved along both qualitative and quantitative lines.

The scoring methods we have in place today for vulnerabilities and configurations (CVSS and CCSS respectively) can measure risk of a particular instance of a class of concepts in our domain.  What I don't see being possible at this point is a way to measure the aggregate instances of vulnerabilities and misconfigurations for some set of assets (whether that be a single asset or a composite asset representing an entire network).

Risk management methodologies are not scarce � NIST, ISO, CobiT, OCTAVE and others all present some method of managing risk, and they are similar.  How can we apply automation in support of these various risk management methods while providing both qualitative and quantitative risk assessment under the hood?

Regards,

Adam W. Montville | Security and Compliance Architect

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

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

From: Adam Montville <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 14 Feb 2012 20:50:27 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [scap_interest] Checking language needs

Kent,

I think scheduling should be a separate concern, but can see targeting being embedded in the checking system, much as it is today in OVAL (in a way, the inventory definitions perform the targeting for technical checks).  If we were to leverage Asset Identification, the targeting could be handled in some cases with a simple ai:asset reference � a person is targeted as the owner of the given system.

Adam

From: kent_landfield <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 14:30:27 -0600
To: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Checking language needs

Thanks Karen!  I'll take you up on that!

>From the standpoint of what should be included beyond the actual integration issues, should this document, in addition to integration, discuss issues such as targeting and scheduling for interrogative checking systems like OCIL or would folks consider that a separate issue to be dealt with somewhere else?

Thoughts?

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Karen Scarfone <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 14:11:21 -0600
To: Kent Landfield <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Checking language needs

Kent,

I'd be happy to help with the publication/editing side of specification development.

Karen

On Tue, Feb 14, 2012 at 3:02 PM, <[email-masked]<mailto:[email-masked]>> wrote:
All,

One of the missing pieces we have right now is a standardized approach to developing new checking languages.  Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF.  The later's adoption rate has been seriously impacted because of that.  Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages.  Scripting is also being done directly from XCCDF benchmarks by multiple vendor products.

As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means.  Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today.  Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting.  Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches.  Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.

>From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place.  We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate effectively.  By specifying the practices and items  new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.

I am looking for interest here and for those that might want to help me in producing this draft specification.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

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

--
Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
[email-masked]<mailto:[email-masked]>   (703)401-1018

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

From: Luis Nunez <[email-masked]>
Date: Tue, 14 Feb 2012 15:45:12 -0500
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [scap_interest] Checking language needs

--Apple-Mail=_7FB1772F-2054-4A49-BE65-36E8D93A047F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I would think "targeting and scheduling for interrogative checking..." would be part of the document.

XCCDF is the benchmark for security automation checking.
OCIL is the human intervention for checking.

The Security Technical Implementation Guide (STIG) as an example has both automation (XCCDF) and manual verification checks (OCIL). Although the the most STIGs come in XCCDF format I know of no OCIL that accompanies it (Yet). It would be good to have guidance on how one would cover both.

-ln

On Feb 14, 2012, at 3:30 PM, <[email-masked]> wrote:

> Thanks Karen!  I'll take you up on that!
> 
> From the standpoint of what should be included beyond the actual integration issues, should this document, in addition to integration, discuss issues such as targeting and scheduling for interrogative checking systems like OCIL or would folks consider that a separate issue to be dealt with somewhere else?
> 
> Thoughts?
> 
> Kent Landfield
> Director Content Strategy, Architecture and Standards
> 
> McAfee | An Intel Company
> 5000 Headquarters Dr.
> Plano, Texas 75024
> 
> Direct: +1.972.963.7096 
> Mobile: +1.817.637.8026
> Web: www.mcafee.com
> 
> From: Karen Scarfone <[email-masked]>
> Date: Tue, 14 Feb 2012 14:11:21 -0600
> To: Kent Landfield <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [scap_interest] Checking language needs
> 
>> Kent,
>> 
>> I'd be happy to help with the publication/editing side of specification development.
>> 
>> 
>> Karen
>> 
>> On Tue, Feb 14, 2012 at 3:02 PM, <[email-masked]> wrote:
>>> All,
>>> 
>>> One of the missing pieces we have right now is a standardized approach to developing new checking languages.  Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF.  The later's adoption rate has been seriously impacted because of that.  Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages.  Scripting is also being done directly from XCCDF benchmarks by multiple vendor products.  
>>> 
>>> As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means.  Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today.  Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting.  Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches.  Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.
>>> 
>>> From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place.  We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate effectively.  By specifying the practices and items  new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.
>>> 
>>> I am looking for interest here and for those that might want to help me in producing this draft specification.  
>>> 
>>> Kent Landfield
>>> Director Content Strategy, Architecture and Standards
>>> 
>>> McAfee | An Intel Company
>>> 5000 Headquarters Dr.
>>> Plano, Texas 75024
>>> 
>>> Direct: +1.972.963.7096 
>>> Mobile: +1.817.637.8026
>>> Web: www.mcafee.com
>>> 
>>> _______________________________________________
>>> scap_interest mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/scap_interest
>>> 
>> 
>> 
>> 
>> -- 
>> Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
>> [email-masked]   (703)401-1018
>> 
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest

--Apple-Mail=_7FB1772F-2054-4A49-BE65-36E8D93A047F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I would think "targeting and scheduling for interrogative checking..." would be part of the document.</div><div><br></div><div>XCCDF is the benchmark for security automation checking.</div><div>OCIL is the human intervention for checking.</div><div><br></div><div>The Security Technical Implementation Guide (STIG) as an example has both automation (XCCDF) and manual verification checks (OCIL). Although the the most STIGs come in XCCDF format I know of no OCIL that accompanies it (Yet). It would be good to have guidance on how one would cover both.</div><div><br></div><div>-ln</div><br><div><div>On Feb 14, 2012, at 3:30 PM, &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-family: 'Times New Roman', sans-serif; "><div><div><div>Thanks Karen! &nbsp;I'll take you up on that!</div><div><br></div><div>From the standpoint of what should be included beyond the actual integration issues, should this document, in addition to integration, discuss issues such as t<span class="Apple-style-span" style="font-family: 'Times New Roman', serif; ">argeting and scheduling for interrogative checking systems like OCIL or would folks consider that a separate issue to be dealt with somewhere else?</span></div><div><span class="Apple-style-span" style="font-family: 'Times New Roman', serif; "><br></span></div><div><span class="Apple-style-span" style="font-family: 'Times New Roman', serif; ">Thoughts?</span></div><div><span class="Apple-style-span" style="font-family: 'Times New Roman', serif; "><br></span></div><div><div><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Kent Landfield</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Director Content Strategy, Architecture and Standards</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>McAfee | An Intel Company</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">5000 Headquarters Dr.</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Plano, Texas 75024</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Direct: +1.972.963.7096&nbsp;</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Mobile: +1.817.637.8026</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Web:&nbsp;</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><a href="http://www.mcafee.com/" style="color: rgb(96, 106, 113) !important; ">www.mcafee.com</a></span></div></div></div></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Karen Scarfone &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Date: </span> Tue, 14 Feb 2012 14:11:21 -0600<br><span style="font-weight:bold">To: </span> Kent  Landfield &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Cc: </span> "<a href="mailto:[email-masked]">[email-masked]</a>" &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Subject: </span> Re: [scap_interest] Checking language needs<br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;" type="cite">Kent,<div><br></div><div>I'd be happy to help with the publication/editing side of specification development.</div><div><br></div><div><br></div><div>Karen<br><br><div class="gmail_quote">On Tue, Feb 14, 2012 at 3:02 PM,  <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" type="cite"><div style="font-size:16px;font-family:'Times New Roman',sans-serif;word-wrap:break-word"><div><div><div>All,</div><div><br></div><div>One of the missing pieces we have right now is a standardized approach to developing new checking languages. &nbsp;Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF. &nbsp;The later's adoption rate has been seriously impacted because of that. &nbsp;Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages. &nbsp;Scripting is also being done directly from XCCDF benchmarks by multiple vendor products. &nbsp;</div><div><br></div><div>As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means. &nbsp;Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today. &nbsp;Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting. &nbsp;Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches. &nbsp;Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.</div><div><br></div><div>From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place. &nbsp;We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate&nbsp;effectively. &nbsp;By specifying the practices and items &nbsp;new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.</div><div><br></div><div>I am looking for interest here and for those that might want to help me in producing this draft specification. &nbsp;</div><div><br></div><div><div><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><strong>Kent Landfield</strong></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; ">Director Content Strategy, Architecture and Standards</span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><strong>McAfee | An Intel Company</strong></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; ">5000 Headquarters Dr.</span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; ">Plano, Texas 75024</span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; ">Direct: +1.972.963.7096&nbsp;</span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; ">Mobile: +1.817.637.8026</span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><strong>Web:&nbsp;</strong></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><a href="http://www.mcafee.com/" style="color:rgb(96,106,113)!important" target="_blank">www.mcafee.com</a></span></div></div></div></div></div><br>_______________________________________________<br>
scap_interest mailing list<br><a href="mailto:[email-masked]">[email-masked]</a><br><a href="https://www.ietf.org/mailman/listinfo/scap_interest" target="_blank">https://www.ietf.org/mailman/listinfo/scap_interest</a><br><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Karen Scarfone, Principal Consultant, Scarfone Cybersecurity<br><a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&nbsp;&nbsp; (703)401-1018<br><br></div></blockquote></span></div>
_______________________________________________<br>scap_interest mailing list<br><a href="mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.org/mailman/listinfo/scap_interest<br></blockquote></div><br></body></html>
--Apple-Mail=_7FB1772F-2054-4A49-BE65-36E8D93A047F--

From: Luis Nunez <[email-masked]>
Date: Tue, 14 Feb 2012 15:33:45 -0500
To: Karen Scarfone <[email-masked]>
Cc: [email-masked]
Subject: Re: [scap_interest] Checking language needs

--Apple-Mail=_6F31A0FF-BCD8-4A17-A1EC-A3ED587F7E53
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

This sounds like something that would be helpful is understanding the cooperative aspects of the specifications.  Looking at how these specifications (XCCDF, OVAL,...) interoperate from a relationship standpoint would be usefully and could help others in understanding. One of the toughest issues I have is explaining what SCAPOVALXCCDFCPECCEVECVESS is,  let along how they work in concert.

-ln

On Feb 14, 2012, at 3:11 PM, Karen Scarfone wrote:

> Kent,
> 
> I'd be happy to help with the publication/editing side of specification development.
> 
> 
> Karen
> 
> On Tue, Feb 14, 2012 at 3:02 PM, <[email-masked]> wrote:
> All,
> 
> One of the missing pieces we have right now is a standardized approach to developing new checking languages.  Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF.  The later's adoption rate has been seriously impacted because of that.  Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages.  Scripting is also being done directly from XCCDF benchmarks by multiple vendor products.  
> 
> As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means.  Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today.  Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting.  Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches.  Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.
> 
> From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place.  We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate effectively.  By specifying the practices and items  new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.
> 
> I am looking for interest here and for those that might want to help me in producing this draft specification.  
> 
> Kent Landfield
> Director Content Strategy, Architecture and Standards
> 
> McAfee | An Intel Company
> 5000 Headquarters Dr.
> Plano, Texas 75024
> 
> Direct: +1.972.963.7096 
> Mobile: +1.817.637.8026
> Web: www.mcafee.com
> 
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest
> 
> 
> 
> 
> -- 
> Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
> [email-masked]   (703)401-1018
> 
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest

--Apple-Mail=_6F31A0FF-BCD8-4A17-A1EC-A3ED587F7E53
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">This sounds like something that would be helpful is understanding the cooperative aspects of the specifications. &nbsp;Looking at how these specifications (XCCDF, OVAL,...) interoperate from a relationship standpoint would be usefully and could help others in understanding. One of the toughest issues I have is explaining what SCAPOVALXCCDFCPECCEVECVESS is, &nbsp;let along how they work in concert.<div><br></div><div><br></div><div>-ln</div><div><br><div><div>On Feb 14, 2012, at 3:11 PM, Karen Scarfone wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Kent,<div><br></div><div>I'd be happy to help with the publication/editing side of specification development.</div><div><br></div><div><br></div><div>Karen<br><br><div class="gmail_quote">On Tue, Feb 14, 2012 at 3:02 PM,  <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:16px;font-family:'Times New Roman',sans-serif;word-wrap:break-word"><div><div><div>All,</div>
<div><br></div><div>One of the missing pieces we have right now is a standardized approach to developing new checking languages. &nbsp;Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF. &nbsp;The later's adoption rate has been seriously impacted because of that. &nbsp;Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages. &nbsp;Scripting is also being done directly from XCCDF benchmarks by multiple vendor products. &nbsp;</div>
<div><br></div><div>As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means. &nbsp;Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today. &nbsp;Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting. &nbsp;Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches. &nbsp;Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.</div>
<div><br></div><div>From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place. &nbsp;We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate&nbsp;effectively. &nbsp;By specifying the practices and items &nbsp;new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.</div>
<div><br></div><div>I am looking for interest here and for those that might want to help me in producing this draft specification. &nbsp;</div><div><br></div><div><div><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><strong>Kent Landfield</strong></span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br>
</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif">Director Content Strategy, Architecture and Standards</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br>
</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br></span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><strong>McAfee | An Intel Company</strong></span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br>
</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif">5000 Headquarters Dr.</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br></span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif">Plano, Texas 75024</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br>
</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br></span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif">Direct: +1.972.963.7096&nbsp;</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br>
</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif">Mobile: +1.817.637.8026</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br>
</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><strong>Web:&nbsp;</strong></span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><a href="http://www.mcafee.com/" style="color:rgb(96,106,113)!important" target="_blank">www.mcafee.com</a></span></div>
</div></div></div></div>
<br>_______________________________________________<br>
scap_interest mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/scap_interest" target="_blank">https://www.ietf.org/mailman/listinfo/scap_interest</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Karen Scarfone, Principal Consultant, Scarfone Cybersecurity<br><a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&nbsp;&nbsp; (703)401-1018<br>
<br>
</div>
_______________________________________________<br>scap_interest mailing list<br><a href="mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.org/mailman/listinfo/scap_interest<br></blockquote></div><br></div></body></html>
--Apple-Mail=_6F31A0FF-BCD8-4A17-A1EC-A3ED587F7E53--

From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 14 Feb 2012 14:30:27 -0600
Accept-Language: en-US
acceptlanguage: en-US
Cc: [email-masked]
Subject: Re: [scap_interest] Checking language needs

--_000_CB601FB12C503kentlandfieldmcafeecom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks Karen!  I'll take you up on that!

>From the standpoint of what should be included beyond the actual integration issues, should this document, in addition to integration, discuss issues such as targeting and scheduling for interrogative checking systems like OCIL or would folks consider that a separate issue to be dealt with somewhere else?

Thoughts?

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: Karen Scarfone <[email-masked]<mailto:[email-masked]>>
Date: Tue, 14 Feb 2012 14:11:21 -0600
To: Kent Landfield <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scap_interest] Checking language needs

Kent,

I'd be happy to help with the publication/editing side of specification development.

Karen

On Tue, Feb 14, 2012 at 3:02 PM, <[email-masked]<mailto:[email-masked]>> wrote:
All,

One of the missing pieces we have right now is a standardized approach to developing new checking languages.  Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF.  The later's adoption rate has been seriously impacted because of that.  Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages.  Scripting is also being done directly from XCCDF benchmarks by multiple vendor products.

As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means.  Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today.  Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting.  Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches.  Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.

>From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place.  We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate effectively.  By specifying the practices and items  new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.

I am looking for interest here and for those that might want to help me in producing this draft specification.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

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

--
Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
[email-masked]<mailto:[email-masked]>   (703)401-1018

--_000_CB601FB12C503kentlandfieldmcafeecom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-family: 'Times New Roman', sans-serif; "><div><div><div>Thanks Karen! &nbsp;I'll take you up on that!</div><div><br></div><div>From the standpoint of what should be included beyond the actual integration issues, should this document, in addition to integration, discuss issues such as t<span class="Apple-style-span" style="font-family: 'Times New Roman', serif; ">argeting and scheduling for interrogative checking systems like OCIL or would folks consider that a separate issue to be dealt with somewhere else?</span></div><div><span class="Apple-style-span" style="font-family: 'Times New Roman', serif; "><br></span></div><div><span class="Apple-style-span" style="font-family: 'Times New Roman', serif; ">Thoughts?</span></div><div><span class="Apple-style-span" style="font-family: 'Times New Roman', serif; "><br></span></div><div><div><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Kent Landfield</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Director Content Strategy, Architecture and Standards</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>McAfee | An Intel Company</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">5000 Headquarters Dr.</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Plano, Texas 75024</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Direct: +1.972.963.7096&nbsp;</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Mobile: +1.817.637.8026</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Web:&nbsp;</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><a href="http://www.mcafee.com/" style="color: rgb(96, 106, 113) !important; ">www.mcafee.com</a></span></div></div></div></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Karen Scarfone &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Date: </span> Tue, 14 Feb 2012 14:11:21 -0600<br><span style="font-weight:bold">To: </span> Kent  Landfield &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Cc: </span> "<a href="mailto:[email-masked]">[email-masked]</a>" &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br><span style="font-weight:bold">Subject: </span> Re: [scap_interest] Checking language needs<br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">Kent,<div><br></div><div>I'd be happy to help with the publication/editing side of specification development.</div><div><br></div><div><br></div><div>Karen<br><br><div class="gmail_quote">On Tue, Feb 14, 2012 at 3:02 PM,  <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:16px;font-family:'Times New Roman',sans-serif;word-wrap:break-word"><div><div><div>All,</div><div><br></div><div>One of the missing pieces we have right now is a standardized approach to developing new checking languages. &nbsp;Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF. &nbsp;The later's adoption rate has been seriously impacted because of that. &nbsp;Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages. &nbsp;Scripting is also being done directly from XCCDF benchmarks by multiple vendor products. &nbsp;</div><div><br></div><div>As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means. &nbsp;Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today. &nbsp;Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting. &nbsp;Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches. &nbsp;Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.</div><div><br></div><div>From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place. &nbsp;We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate&nbsp;effectively. &nbsp;By specifying the practices and items &nbsp;new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.</div><div><br></div><div>I am looking for interest here and for those that might want to help me in producing this draft specification. &nbsp;</div><div><br></div><div><div><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><strong>Kent Landfield</strong></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; ">Director Content Strategy, Architecture and Standards</span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><strong>McAfee | An Intel Company</strong></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; ">5000 Headquarters Dr.</span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; ">Plano, Texas 75024</span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; ">Direct: +1.972.963.7096&nbsp;</span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; ">Mobile: +1.817.637.8026</span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><br></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><strong>Web:&nbsp;</strong></span><span style="font-size: 12px; color: rgb(96, 106, 113); font-family: Arial, Helvetica, sans-serif; "><a href="http://www.mcafee.com/" style="color:rgb(96,106,113)!important" target="_blank">www.mcafee.com</a></span></div></div></div></div></div><br>_______________________________________________<br>
scap_interest mailing list<br><a href="mailto:[email-masked]">[email-masked]</a><br><a href="https://www.ietf.org/mailman/listinfo/scap_interest" target="_blank">https://www.ietf.org/mailman/listinfo/scap_interest</a><br><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Karen Scarfone, Principal Consultant, Scarfone Cybersecurity<br><a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&nbsp;&nbsp; (703)401-1018<br><br></div></blockquote></span></body></html>

--_000_CB601FB12C503kentlandfieldmcafeecom_--

Date: Tue, 14 Feb 2012 15:11:21 -0500
From: Karen Scarfone <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [scap_interest] Checking language needs

--f46d043086c0d61cfb04b8f232ed
Content-Type: text/plain; charset=ISO-8859-1

Kent,

I'd be happy to help with the publication/editing side of specification
development.

Karen

On Tue, Feb 14, 2012 at 3:02 PM, <[email-masked]> wrote:

> All,
>
> One of the missing pieces we have right now is a standardized approach to
> developing new checking languages.  Within fielded XCCDF-enabled products
> today there are multiple checking languages in use. One of them grew up
> with XCCDF (OVAL) and another (OCIL) was developed without much concern for
> how it might be called and used from XCCDF.  The later's adoption rate has
> been seriously impacted because of that.  Additionally, vendors have at
> times introduced their own checking mechanisms to support customer needs
> that could not be supported with the existing checking languages.
>  Scripting is also being done directly from XCCDF benchmarks by multiple
> vendor products.
>
> As we are starting to expand security automation uses, it is important we
> enable innovative approaches to check execution. Not everything can be done
> using the existing model and existing means.  Continuous monitoring uses
> are going to require more flexibility by requiring different means to check
> certain areas than exist today.  Forcing implementers to have to dig thru
> the XCCDF specification to have to figure out how to properly integrate
> with it is an inhibitor. We need to foster alternative means so integrating
> into the the existing security automation architectures and products is not
> so daunting.  Even in areas where something as simple as scripting is used,
> I would be very surprised if two existing implementations could execute the
> same script content because of incompatible implementation approaches.
>  Yes, OVAL is interoperable today but we need to make sure additional
> checking languages have that same potential for interoperability.
>
> From my perspective, the key to the success in fielding a useful framework
> is assuring the right building blocks are in place.  We need to be able to
> leverage those building blocks to expand standards based security
> automation. It is important we document the proper way to develop new
> checking mechanisms if we are to have content and solutions that
> interoperate effectively.  By specifying the practices and items  new
> checking languages need to support, we can expand what is possible with
> security automation using already fielded tools and environments.
>
> I am looking for interest here and for those that might want to help me in
> producing this draft specification.
>
> *Kent Landfield*
> Director Content Strategy, Architecture and Standards
>
> *McAfee | An Intel Company*
> 5000 Headquarters Dr.
> Plano, Texas 75024
>
> Direct: +1.972.963.7096
> Mobile: +1.817.637.8026
> *Web: *www.mcafee.com
>
> _______________________________________________
> scap_interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scap_interest
>
>

-- 
Karen Scarfone, Principal Consultant, Scarfone Cybersecurity
[email-masked]   (703)401-1018

--f46d043086c0d61cfb04b8f232ed
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Kent,<div><br></div><div>I&#39;d be happy to help with the publication/editing side of specification development.</div><div><br></div><div><br></div><div>Karen<br><br><div class="gmail_quote">On Tue, Feb 14, 2012 at 3:02 PM,  <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:16px;font-family:&#39;Times New Roman&#39;,sans-serif;word-wrap:break-word"><div><div><div>All,</div>
<div><br></div><div>One of the missing pieces we have right now is a standardized approach to developing new checking languages. �Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF. �The later&#39;s adoption rate has been seriously impacted because of that. �Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages. �Scripting is also being done directly from XCCDF benchmarks by multiple vendor products. �</div>
<div><br></div><div>As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means. �Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today. �Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting. �Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches. �Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.</div>
<div><br></div><div>From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place. �We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate�effectively. �By specifying the practices and items �new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.</div>
<div><br></div><div>I am looking for interest here and for those that might want to help me in producing this draft specification. �</div><div><br></div><div><div><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><strong>Kent Landfield</strong></span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br>
</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif">Director Content Strategy, Architecture and Standards</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br>
</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br></span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><strong>McAfee | An Intel Company</strong></span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br>
</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif">5000 Headquarters Dr.</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br></span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif">Plano, Texas 75024</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br>
</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br></span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif">Direct: +1.972.963.7096�</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br>
</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif">Mobile: +1.817.637.8026</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><br>
</span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><strong>Web:�</strong></span><span style="font-size:12px;color:rgb(96,106,113);font-family:Arial,Helvetica,sans-serif"><a href="http://www.mcafee.com/" style="color:rgb(96,106,113)!important" target="_blank">www.mcafee.com</a></span></div>
</div></div></div></div>
<br>_______________________________________________<br>
scap_interest mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/scap_interest" target="_blank">https://www.ietf.org/mailman/listinfo/scap_interest</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Karen Scarfone, Principal Consultant, Scarfone Cybersecurity<br><a href="mailto:[email-masked]" target="_blank">[email-masked]</a>�� (703)401-1018<br>
<br>
</div>

--f46d043086c0d61cfb04b8f232ed--

From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 14 Feb 2012 14:02:20 -0600
Accept-Language: en-US
acceptlanguage: en-US
Subject: [scap_interest] Checking language needs

--_000_CB6019EB2C4E5kentlandfieldmcafeecom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,

One of the missing pieces we have right now is a standardized approach to developing new checking languages.  Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF.  The later's adoption rate has been seriously impacted because of that.  Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages.  Scripting is also being done directly from XCCDF benchmarks by multiple vendor products.

As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means.  Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today.  Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting.  Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches.  Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.

>From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place.  We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate effectively.  By specifying the practices and items  new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.

I am looking for interest here and for those that might want to help me in producing this draft specification.

Kent Landfield
Director Content Strategy, Architecture and Standards

McAfee | An Intel Company
5000 Headquarters Dr.
Plano, Texas 75024

Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

--_000_CB6019EB2C4E5kentlandfieldmcafeecom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 16px; font-family: 'Times New Roman', sans-serif; "><div><div><div>All,</div><div><br></div><div>One of the missing pieces we have right now is a standardized approach to developing new checking languages. &nbsp;Within fielded XCCDF-enabled products today there are multiple checking languages in use. One of them grew up with XCCDF (OVAL) and another (OCIL) was developed without much concern for how it might be called and used from XCCDF. &nbsp;The later's adoption rate has been seriously impacted because of that. &nbsp;Additionally, vendors have at times introduced their own checking mechanisms to support customer needs that could not be supported with the existing checking languages. &nbsp;Scripting is also being done directly from XCCDF benchmarks by multiple vendor products. &nbsp;</div><div><br></div><div>As we are starting to expand security automation uses, it is important we enable innovative approaches to check execution. Not everything can be done using the existing model and existing means. &nbsp;Continuous monitoring uses are going to require more flexibility by requiring different means to check certain areas than exist today. &nbsp;Forcing implementers to have to dig thru the XCCDF specification to have to figure out how to properly integrate with it is an inhibitor. We need to foster alternative means so integrating into the the existing security automation architectures and products is not so daunting. &nbsp;Even in areas where something as simple as scripting is used, I would be very surprised if two existing implementations could execute the same script content because of incompatible implementation approaches. &nbsp;Yes, OVAL is interoperable today but we need to make sure additional checking languages have that same potential for interoperability.</div><div><br></div><div>From my perspective, the key to the success in fielding a useful framework is assuring the right building blocks are in place. &nbsp;We need to be able to leverage those building blocks to expand standards based security automation. It is important we document the proper way to develop new checking mechanisms if we are to have content and solutions that interoperate&nbsp;effectively. &nbsp;By specifying the practices and items &nbsp;new checking languages need to support, we can expand what is possible with security automation using already fielded tools and environments.</div><div><br></div><div>I am looking for interest here and for those that might want to help me in producing this draft specification. &nbsp;</div><div><br></div><div><div><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Kent Landfield</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Director Content Strategy, Architecture and Standards</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>McAfee | An Intel Company</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">5000 Headquarters Dr.</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Plano, Texas 75024</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Direct: +1.972.963.7096&nbsp;</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; ">Mobile: +1.817.637.8026</span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><br></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><strong>Web:&nbsp;</strong></span><span class="Apple-style-span" style="font-size: 12px; color: rgb(96, 106, 113); -webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px; font-family: Arial, Helvetica, sans-serif; "><a href="http://www.mcafee.com/" style="color: rgb(96, 106, 113) !important; ">www.mcafee.com</a></span></div></div></div></div></body></html>

--_000_CB6019EB2C4E5kentlandfieldmcafeecom_--

From: <[email-masked]>
To: <[email-masked]>
Date: Tue, 14 Feb 2012 09:47:14 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: [scap_interest] Security automation and MILE

Greetings,

In support of this effort, I plan to write and submit a draft very soon to show the relevance of this work to the IETF work in MILE.  The Structured Cybersecurity Information draft that extends IODEF is a very clear connection.  The GRC-Exchange work is another connection point.  Once I have it posted, I will share the link to this mailing list.

Best regards,
Kathleen

From: Adam Montville <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 13 Feb 2012 22:16:18 +0000
Accept-Language: en-US
Subject: [scap_interest] IETF 83 Birds of a Feather Session Preparation

--_002_CB5E56178F09amontvilletripwirecom_
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: quoted-printable

All:

You may recall that in November 2010 an IETF BoF was held with the goal of
introducing the IETF community to SCAP and, ultimately, to consider 1)
whether the technology was mature enough for standardization, and 2)
whether such standardization should take place under the auspices of the
IETF.

On February 10, 2012 a Vendor Letter - signed by 16 executive-level
representatives - was sent to various SCAP stakeholders at NIST, DHS,
NCSC, and other US Government agencies.  The Vendor Letter (attached)
demonstrates a 
significant level of support among vendors for moving security automation
development to the IETF.

Now, we seek to schedule a WG-forming BoF session during IETF 83 in Paris.
 As a WG-forming BoF, we will be discussing a charter, potential drafts,
and other important aspects concerning the possible move of security
automation development to the IETF.

I invite all vendors, government representatives, specification authors
and contributors to engage in a discussion on the scap_interest list (to
subscribe visit: https://www.ietf.org/mailman/listinfo/scap_interest).
Such discussion should occur before IETF 83 and cover what moving security
automation development to the IETF would mean, how a WG might be
structured, what a charter might look like, which specifications should be
first drafted, what pieces are missing, and how continuous monitoring
might additionally be included.

IT IS IMPORTANT THAT BOF-RELATED DISCUSSIONS BE CONDUCTED ON THE
SCAP_INTEREST MAILING LIST AND NOT ON INDIVIDUAL SPECIFICATION DEVELOPMENT
LISTS.

The following are areas of concern (in addition to what already exists in
the security automation domain today) we believe would be suitable for
furthering the security automation efforts on a global scale:

  * XCCDF 1.2.1
    * Alternate checking systems
    * Targeting and scheduling for interrogative checking systems
  * Security automation core elements
  * Risk scoring normalization and unification

NOTE: I originally sent this with multiple recipients, but that message
was held for moderation.  I'm "reposting" the message without the
additional recipients.

Regards,

Adam W. Montville | Security and Compliance Architect

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

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

--_002_CB5E56178F09amontvilletripwirecom_
Content-Type: application/pdf;
	name="SCAP-executive_recommendation_letter.pdf"
Content-Description: SCAP-executive_recommendation_letter.pdf
Content-Disposition: attachment;
	filename="SCAP-executive_recommendation_letter.pdf"; size3949;
	creation-date="Mon, 13 Feb 2012 22:16:18 GMT";
	modification-date="Mon, 13 Feb 2012 22:16:18 GMT"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: base64

--_002_CB5E56178F09amontvilletripwirecom_--

From: Adam Montville <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 13 Feb 2012 22:06:40 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, CPE Community Forum <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [scap_interest] IETF 83 Birds of a Feather Session Preparation

--_002_CB5E56178F09amontvilletripwirecom_
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: quoted-printable

All:

You may recall that in November 2010 an IETF BoF was held with the goal of
introducing the IETF community to SCAP and, ultimately, to consider 1)
whether the technology was mature enough for standardization, and 2)
whether such standardization should take place under the auspices of the
IETF.

On February 10, 2012 a Vendor Letter - signed by 16 executive-level
representatives - was sent to various SCAP stakeholders at NIST, DHS,
NCSC, and other US Government agencies.  The Vendor Letter (attached)
demonstrates a 
significant level of support among vendors for moving security automation
development to the IETF.

Now, we seek to schedule a WG-forming BoF session during IETF 83 in Paris.
 As a WG-forming BoF, we will be discussing a charter, potential drafts,
and other important aspects concerning the possible move of security
automation development to the IETF.

I invite all vendors, government representatives, specification authors
and contributors to engage in a discussion on the scap_interest list (to
subscribe visit: https://www.ietf.org/mailman/listinfo/scap_interest).
Such discussion should occur before IETF 83 and cover what moving security
automation development to the IETF would mean, how a WG might be
structured, what a charter might look like, which specifications should be
first drafted, what pieces are missing, and how continuous monitoring
might additionally be included.

IT IS IMPORTANT THAT BOF-RELATED DISCUSSIONS BE CONDUCTED ON THE
SCAP_INTEREST MAILING LIST AND NOT ON INDIVIDUAL SPECIFICATION DEVELOPMENT
LISTS.

The following are areas of concern (in addition to what already exists in
the security automation domain today) we believe would be suitable for
furthering the security automation efforts on a global scale:

  * XCCDF 1.2.1
    * Alternate checking systems
    * Targeting and scheduling for interrogative checking systems
  * Security automation core elements
  * Risk scoring normalization and unification

Finally, if you believe this message should be forwarded to additional
communities of interest, please do so (I may have missed a few).

Regards,

Adam W. Montville | Security and Compliance Architect

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

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

--_002_CB5E56178F09amontvilletripwirecom_
Content-Type: application/pdf;
	name="SCAP-executive_recommendation_letter.pdf"
Content-Description: SCAP-executive_recommendation_letter.pdf
Content-Disposition: attachment;
	filename="SCAP-executive_recommendation_letter.pdf"; size3949;
	creation-date="Mon, 13 Feb 2012 22:06:40 GMT";
	modification-date="Mon, 13 Feb 2012 22:06:40 GMT"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: base64

--_002_CB5E56178F09amontvilletripwirecom_--

From: Luis Nunez <[email-masked]>
Date: Sun, 12 Feb 2012 20:40:17 -0500
To: [email-masked]
Subject: [scap_interest] Hello

Test hello message.

Disregard.

-ln