From bcheikes@mitre.org Mon Oct 1 07:40:39 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BE311E8129 for ; Mon, 1 Oct 2012 07:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kguxOtD0tc7W for ; Mon, 1 Oct 2012 07:40:28 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E89CB11E8117 for ; Mon, 1 Oct 2012 07:40:27 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 338241F08CB; Mon, 1 Oct 2012 10:40:27 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 18FA81F08C7; Mon, 1 Oct 2012 10:40:27 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.99]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.001; Mon, 1 Oct 2012 10:40:26 -0400 From: "Cheikes, Brant A." To: Adam Montville , Jan-Oliver Wagner , "sacm@ietf.org" Thread-Topic: [sacm] SWID and CPE: WAS - Re: SACM BoF Request Thread-Index: AQHNm+oxa562JCBH4kWOKtg6vpwFtJekZeww Date: Mon, 1 Oct 2012 14:40:26 +0000 Message-ID: <808A833A2D415D41996B1CF760901A0A1D87D704@IMCMBX04.MITRE.ORG> References: <201209261228.36242.Jan-Oliver.Wagner@greenbone.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.57] Content-Type: multipart/alternative; boundary="_000_808A833A2D415D41996B1CF760901A0A1D87D704IMCMBX04MITREOR_" MIME-Version: 1.0 Cc: "Moriarty, Kathleen" , "Waltermire, David A." , "Baker, Jon" Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 14:40:40 -0000 --_000_808A833A2D415D41996B1CF760901A0A1D87D704IMCMBX04MITREOR_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm sorry I didn't join this thread sooner, but I'll try to catch up. I've= been leading the CPE project at MITRE for the last three years, and for th= e last year-plus have been working closely with Steve Klos, the Executive D= irector of TagVault.org, to assess similarities/differences between the CPE= and SWID tag standards, and to develop a roadmap that enables the two stan= dards to interoperate in some fashion. Steve and I chaired a session at th= e recent Developer Days workshop on the topic; see: http://cpe.mitre.org/news/index.html#jul272012b CPE names and SWID tags are very different things, with overlapping and non= -overlapping use cases, different value propositions to stakeholders, and d= ifferent procedures for creation and maintenance. The CPE v2.3 standard is= documented in a suite of NIST IRs, and the SWID tag standard is documented= in ISO/IEC 19770-2:2009. This is not the proper venue for tutorials on ei= ther CPE or SWID; I would encourage those who know CPE to learn more about = SWIDs using TagVault.org resources. Also note that Steve Klos will be spea= king today at ITSAC. In my view, both CPE and SWID need to be considered when discussing asset i= nventory solutions. I suspect that SWID tags will eventually replace CPE n= ames, but that will depend on market uptake and on how well we can deploy a= nd use so-called "third-party" SWID tags-non-authoritative tags created by = entities other than the software publisher/creator. Adam is right that SWI= D tagging is a relatively new concept. There aren't many vendors yet who h= ave adopted tags, but there definitely are some, including Symantec and mos= t recently Microsoft. SWIDs are today where CPE was perhaps five years ago= , in terms of adoption and coverage. Give it time. SWID tags are full-fledged XML documents, whereas CPE names are just identi= fying strings assigned by a third party (NIST) to software products. Embed= ded within the SWID tag document is a unique ID, which lacks the readabilit= y of a CPE name but could serve the same function as a CPE name. SWID tags= are associated with individual product releases; CPE names can also be ass= ociated with individual products, but also have the capability to identify = broader classes of a product. You can create a CPE name that generically r= efers to "all Windows 7 operating systems", but you can't do that with a SW= ID tag. The main issue with CPE is that it has a relatively unsustainable O&M profi= le. Since software publishers haven't (and largely won't) adopt CPE and bu= ild CPE names somehow into their products (whatever that might mean; CPE th= us far hasn't addressed this issue), we need a central authority-NIST-to de= vote ongoing resources to maintaining the CPE dictionary, with names arrivi= ng only when submitted by a member of the "CPE community" in response to a = naming need. In contrast, software publishers who adopt SWID tagging creat= e the tags at product release time, and the tag is included in the installa= tion package for the product. When the product is installed, the tag is pl= aced on the endpoint. When the product is uninstalled, the tag is removed.= With the addition of certification and digital signing of tags (not avail= able in CPE), one can have some guarantee that the tag has not been tampere= d with. The TagVault community is considering the addition of a "secure as= set management" certification level, which would require certified tags to = include a "package footprint" element documenting the individual files whic= h comprise the tagged product. These are features well beyond CPE. There was a question about CPE's ability to represent product suites/groups= . You can create a CPE name for "Microsoft Office 2010 Professional", and = you can create separate CPE names for all the products in that suite (Word,= PowerPoint, etc.), but CPE provides no way to represent the fact that by i= nstalling MS Office 2010 you also install all the individual products that = are included. SWID tags let you do that explicitly. That's all for now-I've gone on long enough. I'll try to keep a closer eye= on this thread and do a better job of answering questions as they come up. Cheers, /Brant Brant A. Cheikes The MITRE Corporation 202 Burlington Road, M/S K302 Bedford, MA 01730-1420 Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Ada= m Montville Sent: Wednesday, September 26, 2012 9:23 AM To: Jan-Oliver Wagner; sacm@ietf.org Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon Subject: [sacm] SWID and CPE: WAS - Re: SACM BoF Request This seems like an important discussion. Asset management is, arguably, th= e most important foundational piece of an effective information security pr= ogram, as our use case document [1] recognizes (asset management is the fir= st recognized capability in support of Use Case 1). Clearly, there are pro= s and cons to leveraging CPE and/or SWID, and after quickly reading through= some of the information available at TagVault [2], it seems clear that SWI= Ds are roughly equivalent to CPE for operating systems and applications. Before looking at the differences between CPE and SWID, it's probably a goo= d idea to understand exactly what we need from a software asset classificat= ion scheme not only within our use cases, but also from a couple of control= frameworks our use cases support (I prefer to look at the Critical Audit G= uidelines (CAG) published by SANS and ISO 27002). Both the CAG and 27002 make reference to managing assets, but only in terms= of keeping an inventory. The CAG goes further by explicitly stating (in C= ritical Control 2) that we need to have an inventory of all authorized and = unauthorized software. I don't believe either really mentions anything abo= ut corrective actions, except implicitly in sections related to incident re= sponse. So, we have a clear need to look at an instance of software, classify it, a= nd build or contribute to an identity profile for it for continued referenc= e. Can CPE handle this classification for for us? Yes. Can SWID handle t= his classification for us? It seems so. Note that we should not rely on e= ither of these methods to identify software for targeted actions - that wou= ld be the domain of Asset Identification (we could use CPE or SWID to speci= fy classes of targets for actions). Distribution and operational identification seems important to consider as = well. CPEs aren't installed with the software and require some assessment = action to derive. SWIDs, on the other hand, appear to be distributed by th= e software publisher [3]. Moreover, SWIDs are certified and signed by TagV= ault. I'm unsure of the details about how SWIDs become available on a give= n system (they still need to be actively collected from a target system at = some point). At this point, the difference between the two is really volume of available= "tags" (we can reasonably call a CPE name a "tag" in this context), and th= is is where I see the rubber meeting the road - when an operational compone= nt is implicitly or explicitly required for a standard to work as intended = at scale. There seems to be very little information about SWID volumes available (at = least in the limited time I've had to search around), so it's difficult to = judge how well they've penetrated the market. The last press release from = TagVault is from 2010, which may suggest a dropping off of the effort or a = satisfaction that they've done enough. Information about CPE volume seems = most readily available from NVD [5]. Can anyone on this list provide additional details about SWID? I think it may be useful, from a community perspective, to be able to hand= le both software identification types, provided both are operationally feas= ible and foreseeably sustainable. For example, the ai:software element def= ined by the Asset Identification draft [4] has an optional CPE attribute th= at could just as easily be complemented by an optional SWID attribute. [1] http://tools.ietf.org/html/waltermire-sacm-use-cases-02 [2] http://www.tagvault.org [3] http://www.tagvault.org/swid-tag-lifecycle [4] http://trac.tools.ietf.org/html/draft-montville-sacm-asset-identificati= on-00 [5] http://nvd.nist.gov/cpe.cfm On 9/26/12 3:28 AM, "Jan-Oliver Wagner" > wrote: On Mittwoch, 26. September 2012, Baker, Jon wrote: I am a big fan of SWIDs and believe that we would really benefit from wides= pread SWID adoption. In my previous message, I was attempting to state that= we need capabilities offer by both CPE and SWID. I am a big fan of CPE and believe it is fully compatible with Open Source r= eference implementation and widespread use/adoption in Open Source tools, especially= also in commercial environments. Neglecting CPE in favour of SWID would IMHO be a drawback for widespread se= curity automation because, as to my understanding, SWID is not fully compatible wi= th the vendor-independent approaches. Convince me I am wrong and I'd be happy ;-) (Sorry for jumping in here, it was just something I am worried about since = some time already so I spontaneously reacted on the keywords :-) -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCc= k, HR B 202460 Gesch=E4ftsf=FChrer: Lukas Grunwald, Dr. Jan-Oliver Wagner --_000_808A833A2D415D41996B1CF760901A0A1D87D704IMCMBX04MITREOR_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I’m sorry I didn’t join this t= hread sooner, but I’ll try to catch up.  I’ve been leading= the CPE project at MITRE for the last three years, and for the last year-p= lus have been working closely with Steve Klos, the Executive Director of TagVault.org, t= o assess similarities/differences between the CPE and SWID tag standards, a= nd to develop a roadmap that enables the two standards to interoperate in s= ome fashion.  Steve and I chaired a session at the recent Developer Days workshop on the topic; see:

http://cpe.mitre.org/news/index.html#jul272012b<= /o:p>

 

CPE names and SWID tags are very different= things, with overlapping and non-overlapping use cases, different value pr= opositions to stakeholders, and different procedures for creation and maintenance.  The CPE v2.3 standard is documented in a s= uite of NIST IRs, and the SWID tag standard is documented in ISO/IEC 19770-= 2:2009.  This is not the proper venue for tutorials on either CPE or S= WID; I would encourage those who know CPE to learn more about SWIDs using TagVault.org resources.  Also note th= at Steve Klos will be speaking today at ITSAC.

 

In my view, both CPE and SWID need to be c= onsidered when discussing asset inventory solutions.  I suspect that S= WID tags will eventually replace CPE names, but that will depend on market uptake and on how well we can deploy and use so-called “th= ird-party” SWID tags—non-authoritative tags created by entities= other than the software publisher/creator.  Adam is right that SWID t= agging is a relatively new concept.  There aren’t many vendors yet who have adopted tags, but there definitely are some, includin= g Symantec and most recently Microsoft.  SWIDs are today where CPE was= perhaps five years ago, in terms of adoption and coverage.  Give it t= ime.

 

SWID tags are full-fledged XML documents, = whereas CPE names are just identifying strings assigned by a third party (N= IST) to software products.  Embedded within the SWID tag document is a unique ID, which lacks the readability of a CPE name but cou= ld serve the same function as a CPE name.  SWID tags are associated wi= th individual product releases; CPE names can also be associated with indiv= idual products, but also have the capability to identify broader classes of a product.  You can create a CPE name = that generically refers to “all Windows 7 operating systems”, b= ut you can’t do that with a SWID tag.

 

The main issue with CPE is that it has a r= elatively unsustainable O&M profile.  Since software publishers ha= ven’t (and largely won’t) adopt CPE and build CPE names somehow= into their products (whatever that might mean; CPE thus far hasn’t addres= sed this issue), we need a central authority—NIST—to devote ong= oing resources to maintaining the CPE dictionary, with names arriving only = when submitted by a member of the “CPE community” in response to a naming need.  In contrast, software publishers who a= dopt SWID tagging create the tags at product release time, and the tag is i= ncluded in the installation package for the product.  When the product= is installed, the tag is placed on the endpoint.  When the product is uninstalled, the tag is removed.  With the additi= on of certification and digital signing of tags (not available in CPE), one= can have some guarantee that the tag has not been tampered with.  The= TagVault community is considering the addition of a “secure asset management” certification level, which woul= d require certified tags to include a “package footprint” eleme= nt documenting the individual files which comprise the tagged product. = ; These are features well beyond CPE.

 

There was a question about CPE’s abi= lity to represent product suites/groups.  You can create a CPE name fo= r “Microsoft Office 2010 Professional”, and you can create sepa= rate CPE names for all the products in that suite (Word, PowerPoint, etc.), but= CPE provides no way to represent the fact that by installing MS Office 201= 0 you also install all the individual products that are included.  SWI= D tags let you do that explicitly.

 

That’s all for now—I’ve = gone on long enough.  I’ll try to keep a closer eye on this thre= ad and do a better job of answering questions as they come up.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352 =

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Wednesday, September 26, 2012 9:23 AM
To: Jan-Oliver Wagner; sacm@ietf.org
Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon
Subject: [sacm] SWID and CPE: WAS - Re: SACM BoF Request<= /span>

 

= This seems like an important discussion.  Asset management is, arguabl= y, the most important foundational piece of an effective information security program, as our use case document [1] recognizes (asset managemen= t is the first recognized capability in support of Use Case 1).  Clear= ly, there are pros and cons to leveraging CPE and/or SWID, and after quickl= y reading through some of the information available at TagVault [2], it seems clear that SWIDs are roughly equivalen= t to CPE for operating systems and applications.

=  

= Before looking at the differences between CPE and SWID, it's probably a goo= d idea to understand exactly what we need from a software asset classification scheme not only within our use cases, but also from a= couple of control frameworks our use cases support (I prefer to look at th= e Critical Audit Guidelines (CAG) published by SANS and ISO 27002).

=  

= Both the CAG and 27002 make reference to managing assets, but only in terms= of keeping an inventory.  The CAG goes further by explicitly stating (in Critical Control 2) that we need to have an inventory of all a= uthorized and unauthorized software.  I don't believe either really me= ntions anything about corrective actions, except implicitly in sections rel= ated to incident response.  

=  

= So, we have a clear need to look at an instance of software, classify it, a= nd build or contribute to an identity profile for it for continued reference.  Can CPE handle this classification for for us?  Yes.=  Can SWID handle this classification for us?  It seems so.  = ;Note that we should not rely on either of these methods to identify softwa= re for targeted actions – that would be the domain of Asset Identification (we could use CPE or SWID to specify classes of targets for= actions).

=  

= Distribution and operational identification seems important to consider as = well.  CPEs aren't installed with the software and require some assessment action to derive.  SWIDs, on the other hand, appear t= o be distributed by the software publisher [3].  Moreover, SWIDs are c= ertified and signed by TagVault.  I'm unsure of the details about how = SWIDs become available on a given system (they still need to be actively collected from a target system at some point).

=  

= At this point, the difference between the two is really volume of available= "tags" (we can reasonably call a CPE name a "tag" in t= his context), and this is where I see the rubber meeting the road – when= an operational component is implicitly or explicitly required for a standa= rd to work as intended at scale.  

=  

= There seems to be very little information about SWID volumes available (at = least in the limited time I've had to search around), so it's difficult to judge how well they've penetrated the market.  The last = press release from TagVault is from 2010, which may suggest a dropping off = of the effort or a satisfaction that they've done enough.  Information= about CPE volume seems most readily available from NVD [5].

=  

= Can anyone on this list provide additional details about SWID?

=  

= I think it may be useful, from a  community perspective, to be able to= handle both software identification types, provided both are operationally feasible and foreseeably sustainable.  For example, the ai:softwar= e element defined by the Asset Identification draft [4] has an optional= CPE attribute that could just as easily be complemented by an optional SWI= D attribute.

=  

=  

= [2] http://www.tagvault.org<= /span>

=  

=  

=  

= On 9/26/12 3:28 AM, "Jan-Oliver Wagner" <Jan-Oliver.Wagner@greenbone.net> wrote= :

=  

= On Mittwoch, 26. September 2012, Baker, Jon wrote:

= I am a big fan of SWIDs and believe that we would really benefit from wides= pread SWID adoption. In my previous message, I was attempting to state that we need capabilities offer by both CPE and SWID. =

=  

= I am a big fan of CPE and believe it is fully compatible with Open Source r= eference

= implementation and widespread use/adoption in Open Source tools, especially= also

= in commercial environments.

=  

= Neglecting CPE in favour of SWID would IMHO be a drawback for widespread se= curity

= automation because, as to my understanding, SWID is not fully compatible wi= th the vendor-independent

= approaches. Convince me I am wrong and I'd be happy ;-)

=  

=  

= (Sorry for jumping in here, it was just something I am worried about since = some time already

= so I spontaneously reacted on the keywords :-)

=  

=  

= --

= Dr. Jan-Oliver Wagner |  ++49-541-335084-0  |&n= bsp; http://www.greenbone.net/

= Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCc= k, HR B 202460

= Gesch=E4ftsf=FChrer: Lukas Grunwald, Dr. Jan-Oliver Wagner

=  

=  

=  

=  

--_000_808A833A2D415D41996B1CF760901A0A1D87D704IMCMBX04MITREOR_-- From stevek@tagvault.org Mon Oct 1 21:02:12 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF2421F8ABA for ; Mon, 1 Oct 2012 21:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.111 X-Spam-Level: X-Spam-Status: No, score=0.111 tagged_above=-999 required=5 tests=[AWL=2.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkteSI5WbaqO for ; Mon, 1 Oct 2012 21:02:03 -0700 (PDT) Received: from tagvault.org (tagvault.org [70.32.84.97]) by ietfa.amsl.com (Postfix) with ESMTP id 53AAD21F8AB9 for ; Mon, 1 Oct 2012 21:02:02 -0700 (PDT) Received: (qmail 19772 invoked from network); 1 Oct 2012 20:58:51 -0700 Received: from 108-247-126-13.lightspeed.sntcca.sbcglobal.net (HELO stevekltp64) (108.247.126.13) by tagvault.org with (AES128-SHA encrypted) SMTP; 1 Oct 2012 20:58:50 -0700 From: "Steve Klos" To: References: <201209261228.36242.Jan-Oliver.Wagner@greenbone.net> <808A833A2D415D41996B1CF760901A0A1D87D704@IMCMBX04.MITRE.ORG> In-Reply-To: <808A833A2D415D41996B1CF760901A0A1D87D704@IMCMBX04.MITRE.ORG> Date: Mon, 1 Oct 2012 20:58:34 -0700 Organization: TagVault.org Message-ID: <007801cda052$32da1d50$988e57f0$@tagvault.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0079_01CDA017.86827140" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKZxrn1m88rrnIOt+tdMUSm3OrHnwGJ7BgfAg4SWteV8E75YA== Content-Language: en-us Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stevek@tagvault.org List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 04:02:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0079_01CDA017.86827140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, =20 A few notes now and I will follow-up at the IT SAC conference in = one-on-one sessions, during various BoF sessions and I=92m more than happy to = continue this discussion thread as we move forward. =20 Brant already provided many details and I=92ve seen a variety of = comments on this reflector covering various different topics on SWID tags. Let me summarize in bullet points: =20 1) SWID Tags provide authoritative identification information = provided by the software publisher (authoritative by nature due to the digital signatures applied by the publishers). 2) SWID Tags do not need to be =93registered=94 or =93certified=94 = to be useful, but doing so ensure that the data provided in the tag meets a well-known minimum data set and it also follows registered and = enumerated values to ensure normalization. 3) SWID tags can be created by third party organizations and will = vary in the =93trust=94 level based on the identification of the organization creating the SWID tag. SWID tags created by =93NIST=94, for example = would have a much higher degree of trust than tags created by =93Mom and Pop Shop = Inc.=94 Digital signatures (that include recognition by a CA) are used to = recognize the creator. 4) SWID tags provide support for suites/bundles and the various software relationships within those software groupings. =20 5) SWID tags also provide support for patches with the = identification of which software the patch is targeted at. 6) SWID tags support efforts to mitigate the software supply chain security risk by including (in the secure asset management level of certification), the footprint of each file on the installation media as = well as for each file that may be copied onto the device the software is = being installed on. These file level details utilize the SHA 2 (256) = algorithm and are also digitally signed with the publishers signature. 7) Through work with MITRE, NIST and others, the SWID standard has = been extended to support many of the fields necessary to map against the CPE = name structure =96 Brant and others have already referenced this work and the document behind it. Note that TagVault.org is heavily involved in the = ISO standards development efforts and these extensions are already targeted = to be incorporated back into an amendment to the 19770-2 standard. 8) To ensure we don=92t =93mix=94 standards =96 the effort for the = SWID tag standard is to ensure the fields are defined properly and that software publishers are required to include the data in these fields, however, = the CPE name is defined as a process to concatenate fields. This enables = NIST, IETF, or others to manage the CPE standard as required and for the = process used to create the CPE names to be used as an integration point between = the standards. 9) Due to the fact that there is a vast library of tools, = processes, etc invested in CPE names, my perspective on the integration is to keep = CPE essentially as is, add the integration with SWID tag names and to = utilize this information with the systems around it to normalize names and terms = for both systems. 10) SW Publishers are quickly coming to the realization that SWID tags lower their overall infrastructure costs due to many factors, they = provide the data their customers have been requesting for quite some time and = they provide the added value of ensuring that the customer is receiving only = what the publisher published, so they add a level of supply chain risk = management to the distribution process. Microsoft and Symantec have certainly recognized and embraced these benefits and are quickly working to = integrate certified SWID tags into their build environments to provide the highest value to their customers. =20 My presentation is on Wed afternoon from 4:30 to 5:30 and as many on = this distribution are aware =96 this is an area I=92m passionate about. Many = IT processes from compliance to security to logistics require authoritative identification of software. Anyone who=92s worked with tools in this = area knows that existing systems vary dramatically in their abilities and generally data sets between different tools cannot be easily reconciled against each other. The fact that SWID tags can provide solutions to = these areas, are being supported directly by publishers and can be integrated = into the SCAP infrastructure and can even provide a direct bridge between discovery data and CPE names, seem to make this technology an ideal fit = for this community. =20 Looking forward to seeing many of you on Wed! =20 Regards, =20 Steve Klos From: Cheikes, Brant A. [mailto:bcheikes@mitre.org]=20 Sent: Monday, October 01, 2012 7:40 AM To: Adam Montville; Jan-Oliver Wagner; sacm@ietf.org Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request =20 I=92m sorry I didn=92t join this thread sooner, but I=92ll try to catch = up. I=92ve been leading the CPE project at MITRE for the last three years, and for = the last year-plus have been working closely with Steve Klos, the Executive Director of TagVault.org, to assess similarities/differences between the = CPE and SWID tag standards, and to develop a roadmap that enables the two standards to interoperate in some fashion. Steve and I chaired a = session at the recent Developer Days workshop on the topic; see: http://cpe.mitre.org/news/index.html#jul272012b =20 CPE names and SWID tags are very different things, with overlapping and non-overlapping use cases, different value propositions to stakeholders, = and different procedures for creation and maintenance. The CPE v2.3 = standard is documented in a suite of NIST IRs, and the SWID tag standard is = documented in ISO/IEC 19770-2:2009. This is not the proper venue for tutorials on either CPE or SWID; I would encourage those who know CPE to learn more = about SWIDs using TagVault.org resources. Also note that Steve Klos will be speaking today at ITSAC. =20 In my view, both CPE and SWID need to be considered when discussing = asset inventory solutions. I suspect that SWID tags will eventually replace = CPE names, but that will depend on market uptake and on how well we can = deploy and use so-called =93third-party=94 SWID tags=97non-authoritative tags = created by entities other than the software publisher/creator. Adam is right that = SWID tagging is a relatively new concept. There aren=92t many vendors yet = who have adopted tags, but there definitely are some, including Symantec and most recently Microsoft. SWIDs are today where CPE was perhaps five years = ago, in terms of adoption and coverage. Give it time. =20 SWID tags are full-fledged XML documents, whereas CPE names are just identifying strings assigned by a third party (NIST) to software = products. Embedded within the SWID tag document is a unique ID, which lacks the readability of a CPE name but could serve the same function as a CPE = name. SWID tags are associated with individual product releases; CPE names can also be associated with individual products, but also have the = capability to identify broader classes of a product. You can create a CPE name that generically refers to =93all Windows 7 operating systems=94, but you = can=92t do that with a SWID tag. =20 The main issue with CPE is that it has a relatively unsustainable O&M profile. Since software publishers haven=92t (and largely won=92t) = adopt CPE and build CPE names somehow into their products (whatever that might = mean; CPE thus far hasn=92t addressed this issue), we need a central authority=97NIST=97to devote ongoing resources to maintaining the CPE dictionary, with names arriving only when submitted by a member of the = =93CPE community=94 in response to a naming need. In contrast, software = publishers who adopt SWID tagging create the tags at product release time, and the = tag is included in the installation package for the product. When the = product is installed, the tag is placed on the endpoint. When the product is uninstalled, the tag is removed. With the addition of certification and digital signing of tags (not available in CPE), one can have some = guarantee that the tag has not been tampered with. The TagVault community is considering the addition of a =93secure asset management=94 = certification level, which would require certified tags to include a =93package footprint=94 = element documenting the individual files which comprise the tagged product. = These are features well beyond CPE. =20 There was a question about CPE=92s ability to represent product = suites/groups. You can create a CPE name for =93Microsoft Office 2010 Professional=94, = and you can create separate CPE names for all the products in that suite (Word, PowerPoint, etc.), but CPE provides no way to represent the fact that by installing MS Office 2010 you also install all the individual products = that are included. SWID tags let you do that explicitly. =20 That=92s all for now=97I=92ve gone on long enough. I=92ll try to keep a = closer eye on this thread and do a better job of answering questions as they come = up. =20 Cheers, /Brant =20 Brant A. Cheikes The MITRE Corporation 202 Burlington Road, M/S K302 Bedford, MA 01730-1420 Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352=20 =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Adam Montville Sent: Wednesday, September 26, 2012 9:23 AM To: Jan-Oliver Wagner; sacm@ietf.org Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon Subject: [sacm] SWID and CPE: WAS - Re: SACM BoF Request =20 This seems like an important discussion. Asset management is, arguably, = the most important foundational piece of an effective information security program, as our use case document [1] recognizes (asset management is = the first recognized capability in support of Use Case 1). Clearly, there = are pros and cons to leveraging CPE and/or SWID, and after quickly reading through some of the information available at TagVault [2], it seems = clear that SWIDs are roughly equivalent to CPE for operating systems and applications. =20 Before looking at the differences between CPE and SWID, it's probably a = good idea to understand exactly what we need from a software asset = classification scheme not only within our use cases, but also from a couple of control frameworks our use cases support (I prefer to look at the Critical Audit Guidelines (CAG) published by SANS and ISO 27002). =20 Both the CAG and 27002 make reference to managing assets, but only in = terms of keeping an inventory. The CAG goes further by explicitly stating (in Critical Control 2) that we need to have an inventory of all authorized = and unauthorized software. I don't believe either really mentions anything about corrective actions, except implicitly in sections related to = incident response. =20 =20 So, we have a clear need to look at an instance of software, classify = it, and build or contribute to an identity profile for it for continued reference. Can CPE handle this classification for for us? Yes. Can = SWID handle this classification for us? It seems so. Note that we should = not rely on either of these methods to identify software for targeted = actions =96 that would be the domain of Asset Identification (we could use CPE or = SWID to specify classes of targets for actions). =20 Distribution and operational identification seems important to consider = as well. CPEs aren't installed with the software and require some = assessment action to derive. SWIDs, on the other hand, appear to be distributed by = the software publisher [3]. Moreover, SWIDs are certified and signed by TagVault. I'm unsure of the details about how SWIDs become available on = a given system (they still need to be actively collected from a target = system at some point). =20 At this point, the difference between the two is really volume of = available "tags" (we can reasonably call a CPE name a "tag" in this context), and = this is where I see the rubber meeting the road =96 when an operational = component is implicitly or explicitly required for a standard to work as intended = at scale. =20 =20 There seems to be very little information about SWID volumes available = (at least in the limited time I've had to search around), so it's difficult = to judge how well they've penetrated the market. The last press release = from TagVault is from 2010, which may suggest a dropping off of the effort or = a satisfaction that they've done enough. Information about CPE volume = seems most readily available from NVD [5]. =20 Can anyone on this list provide additional details about SWID? =20 I think it may be useful, from a community perspective, to be able to handle both software identification types, provided both are = operationally feasible and foreseeably sustainable. For example, the ai:software = element defined by the Asset Identification draft [4] has an optional CPE = attribute that could just as easily be complemented by an optional SWID attribute. =20 =20 [1] http://tools.ietf.org/html/waltermire-sacm-use-cases-02=20 [2] http://www.tagvault.org [3] http://www.tagvault.org/swid-tag-lifecycle [4] http://trac.tools.ietf.org/html/draft-montville-sacm-asset-identification= -00 [5] http://nvd.nist.gov/cpe.cfm =20 =20 =20 On 9/26/12 3:28 AM, "Jan-Oliver Wagner" = wrote: =20 On Mittwoch, 26. September 2012, Baker, Jon wrote: I am a big fan of SWIDs and believe that we would really benefit from widespread SWID adoption. In my previous message, I was attempting to = state that we need capabilities offer by both CPE and SWID.=20 =20 I am a big fan of CPE and believe it is fully compatible with Open = Source reference implementation and widespread use/adoption in Open Source tools, = especially also in commercial environments. =20 Neglecting CPE in favour of SWID would IMHO be a drawback for widespread security automation because, as to my understanding, SWID is not fully compatible with the vendor-independent approaches. Convince me I am wrong and I'd be happy ;-) =20 =20 (Sorry for jumping in here, it was just something I am worried about = since some time already so I spontaneously reacted on the keywords :-) =20 =20 --=20 Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG = Osnabr=FCck, HR B 202460 Gesch=E4ftsf=FChrer: Lukas Grunwald, Dr. Jan-Oliver Wagner =20 =20 =20 =20 ------=_NextPart_000_0079_01CDA017.86827140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Folks,

 

A few notes now and I will follow-up at the IT SAC conference in = one-on-one sessions, during various BoF sessions and I’m more than = happy to continue this discussion thread as we move = forward.

 

Brant already provided many details and I’ve seen a variety of = comments on this reflector covering various different topics on SWID = tags.=A0 Let me summarize in bullet points:

 

1)      = SWID Tags provide authoritative identification information provided = by the software publisher (authoritative by nature due to the digital = signatures applied by the publishers).

2)      = SWID Tags do not need to be “registered” or = “certified” to be useful, but doing so ensure that the data = provided in the tag meets a well-known minimum data set and it also = follows registered and enumerated values to ensure = normalization.

3)      = SWID tags can be created by third party organizations and will vary = in the “trust” level based on the identification of the = organization creating the SWID tag.=A0 SWID tags created by = “NIST”, for example would have a much higher degree of trust = than tags created by “Mom and Pop Shop Inc.”=A0 Digital = signatures (that include recognition by a CA) are used to recognize the = creator.

4)      = SWID tags provide support for suites/bundles and the various software = relationships within those software groupings.=A0 =

5)      = SWID tags also provide support for patches with the identification of = which software the patch is targeted at.

6)      = SWID tags support efforts to mitigate the software supply chain = security risk by including (in the secure asset management level of = certification), the footprint of each file on the installation media as = well as for each file that may be copied onto the device the software is = being installed on.=A0 These file level details utilize the SHA 2 (256) = algorithm and are also digitally signed with the publishers = signature.

7)      = Through work with MITRE, NIST and others, the SWID standard has been = extended to support many of the fields necessary to map against the CPE = name structure – Brant and others have already referenced this = work and the document behind it.=A0 Note that TagVault.org is heavily = involved in the ISO standards development efforts and these extensions = are already targeted to be incorporated back into an amendment to the = 19770-2 standard.

8)      = To ensure we don’t “mix” standards – the = effort for the SWID tag standard is to ensure the fields are defined = properly and that software publishers are required to include the data = in these fields, however, the CPE name is defined as a process to = concatenate fields.=A0 This enables NIST, IETF, or others to manage the = CPE standard as required and for the process used to create the CPE = names to be used as an integration point between the = standards.

9)      = Due to the fact that there is a vast library of tools, processes, etc = invested in CPE names, my perspective on the integration is to keep CPE = essentially as is, add the integration with SWID tag names and to = utilize this information with the systems around it to normalize names = and terms for both systems.

10)   SW Publishers are quickly coming to the realization that SWID tags = lower their overall infrastructure costs due to many factors, they = provide the data their customers have been requesting for quite some = time and they provide the added value of ensuring that the customer is = receiving only what the publisher published, so they add a level of = supply chain risk management to the distribution process.=A0 Microsoft = and Symantec have certainly recognized and embraced these benefits and = are quickly working to integrate certified SWID tags into their build = environments to provide the highest value to their = customers.

 

My presentation is on Wed afternoon from 4:30 to 5:30 and as many on = this distribution are aware – this is an area I’m passionate = about.=A0 Many IT processes from compliance to security to logistics = require authoritative identification of software.=A0 Anyone who’s = worked with tools in this area knows that existing systems vary = dramatically in their abilities and generally data sets between = different tools cannot be easily reconciled against each other.=A0 The = fact that SWID tags can provide solutions to these areas, are being = supported directly by publishers and can be integrated into the SCAP = infrastructure and can even provide a direct bridge between discovery = data and CPE names, seem to make this technology an ideal fit for this = community.

 

Looking forward to seeing many of you on Wed!

 

Regards,

 

Steve Klos

From:= = Cheikes, Brant A. [mailto:bcheikes@mitre.org]
Sent: Monday, = October 01, 2012 7:40 AM
To: Adam Montville; Jan-Oliver = Wagner; sacm@ietf.org
Cc: Moriarty, Kathleen; Waltermire, = David A.; Baker, Jon
Subject: Re: [sacm] SWID and CPE: WAS - = Re: SACM BoF Request

 

I’m = sorry I didn’t join this thread sooner, but I’ll try to = catch up.  I’ve been leading the CPE project at MITRE for the = last three years, and for the last year-plus have been working closely = with Steve Klos, the Executive Director of TagVault.org, to assess = similarities/differences between the CPE and SWID tag standards, and to = develop a roadmap that enables the two standards to interoperate in some = fashion.  Steve and I chaired a session at the recent Developer = Days workshop on the topic; see:

http://cpe.mitre= .org/news/index.html#jul272012b

 

CPE names and = SWID tags are very different things, with overlapping and = non-overlapping use cases, different value propositions to stakeholders, = and different procedures for creation and maintenance.  The CPE = v2.3 standard is documented in a suite of NIST IRs, and the SWID tag = standard is documented in ISO/IEC 19770-2:2009.  This is not the = proper venue for tutorials on either CPE or SWID; I would encourage = those who know CPE to learn more about SWIDs using TagVault.org = resources.  Also note that Steve Klos will be speaking today at = ITSAC.

 

In my view, = both CPE and SWID need to be considered when discussing asset inventory = solutions.  I suspect that SWID tags will eventually replace CPE = names, but that will depend on market uptake and on how well we can = deploy and use so-called “third-party” SWID = tags—non-authoritative tags created by entities other than the = software publisher/creator.  Adam is right that SWID tagging is a = relatively new concept.  There aren’t many vendors yet who = have adopted tags, but there definitely are some, including Symantec and = most recently Microsoft.  SWIDs are today where CPE was perhaps = five years ago, in terms of adoption and coverage.  Give it = time.

 

SWID tags are = full-fledged XML documents, whereas CPE names are just identifying = strings assigned by a third party (NIST) to software products.  = Embedded within the SWID tag document is a unique ID, which lacks the = readability of a CPE name but could serve the same function as a CPE = name.  SWID tags are associated with individual product releases; = CPE names can also be associated with individual products, but also have = the capability to identify broader classes of a product.  You can = create a CPE name that generically refers to “all Windows 7 = operating systems”, but you can’t do that with a SWID = tag.

 

The main = issue with CPE is that it has a relatively unsustainable O&M = profile.  Since software publishers haven’t (and largely = won’t) adopt CPE and build CPE names somehow into their products = (whatever that might mean; CPE thus far hasn’t addressed this = issue), we need a central authority—NIST—to devote ongoing = resources to maintaining the CPE dictionary, with names arriving only = when submitted by a member of the “CPE community” in = response to a naming need.  In contrast, software publishers who = adopt SWID tagging create the tags at product release time, and the tag = is included in the installation package for the product.  When the = product is installed, the tag is placed on the endpoint.  When the = product is uninstalled, the tag is removed.  With the addition of = certification and digital signing of tags (not available in CPE), one = can have some guarantee that the tag has not been tampered with.  = The TagVault community is considering the addition of a “secure = asset management” certification level, which would require = certified tags to include a “package footprint” element = documenting the individual files which comprise the tagged = product.  These are features well beyond = CPE.

 

There was a = question about CPE’s ability to represent product = suites/groups.  You can create a CPE name for “Microsoft = Office 2010 Professional”, and you can create separate CPE names = for all the products in that suite (Word, PowerPoint, etc.), but CPE = provides no way to represent the fact that by installing MS Office 2010 = you also install all the individual products that are included.  = SWID tags let you do that explicitly.

 

That’s = all for now—I’ve gone on long enough.  I’ll try = to keep a closer eye on this thread and do a better job of answering = questions as they come up.

 

Cheers,

/Brant

 

Brant A. = Cheikes
The MITRE Corporation
202 Burlington Road, M/S = K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; = Fax. 781-271-2352

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf Of Adam Montville
Sent: Wednesday, = September 26, 2012 9:23 AM
To: Jan-Oliver Wagner; sacm@ietf.org
Cc: Moriarty, = Kathleen; Waltermire, David A.; Baker, Jon
Subject: [sacm] = SWID and CPE: WAS - Re: SACM BoF = Request

 

This seems like an important discussion.  Asset management is, = arguably, the most important foundational piece of an effective = information security program, as our use case document [1] recognizes = (asset management is the first recognized capability in support of Use = Case 1).  Clearly, there are pros and cons to leveraging CPE and/or = SWID, and after quickly reading through some of the information = available at TagVault [2], it seems clear that SWIDs are roughly = equivalent to CPE for operating systems and = applications.

 

Before looking at the differences between CPE and SWID, it's probably a = good idea to understand exactly what we need from a software asset = classification scheme not only within our use cases, but also from a = couple of control frameworks our use cases support (I prefer to look at = the Critical Audit Guidelines (CAG) published by SANS and ISO = 27002).

 

Both the CAG and 27002 make reference to managing assets, but only in = terms of keeping an inventory.  The CAG goes further by explicitly = stating (in Critical Control 2) that we need to have an inventory of all = authorized and unauthorized software.  I don't believe either = really mentions anything about corrective actions, except implicitly in = sections related to incident response. =  

 

So, we have a clear need to look at an instance of software, classify = it, and build or contribute to an identity profile for it for continued = reference.  Can CPE handle this classification for for us? =  Yes.  Can SWID handle this classification for us?  It = seems so.  Note that we should not rely on either of these methods = to identify software for targeted actions – that would be the = domain of Asset Identification (we could use CPE or SWID to specify = classes of targets for actions).

 

Distribution and operational identification seems important to consider = as well.  CPEs aren't installed with the software and require some = assessment action to derive.  SWIDs, on the other hand, appear to = be distributed by the software publisher [3].  Moreover, SWIDs are = certified and signed by TagVault.  I'm unsure of the details about = how SWIDs become available on a given system (they still need to be = actively collected from a target system at some = point).

 

At this point, the difference between the two is really volume of = available "tags" (we can reasonably call a CPE name a = "tag" in this context), and this is where I see the rubber = meeting the road – when an operational component is implicitly or = explicitly required for a standard to work as intended at scale. =  

 

There seems to be very little information about SWID volumes available = (at least in the limited time I've had to search around), so it's = difficult to judge how well they've penetrated the market.  The = last press release from TagVault is from 2010, which may suggest a = dropping off of the effort or a satisfaction that they've done enough. =  Information about CPE volume seems most readily available from NVD = [5].

 

Can anyone on this list provide additional details about = SWID?

 

I think it may be useful, from a  community perspective, to be = able to handle both software identification types, provided both are = operationally feasible and foreseeably sustainable.  For example, = the ai:software element defined by the Asset Identification draft = [4] has an optional CPE attribute that could just as easily be = complemented by an optional SWID = attribute.

 

 

 

 

 

On 9/26/12 3:28 AM, "Jan-Oliver Wagner" <Jan-Oliver.Wagner@greenbo= ne.net> wrote:

 

On Mittwoch, 26. September 2012, Baker, Jon = wrote:

I am a big fan of SWIDs and believe that we would really benefit from = widespread SWID adoption. In my previous message, I was attempting to = state that we need capabilities offer by both CPE and SWID. =

 

I am a big fan of CPE and believe it is fully compatible with Open = Source reference

implementation and widespread use/adoption in Open Source tools, = especially also

in commercial environments.

 

Neglecting CPE in favour of SWID would IMHO be a drawback for = widespread security

automation because, as to my understanding, SWID is not fully = compatible with the = vendor-independent

approaches. Convince me I am wrong and I'd be happy = ;-)

 

 

(Sorry for jumping in here, it was just something I am worried about = since some time already

so I spontaneously reacted on the keywords = :-)

 

 

--

Dr. Jan-Oliver Wagner = |  ++49-541-335084-0  |  http://www.greenbone.net/

Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG = Osnabr=FCck, HR B 202460

Gesch=E4ftsf=FChrer: Lukas Grunwald, Dr. Jan-Oliver = Wagner

 

 

 

 

------=_NextPart_000_0079_01CDA017.86827140-- From jan-oliver.wagner@greenbone.net Mon Oct 1 23:53:41 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1278521F88FE for ; Mon, 1 Oct 2012 23:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ztl1GotliGux for ; Mon, 1 Oct 2012 23:53:40 -0700 (PDT) Received: from kolab.intevation.de (aktaia.intevation.org [212.95.126.10]) by ietfa.amsl.com (Postfix) with ESMTP id 10B4B21F88FC for ; Mon, 1 Oct 2012 23:53:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id BE72D94D9C1 for ; Tue, 2 Oct 2012 08:53:36 +0200 (CEST) X-Virus-Scanned: by amavisd-new at intevation.de Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 109EE94D9C3 for ; Tue, 2 Oct 2012 08:53:36 +0200 (CEST) Received: from euarne.hq.intevation.de (euarne.hq.intevation.de [192.168.11.56]) (Authenticated sender: jan-oliver.wagner@intevation.de) by kolab.intevation.de (Postfix) with ESMTPSA id 0296094D9C1 for ; Tue, 2 Oct 2012 08:53:36 +0200 (CEST) From: "Jan-Oliver Wagner" Organization: Greenbone Networks GmbH To: sacm@ietf.org Date: Tue, 2 Oct 2012 08:53:33 +0200 User-Agent: KMail/1.9.10 (enterprise35 20120810.d2e3d25) References: <201209261228.36242.Jan-Oliver.Wagner@greenbone.net> <808A833A2D415D41996B1CF760901A0A1D87D704@IMCMBX04.MITRE.ORG> <007801cda052$32da1d50$988e57f0$@tagvault.org> In-Reply-To: <007801cda052$32da1d50$988e57f0$@tagvault.org> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201210020853.35094.Jan-Oliver.Wagner@greenbone.net> Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 06:53:41 -0000 Hello, thanks to all for the comprehensive insights into SWID vs. CPE. However, I come back to my original concerns, cited below, which so far remained mostly unanswered. Most insights were about technical aspects. I still saw no argument why SWID is well compatible with Open Source community and vendor-independent approaches. CPE seems by far more competitive and compatible in this regard. At least I found no clarifying statements from SWID side. Maybe I did not manage to find it. At least such were not brought to attention in this thread. I am starting to have doubts about the non-technical genes of SWID to solve the challenge of helpful product enumeration for security automation. If we only target a part of the IT industry, there will always be a gap in security coverage. It has to be filled with another concept and automatically we end up with two of them. Which in turn will make IT security more expensive for customers. I'd really love to be prooven wrong with my pessimistic concerns! All the best Jan > On 9/26/12 3:28 AM, "Jan-Oliver Wagner" > I am a big fan of CPE and believe it is fully compatible with Open Source > reference >=20 > implementation and widespread use/adoption in Open Source tools, especial= ly > also >=20 > in commercial environments. >=20 > =A0 >=20 > Neglecting CPE in favour of SWID would IMHO be a drawback for widespread > security >=20 > automation because, as to my understanding, SWID is not fully compatible > with the vendor-independent >=20 > approaches. Convince me I am wrong and I'd be happy ;-) =2D-=20 Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG Osnabr=FCc= k, HR B 202460 Gesch=E4ftsf=FChrer: Lukas Grunwald, Dr. Jan-Oliver Wagner From turners@ieca.com Tue Oct 2 05:42:11 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7835521F889A for ; Tue, 2 Oct 2012 05:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.102 X-Spam-Level: X-Spam-Status: No, score=-102.102 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVulPKsqADo3 for ; Tue, 2 Oct 2012 05:42:10 -0700 (PDT) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.56.216.18]) by ietfa.amsl.com (Postfix) with ESMTP id C7BAD21F88DA for ; Tue, 2 Oct 2012 05:42:10 -0700 (PDT) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id 6F49034294DB6; Tue, 2 Oct 2012 07:42:11 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 64E0B34294D96 for ; Tue, 2 Oct 2012 07:42:11 -0500 (CDT) Received: from [108.18.174.220] (port=59036 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TJ1ne-0003Fq-4b for sacm@ietf.org; Tue, 02 Oct 2012 07:42:10 -0500 Message-ID: <506AE121.1070502@ieca.com> Date: Tue, 02 Oct 2012 08:42:09 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sacm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:59036 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 10 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [sacm] BOF process and some observations X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 12:42:11 -0000 I've gotten a lot of question about how the BOF process works. I'll try to give you my summary of what's going on and some observations. Much of this is summarized in: - s5 of https://www.ietf.org/tao.html. - https://datatracker.ietf.org/doc/rfc2418/ - https://datatracker.ietf.org/doc/rfc5434/ A BOF has been approved because I'm convinced, as the sponsoring Area Director (AD), that some of the questions in s1 of RFC 5434 have been answered. Particularly, there's a community interested (evident from sacm's ml) and that there's some part of the problem that could be done in the IETF. The mailing list has been around for about 2 years so, in my mind, it's time to see if sacm is ready for prime time (i.e., time to put up or shut up). In general, you get two shots at forming a WG. I'm counting this as BOF try 1. It'll be clear during the BOF whether it's going well or not. Trust me on this. And, just because a WG isn't formed doesn't mean the work won't get picked by/adopted by/directed to another WG. As far as the BOF goes, I think you should expect that most people that attend the BOF will have read the "charter" messages, the sacm-related drafts, and whatever presentations get posted to the meeting materials manager but that's about it. That is, I'd expect most people won't have read all the list's messages, won't have attended the side-meetings, and probably aren't on non-IETF sacm-related mailing lists. The set of slides that comprises the agenda need to lead everybody, including IAB and IESG members some number of which I expect to attend the BOF, towards being able to say yes to all 5 of the BOF questions. That is, the presenters need to define what sacm is, have some use cases, explain what's left to be done (i.e, how the existing work fits/doesn't fit), describe the proposed-WG's items, etc. And now for some concerns that I'd be remiss in not asking before the BOF: As noted in the TAO, most BOFs that fail to result in a WG fail predominantly because not enough people can agree on a focus for the work, which could also categorized as the problem not being understood. I have to admit that I'm concerned about sacm's scope. The sacm problem space is pretty wide and it's not clear that all of it ought to be done in the IETF. It's okay, but probably not necessary, to explain the entire sacm problem space, but it needs to be clear what's proposed for the IETF and what's not. It'll make it easier to answer the 1st and 3rd BOF questions. I'm also concerned that there's already a fairly substantial amount of already published work in this space. How do they all relate, which parts are required for sacm, which parts are optional for sacm, and which parts are missing for sacm? What (if any) change control issues arise if we adopt/refer to non-IETF specifications? I say this knowing there are, but there'd better be non-USG use cases. It'd be good to hear from those that would use sacm to say yep we're looking for that. Another thing I've been wondering is whether sacm targets, which can be just about any IP-based box, OS, application running on the box/OS (right?), are ready to adopt yet another interface. Are the router, firewall, OS, and phone folks on board? I'd rather not build something hoping that they will come, if you know what I mean. What can/can't be done with existing protocols/models/languages developed in the IETF? Having multiple ways to manage/monitor/collect something is non-ideal so I'm dying to know why for example netconf can't be used or can't be extended and then used. spt From michael.hammer@yaanatech.com Tue Oct 2 06:26:09 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1892C21F8652 for ; Tue, 2 Oct 2012 06:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LIOp5Qy+I2u for ; Tue, 2 Oct 2012 06:25:53 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id B7CE321F865D for ; Tue, 2 Oct 2012 06:25:53 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 2 Oct 2012 06:25:53 -0700 From: Michael Hammer To: "'stevek@tagvault.org'" , "'sacm@ietf.org'" Thread-Topic: [sacm] SWID and CPE: WAS - Re: SACM BoF Request Thread-Index: AQHNm+oe1WnjMbHho06nDjZbZgzxdZelAugAgADe/wCAACe4UA== Date: Tue, 2 Oct 2012 13:25:52 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB32389D452@ex2k10mb2.corp.yaanatech.com> References: <201209261228.36242.Jan-Oliver.Wagner@greenbone.net> <808A833A2D415D41996B1CF760901A0A1D87D704@IMCMBX04.MITRE.ORG> <007801cda052$32da1d50$988e57f0$@tagvault.org> In-Reply-To: <007801cda052$32da1d50$988e57f0$@tagvault.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.2] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002C_01CDA07F.E9E32280" MIME-Version: 1.0 Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 13:26:09 -0000 ------=_NextPart_000_002C_01CDA07F.E9E32280 Content-Type: multipart/alternative; boundary="----=_NextPart_001_002D_01CDA07F.E9E32280" ------=_NextPart_001_002D_01CDA07F.E9E32280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Steve, =20 For #3, I would hope that trust is based on more than being well-known. After all, we have known some well-known government agencies that have failed miserably at security from time to time. Same thing with some = rather large, well-known companies. Mom and Pop might actually be much better = at doing it right because their very existence depends on it. =20 Better to define trust as something you gain by following well-proven methodologies that are traceable and testable. =20 Mike =20 =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Steve Klos Sent: Monday, October 01, 2012 11:59 PM To: sacm@ietf.org Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request =20 Folks, =20 A few notes now and I will follow-up at the IT SAC conference in = one-on-one sessions, during various BoF sessions and I=92m more than happy to = continue this discussion thread as we move forward. =20 Brant already provided many details and I=92ve seen a variety of = comments on this reflector covering various different topics on SWID tags. Let me summarize in bullet points: =20 1) SWID Tags provide authoritative identification information = provided by the software publisher (authoritative by nature due to the digital signatures applied by the publishers). 2) SWID Tags do not need to be =93registered=94 or =93certified=94 = to be useful, but doing so ensure that the data provided in the tag meets a well-known minimum data set and it also follows registered and = enumerated values to ensure normalization. 3) SWID tags can be created by third party organizations and will = vary in the =93trust=94 level based on the identification of the organization creating the SWID tag. SWID tags created by =93NIST=94, for example = would have a much higher degree of trust than tags created by =93Mom and Pop Shop = Inc.=94 Digital signatures (that include recognition by a CA) are used to = recognize the creator. 4) SWID tags provide support for suites/bundles and the various software relationships within those software groupings. =20 5) SWID tags also provide support for patches with the = identification of which software the patch is targeted at. 6) SWID tags support efforts to mitigate the software supply chain security risk by including (in the secure asset management level of certification), the footprint of each file on the installation media as = well as for each file that may be copied onto the device the software is = being installed on. These file level details utilize the SHA 2 (256) = algorithm and are also digitally signed with the publishers signature. 7) Through work with MITRE, NIST and others, the SWID standard has = been extended to support many of the fields necessary to map against the CPE = name structure =96 Brant and others have already referenced this work and the document behind it. Note that TagVault.org is heavily involved in the = ISO standards development efforts and these extensions are already targeted = to be incorporated back into an amendment to the 19770-2 standard. 8) To ensure we don=92t =93mix=94 standards =96 the effort for the = SWID tag standard is to ensure the fields are defined properly and that software publishers are required to include the data in these fields, however, = the CPE name is defined as a process to concatenate fields. This enables = NIST, IETF, or others to manage the CPE standard as required and for the = process used to create the CPE names to be used as an integration point between = the standards. 9) Due to the fact that there is a vast library of tools, = processes, etc invested in CPE names, my perspective on the integration is to keep = CPE essentially as is, add the integration with SWID tag names and to = utilize this information with the systems around it to normalize names and terms = for both systems. 10) SW Publishers are quickly coming to the realization that SWID tags lower their overall infrastructure costs due to many factors, they = provide the data their customers have been requesting for quite some time and = they provide the added value of ensuring that the customer is receiving only = what the publisher published, so they add a level of supply chain risk = management to the distribution process. Microsoft and Symantec have certainly recognized and embraced these benefits and are quickly working to = integrate certified SWID tags into their build environments to provide the highest value to their customers. =20 My presentation is on Wed afternoon from 4:30 to 5:30 and as many on = this distribution are aware =96 this is an area I=92m passionate about. Many = IT processes from compliance to security to logistics require authoritative identification of software. Anyone who=92s worked with tools in this = area knows that existing systems vary dramatically in their abilities and generally data sets between different tools cannot be easily reconciled against each other. The fact that SWID tags can provide solutions to = these areas, are being supported directly by publishers and can be integrated = into the SCAP infrastructure and can even provide a direct bridge between discovery data and CPE names, seem to make this technology an ideal fit = for this community. =20 Looking forward to seeing many of you on Wed! =20 Regards, =20 Steve Klos From: Cheikes, Brant A. [mailto:bcheikes@mitre.org]=20 Sent: Monday, October 01, 2012 7:40 AM To: Adam Montville; Jan-Oliver Wagner; sacm@ietf.org Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request =20 I=92m sorry I didn=92t join this thread sooner, but I=92ll try to catch = up. I=92ve been leading the CPE project at MITRE for the last three years, and for = the last year-plus have been working closely with Steve Klos, the Executive Director of TagVault.org, to assess similarities/differences between the = CPE and SWID tag standards, and to develop a roadmap that enables the two standards to interoperate in some fashion. Steve and I chaired a = session at the recent Developer Days workshop on the topic; see: http://cpe.mitre.org/news/index.html#jul272012b =20 CPE names and SWID tags are very different things, with overlapping and non-overlapping use cases, different value propositions to stakeholders, = and different procedures for creation and maintenance. The CPE v2.3 = standard is documented in a suite of NIST IRs, and the SWID tag standard is = documented in ISO/IEC 19770-2:2009. This is not the proper venue for tutorials on either CPE or SWID; I would encourage those who know CPE to learn more = about SWIDs using TagVault.org resources. Also note that Steve Klos will be speaking today at ITSAC. =20 In my view, both CPE and SWID need to be considered when discussing = asset inventory solutions. I suspect that SWID tags will eventually replace = CPE names, but that will depend on market uptake and on how well we can = deploy and use so-called =93third-party=94 SWID tags=97non-authoritative tags = created by entities other than the software publisher/creator. Adam is right that = SWID tagging is a relatively new concept. There aren=92t many vendors yet = who have adopted tags, but there definitely are some, including Symantec and most recently Microsoft. SWIDs are today where CPE was perhaps five years = ago, in terms of adoption and coverage. Give it time. =20 SWID tags are full-fledged XML documents, whereas CPE names are just identifying strings assigned by a third party (NIST) to software = products. Embedded within the SWID tag document is a unique ID, which lacks the readability of a CPE name but could serve the same function as a CPE = name. SWID tags are associated with individual product releases; CPE names can also be associated with individual products, but also have the = capability to identify broader classes of a product. You can create a CPE name that generically refers to =93all Windows 7 operating systems=94, but you = can=92t do that with a SWID tag. =20 The main issue with CPE is that it has a relatively unsustainable O&M profile. Since software publishers haven=92t (and largely won=92t) = adopt CPE and build CPE names somehow into their products (whatever that might = mean; CPE thus far hasn=92t addressed this issue), we need a central authority=97NIST=97to devote ongoing resources to maintaining the CPE dictionary, with names arriving only when submitted by a member of the = =93CPE community=94 in response to a naming need. In contrast, software = publishers who adopt SWID tagging create the tags at product release time, and the = tag is included in the installation package for the product. When the = product is installed, the tag is placed on the endpoint. When the product is uninstalled, the tag is removed. With the addition of certification and digital signing of tags (not available in CPE), one can have some = guarantee that the tag has not been tampered with. The TagVault community is considering the addition of a =93secure asset management=94 = certification level, which would require certified tags to include a =93package footprint=94 = element documenting the individual files which comprise the tagged product. = These are features well beyond CPE. =20 There was a question about CPE=92s ability to represent product = suites/groups. You can create a CPE name for =93Microsoft Office 2010 Professional=94, = and you can create separate CPE names for all the products in that suite (Word, PowerPoint, etc.), but CPE provides no way to represent the fact that by installing MS Office 2010 you also install all the individual products = that are included. SWID tags let you do that explicitly. =20 That=92s all for now=97I=92ve gone on long enough. I=92ll try to keep a = closer eye on this thread and do a better job of answering questions as they come = up. =20 Cheers, /Brant =20 Brant A. Cheikes The MITRE Corporation 202 Burlington Road, M/S K302 Bedford, MA 01730-1420 Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352=20 =20 From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Adam Montville Sent: Wednesday, September 26, 2012 9:23 AM To: Jan-Oliver Wagner; sacm@ietf.org Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon Subject: [sacm] SWID and CPE: WAS - Re: SACM BoF Request =20 This seems like an important discussion. Asset management is, arguably, = the most important foundational piece of an effective information security program, as our use case document [1] recognizes (asset management is = the first recognized capability in support of Use Case 1). Clearly, there = are pros and cons to leveraging CPE and/or SWID, and after quickly reading through some of the information available at TagVault [2], it seems = clear that SWIDs are roughly equivalent to CPE for operating systems and applications. =20 Before looking at the differences between CPE and SWID, it's probably a = good idea to understand exactly what we need from a software asset = classification scheme not only within our use cases, but also from a couple of control frameworks our use cases support (I prefer to look at the Critical Audit Guidelines (CAG) published by SANS and ISO 27002). =20 Both the CAG and 27002 make reference to managing assets, but only in = terms of keeping an inventory. The CAG goes further by explicitly stating (in Critical Control 2) that we need to have an inventory of all authorized = and unauthorized software. I don't believe either really mentions anything about corrective actions, except implicitly in sections related to = incident response. =20 =20 So, we have a clear need to look at an instance of software, classify = it, and build or contribute to an identity profile for it for continued reference. Can CPE handle this classification for for us? Yes. Can = SWID handle this classification for us? It seems so. Note that we should = not rely on either of these methods to identify software for targeted = actions =96 that would be the domain of Asset Identification (we could use CPE or = SWID to specify classes of targets for actions). =20 Distribution and operational identification seems important to consider = as well. CPEs aren't installed with the software and require some = assessment action to derive. SWIDs, on the other hand, appear to be distributed by = the software publisher [3]. Moreover, SWIDs are certified and signed by TagVault. I'm unsure of the details about how SWIDs become available on = a given system (they still need to be actively collected from a target = system at some point). =20 At this point, the difference between the two is really volume of = available "tags" (we can reasonably call a CPE name a "tag" in this context), and = this is where I see the rubber meeting the road =96 when an operational = component is implicitly or explicitly required for a standard to work as intended = at scale. =20 =20 There seems to be very little information about SWID volumes available = (at least in the limited time I've had to search around), so it's difficult = to judge how well they've penetrated the market. The last press release = from TagVault is from 2010, which may suggest a dropping off of the effort or = a satisfaction that they've done enough. Information about CPE volume = seems most readily available from NVD [5]. =20 Can anyone on this list provide additional details about SWID? =20 I think it may be useful, from a community perspective, to be able to handle both software identification types, provided both are = operationally feasible and foreseeably sustainable. For example, the ai:software = element defined by the Asset Identification draft [4] has an optional CPE = attribute that could just as easily be complemented by an optional SWID attribute. =20 =20 [1] http://tools.ietf.org/html/waltermire-sacm-use-cases-02=20 [2] http://www.tagvault.org [3] http://www.tagvault.org/swid-tag-lifecycle [4] http://trac.tools.ietf.org/html/draft-montville-sacm-asset-identification= -00 [5] http://nvd.nist.gov/cpe.cfm =20 =20 =20 On 9/26/12 3:28 AM, "Jan-Oliver Wagner" = wrote: =20 On Mittwoch, 26. September 2012, Baker, Jon wrote: I am a big fan of SWIDs and believe that we would really benefit from widespread SWID adoption. In my previous message, I was attempting to = state that we need capabilities offer by both CPE and SWID.=20 =20 I am a big fan of CPE and believe it is fully compatible with Open = Source reference implementation and widespread use/adoption in Open Source tools, = especially also in commercial environments. =20 Neglecting CPE in favour of SWID would IMHO be a drawback for widespread security automation because, as to my understanding, SWID is not fully compatible with the vendor-independent approaches. Convince me I am wrong and I'd be happy ;-) =20 =20 (Sorry for jumping in here, it was just something I am worried about = since some time already so I spontaneously reacted on the keywords :-) =20 =20 --=20 Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG = Osnabr=FCck, HR B 202460 Gesch=E4ftsf=FChrer: Lukas Grunwald, Dr. Jan-Oliver Wagner =20 =20 =20 =20 ------=_NextPart_001_002D_01CDA07F.E9E32280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Steve,

 

For #3, I would hope that trust is based on more than being = well-known.=A0 After all, we have known some well-known government = agencies that have failed miserably at security from time to time.=A0 = Same thing with some rather large, well-known companies.=A0 Mom and Pop = might actually be much better at doing it right because their very = existence depends on it.

 

Better to define trust as something you gain by following well-proven = methodologies that are traceable and testable.

 

Mike

 

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of = Steve Klos
Sent: Monday, October 01, 2012 11:59 = PM
To: sacm@ietf.org
Subject: Re: [sacm] SWID and = CPE: WAS - Re: SACM BoF Request

 

Folks,

 

A few notes now and I will follow-up at the IT SAC conference in = one-on-one sessions, during various BoF sessions and I’m more than = happy to continue this discussion thread as we move = forward.

 

Brant already provided many details and I’ve seen a variety of = comments on this reflector covering various different topics on SWID = tags.  Let me summarize in bullet points:

 

1)      = SWID Tags provide authoritative identification information provided = by the software publisher (authoritative by nature due to the digital = signatures applied by the publishers).

2)      = SWID Tags do not need to be “registered” or = “certified” to be useful, but doing so ensure that the data = provided in the tag meets a well-known minimum data set and it also = follows registered and enumerated values to ensure = normalization.

3)      = SWID tags can be created by third party organizations and will vary = in the “trust” level based on the identification of the = organization creating the SWID tag.  SWID tags created by = “NIST”, for example would have a much higher degree of trust = than tags created by “Mom and Pop Shop Inc.”  Digital = signatures (that include recognition by a CA) are used to recognize the = creator.

4)      = SWID tags provide support for suites/bundles and the various software = relationships within those software groupings.  =

5)      = SWID tags also provide support for patches with the identification of = which software the patch is targeted at.

6)      = SWID tags support efforts to mitigate the software supply chain = security risk by including (in the secure asset management level of = certification), the footprint of each file on the installation media as = well as for each file that may be copied onto the device the software is = being installed on.  These file level details utilize the SHA 2 = (256) algorithm and are also digitally signed with the publishers = signature.

7)      = Through work with MITRE, NIST and others, the SWID standard has been = extended to support many of the fields necessary to map against the CPE = name structure – Brant and others have already referenced this = work and the document behind it.  Note that TagVault.org is heavily = involved in the ISO standards development efforts and these extensions = are already targeted to be incorporated back into an amendment to the = 19770-2 standard.

8)      = To ensure we don’t “mix” standards – the = effort for the SWID tag standard is to ensure the fields are defined = properly and that software publishers are required to include the data = in these fields, however, the CPE name is defined as a process to = concatenate fields.  This enables NIST, IETF, or others to manage = the CPE standard as required and for the process used to create the CPE = names to be used as an integration point between the = standards.

9)      = Due to the fact that there is a vast library of tools, processes, etc = invested in CPE names, my perspective on the integration is to keep CPE = essentially as is, add the integration with SWID tag names and to = utilize this information with the systems around it to normalize names = and terms for both systems.

10)   SW Publishers are quickly coming to the realization that SWID tags = lower their overall infrastructure costs due to many factors, they = provide the data their customers have been requesting for quite some = time and they provide the added value of ensuring that the customer is = receiving only what the publisher published, so they add a level of = supply chain risk management to the distribution process.  = Microsoft and Symantec have certainly recognized and embraced these = benefits and are quickly working to integrate certified SWID tags into = their build environments to provide the highest value to their = customers.

 

My presentation is on Wed afternoon from 4:30 to 5:30 and as many on = this distribution are aware – this is an area I’m passionate = about.  Many IT processes from compliance to security to logistics = require authoritative identification of software.  Anyone = who’s worked with tools in this area knows that existing systems = vary dramatically in their abilities and generally data sets between = different tools cannot be easily reconciled against each other.  = The fact that SWID tags can provide solutions to these areas, are being = supported directly by publishers and can be integrated into the SCAP = infrastructure and can even provide a direct bridge between discovery = data and CPE names, seem to make this technology an ideal fit for this = community.

 

Looking forward to seeing many of you on Wed!

 

Regards,

 

Steve Klos

From:= = Cheikes, Brant A. [mailto:bcheikes@mitre.org]
Sent: Monday, October 01, 2012 7:40 AM
To: Adam = Montville; Jan-Oliver Wagner; sacm@ietf.org
Cc: Moriarty, = Kathleen; Waltermire, David A.; Baker, Jon
Subject: Re: [sacm] = SWID and CPE: WAS - Re: SACM BoF = Request

 

I’m = sorry I didn’t join this thread sooner, but I’ll try to = catch up.  I’ve been leading the CPE project at MITRE for the = last three years, and for the last year-plus have been working closely = with Steve Klos, the Executive Director of TagVault.org, to assess = similarities/differences between the CPE and SWID tag standards, and to = develop a roadmap that enables the two standards to interoperate in some = fashion.  Steve and I chaired a session at the recent Developer = Days workshop on the topic; see:

http://cpe.mitre= .org/news/index.html#jul272012b

 

CPE names and = SWID tags are very different things, with overlapping and = non-overlapping use cases, different value propositions to stakeholders, = and different procedures for creation and maintenance.  The CPE = v2.3 standard is documented in a suite of NIST IRs, and the SWID tag = standard is documented in ISO/IEC 19770-2:2009.  This is not the = proper venue for tutorials on either CPE or SWID; I would encourage = those who know CPE to learn more about SWIDs using TagVault.org = resources.  Also note that Steve Klos will be speaking today at = ITSAC.

 

In my view, = both CPE and SWID need to be considered when discussing asset inventory = solutions.  I suspect that SWID tags will eventually replace CPE = names, but that will depend on market uptake and on how well we can = deploy and use so-called “third-party” SWID = tags—non-authoritative tags created by entities other than the = software publisher/creator.  Adam is right that SWID tagging is a = relatively new concept.  There aren’t many vendors yet who = have adopted tags, but there definitely are some, including Symantec and = most recently Microsoft.  SWIDs are today where CPE was perhaps = five years ago, in terms of adoption and coverage.  Give it = time.

 

SWID tags are = full-fledged XML documents, whereas CPE names are just identifying = strings assigned by a third party (NIST) to software products.  = Embedded within the SWID tag document is a unique ID, which lacks the = readability of a CPE name but could serve the same function as a CPE = name.  SWID tags are associated with individual product releases; = CPE names can also be associated with individual products, but also have = the capability to identify broader classes of a product.  You can = create a CPE name that generically refers to “all Windows 7 = operating systems”, but you can’t do that with a SWID = tag.

 

The main = issue with CPE is that it has a relatively unsustainable O&M = profile.  Since software publishers haven’t (and largely = won’t) adopt CPE and build CPE names somehow into their products = (whatever that might mean; CPE thus far hasn’t addressed this = issue), we need a central authority—NIST—to devote ongoing = resources to maintaining the CPE dictionary, with names arriving only = when submitted by a member of the “CPE community” in = response to a naming need.  In contrast, software publishers who = adopt SWID tagging create the tags at product release time, and the tag = is included in the installation package for the product.  When the = product is installed, the tag is placed on the endpoint.  When the = product is uninstalled, the tag is removed.  With the addition of = certification and digital signing of tags (not available in CPE), one = can have some guarantee that the tag has not been tampered with.  = The TagVault community is considering the addition of a “secure = asset management” certification level, which would require = certified tags to include a “package footprint” element = documenting the individual files which comprise the tagged = product.  These are features well beyond = CPE.

 

There was a = question about CPE’s ability to represent product = suites/groups.  You can create a CPE name for “Microsoft = Office 2010 Professional”, and you can create separate CPE names = for all the products in that suite (Word, PowerPoint, etc.), but CPE = provides no way to represent the fact that by installing MS Office 2010 = you also install all the individual products that are included.  = SWID tags let you do that explicitly.

 

That’s = all for now—I’ve gone on long enough.  I’ll try = to keep a closer eye on this thread and do a better job of answering = questions as they come up.

 

Cheers,

/Brant

 

Brant A. = Cheikes
The MITRE Corporation
202 Burlington Road, M/S = K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; = Fax. 781-271-2352

 

From:= = sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.= org] On Behalf Of Adam Montville
Sent: Wednesday, = September 26, 2012 9:23 AM
To: Jan-Oliver Wagner; sacm@ietf.org
Cc: Moriarty, = Kathleen; Waltermire, David A.; Baker, Jon
Subject: [sacm] = SWID and CPE: WAS - Re: SACM BoF = Request

 

This seems like an important discussion.  Asset management is, = arguably, the most important foundational piece of an effective = information security program, as our use case document [1] recognizes = (asset management is the first recognized capability in support of Use = Case 1).  Clearly, there are pros and cons to leveraging CPE and/or = SWID, and after quickly reading through some of the information = available at TagVault [2], it seems clear that SWIDs are roughly = equivalent to CPE for operating systems and = applications.

 

Before looking at the differences between CPE and SWID, it's probably a = good idea to understand exactly what we need from a software asset = classification scheme not only within our use cases, but also from a = couple of control frameworks our use cases support (I prefer to look at = the Critical Audit Guidelines (CAG) published by SANS and ISO = 27002).

 

Both the CAG and 27002 make reference to managing assets, but only in = terms of keeping an inventory.  The CAG goes further by explicitly = stating (in Critical Control 2) that we need to have an inventory of all = authorized and unauthorized software.  I don't believe either = really mentions anything about corrective actions, except implicitly in = sections related to incident response. =  

 

So, we have a clear need to look at an instance of software, classify = it, and build or contribute to an identity profile for it for continued = reference.  Can CPE handle this classification for for us? =  Yes.  Can SWID handle this classification for us?  It = seems so.  Note that we should not rely on either of these methods = to identify software for targeted actions – that would be the = domain of Asset Identification (we could use CPE or SWID to specify = classes of targets for actions).

 

Distribution and operational identification seems important to consider = as well.  CPEs aren't installed with the software and require some = assessment action to derive.  SWIDs, on the other hand, appear to = be distributed by the software publisher [3].  Moreover, SWIDs are = certified and signed by TagVault.  I'm unsure of the details about = how SWIDs become available on a given system (they still need to be = actively collected from a target system at some = point).

 

At this point, the difference between the two is really volume of = available "tags" (we can reasonably call a CPE name a = "tag" in this context), and this is where I see the rubber = meeting the road – when an operational component is implicitly or = explicitly required for a standard to work as intended at scale. =  

 

There seems to be very little information about SWID volumes available = (at least in the limited time I've had to search around), so it's = difficult to judge how well they've penetrated the market.  The = last press release from TagVault is from 2010, which may suggest a = dropping off of the effort or a satisfaction that they've done enough. =  Information about CPE volume seems most readily available from NVD = [5].

 

Can anyone on this list provide additional details about = SWID?

 

I think it may be useful, from a  community perspective, to be = able to handle both software identification types, provided both are = operationally feasible and foreseeably sustainable.  For example, = the ai:software element defined by the Asset Identification draft = [4] has an optional CPE attribute that could just as easily be = complemented by an optional SWID = attribute.

 

 

 

 

 

On 9/26/12 3:28 AM, "Jan-Oliver Wagner" <Jan-Oliver.Wagner@greenbo= ne.net> wrote:

 

On Mittwoch, 26. September 2012, Baker, Jon = wrote:

I am a big fan of SWIDs and believe that we would really benefit from = widespread SWID adoption. In my previous message, I was attempting to = state that we need capabilities offer by both CPE and SWID. =

 

I am a big fan of CPE and believe it is fully compatible with Open = Source reference

implementation and widespread use/adoption in Open Source tools, = especially also

in commercial environments.

 

Neglecting CPE in favour of SWID would IMHO be a drawback for = widespread security

automation because, as to my understanding, SWID is not fully = compatible with the = vendor-independent

approaches. Convince me I am wrong and I'd be happy = ;-)

 

 

(Sorry for jumping in here, it was just something I am worried about = since some time already

so I spontaneously reacted on the keywords = :-)

 

 

--

Dr. Jan-Oliver Wagner = |  ++49-541-335084-0  |  http://www.greenbone.net/

Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabr=FCck | AG = Osnabr=FCck, HR B 202460

Gesch=E4ftsf=FChrer: Lukas Grunwald, Dr. Jan-Oliver = Wagner

 

 

 

 

------=_NextPart_001_002D_01CDA07F.E9E32280-- ------=_NextPart_000_002C_01CDA07F.E9E32280 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAw MjEzMjU1MFowIwYJKoZIhvcNAQkEMRYEFLmHJ5WzYzvqAo6Mqtv/eoJFOznJMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGApdceoJv707OHxlV67hc9gP1lzUFmr9Faci8H3106mcx3 wv7MDQFRtKWw1gU32WoIg9HYlpSROmGZKHf/ji8l568dHhzFA8mSwV6jvnCVfmO1rrd6kV7e3o5b usfQ+vqCBuldyyQ0lmlXgdKALoLAxJXVf8tsalEI++E1oD7S+GAAAAAAAAA= ------=_NextPart_000_002C_01CDA07F.E9E32280-- From michael.hammer@yaanatech.com Tue Oct 2 06:29:25 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0AD21F8645 for ; Tue, 2 Oct 2012 06:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnWEGRnY74ck for ; Tue, 2 Oct 2012 06:29:24 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id DC8F221F8643 for ; Tue, 2 Oct 2012 06:29:24 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 2 Oct 2012 06:29:25 -0700 From: Michael Hammer To: "'turners@ieca.com'" , "'sacm@ietf.org'" Thread-Topic: [sacm] BOF process and some observations Thread-Index: AQHNoJtp5A2+sFEOV0amDwczXyqlJJemAb+Q Date: Tue, 2 Oct 2012 13:29:24 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB32389D863@ex2k10mb2.corp.yaanatech.com> References: <506AE121.1070502@ieca.com> In-Reply-To: <506AE121.1070502@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.2] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0033_01CDA080.68DACC00" MIME-Version: 1.0 Subject: Re: [sacm] BOF process and some observations X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 13:29:25 -0000 ------=_NextPart_000_0033_01CDA080.68DACC00 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To help gain focus, folks should understand that the IETF defines success as completion of the WG, not a life-long old boys club. It is not a one-shot deal. You can create a series of WGs to tackle subsequent elements of work over time. Mike -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Sean Turner Sent: Tuesday, October 02, 2012 8:42 AM To: sacm@ietf.org Subject: [sacm] BOF process and some observations I've gotten a lot of question about how the BOF process works. I'll try to give you my summary of what's going on and some observations. Much of this is summarized in: - s5 of https://www.ietf.org/tao.html. - https://datatracker.ietf.org/doc/rfc2418/ - https://datatracker.ietf.org/doc/rfc5434/ A BOF has been approved because I'm convinced, as the sponsoring Area Director (AD), that some of the questions in s1 of RFC 5434 have been answered. Particularly, there's a community interested (evident from sacm's ml) and that there's some part of the problem that could be done in the IETF. The mailing list has been around for about 2 years so, in my mind, it's time to see if sacm is ready for prime time (i.e., time to put up or shut up). In general, you get two shots at forming a WG. I'm counting this as BOF try 1. It'll be clear during the BOF whether it's going well or not. Trust me on this. And, just because a WG isn't formed doesn't mean the work won't get picked by/adopted by/directed to another WG. As far as the BOF goes, I think you should expect that most people that attend the BOF will have read the "charter" messages, the sacm-related drafts, and whatever presentations get posted to the meeting materials manager but that's about it. That is, I'd expect most people won't have read all the list's messages, won't have attended the side-meetings, and probably aren't on non-IETF sacm-related mailing lists. The set of slides that comprises the agenda need to lead everybody, including IAB and IESG members some number of which I expect to attend the BOF, towards being able to say yes to all 5 of the BOF questions. That is, the presenters need to define what sacm is, have some use cases, explain what's left to be done (i.e, how the existing work fits/doesn't fit), describe the proposed-WG's items, etc. And now for some concerns that I'd be remiss in not asking before the BOF: As noted in the TAO, most BOFs that fail to result in a WG fail predominantly because not enough people can agree on a focus for the work, which could also categorized as the problem not being understood. I have to admit that I'm concerned about sacm's scope. The sacm problem space is pretty wide and it's not clear that all of it ought to be done in the IETF. It's okay, but probably not necessary, to explain the entire sacm problem space, but it needs to be clear what's proposed for the IETF and what's not. It'll make it easier to answer the 1st and 3rd BOF questions. I'm also concerned that there's already a fairly substantial amount of already published work in this space. How do they all relate, which parts are required for sacm, which parts are optional for sacm, and which parts are missing for sacm? What (if any) change control issues arise if we adopt/refer to non-IETF specifications? I say this knowing there are, but there'd better be non-USG use cases. It'd be good to hear from those that would use sacm to say yep we're looking for that. Another thing I've been wondering is whether sacm targets, which can be just about any IP-based box, OS, application running on the box/OS (right?), are ready to adopt yet another interface. Are the router, firewall, OS, and phone folks on board? I'd rather not build something hoping that they will come, if you know what I mean. What can/can't be done with existing protocols/models/languages developed in the IETF? Having multiple ways to manage/monitor/collect something is non-ideal so I'm dying to know why for example netconf can't be used or can't be extended and then used. spt _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm ------=_NextPart_000_0033_01CDA080.68DACC00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMTAw MjEzMjkyM1owIwYJKoZIhvcNAQkEMRYEFGlA3C+xM7vAH4woJ66d2mQLZcgVMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAJcSc9ttM/rf/+mhy2fNvJV+fhaVGNspydIicDjyEmWFa 17rdR2uYTOgeUdUBwgwF3VFKlH+7MSlkFxKTkNeS8YFQ/MblGpRayd/0EfMEE5tGFQuMVGXEz4FN kpm5uah/3DpZckUyLKdsrzaJseDNMpRMMp9og4HP4b8qkqvjZgkAAAAAAAA= ------=_NextPart_000_0033_01CDA080.68DACC00-- From turners@ieca.com Tue Oct 2 07:36:13 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A93721F84D6 for ; Tue, 2 Oct 2012 07:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.137 X-Spam-Level: X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[AWL=-0.731, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPoEe7BsQNkn for ; Tue, 2 Oct 2012 07:36:12 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.41.245.8]) by ietfa.amsl.com (Postfix) with ESMTP id D574321F84D4 for ; Tue, 2 Oct 2012 07:36:12 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id B7EE8236688AE; Tue, 2 Oct 2012 09:36:12 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 93B3A236687F2 for ; Tue, 2 Oct 2012 09:36:12 -0500 (CDT) Received: from [108.18.174.220] (port=60101 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TJ3a0-0001wb-6a for sacm@ietf.org; Tue, 02 Oct 2012 09:36:12 -0500 Message-ID: <506AFBDB.3010008@ieca.com> Date: Tue, 02 Oct 2012 10:36:11 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sacm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:60101 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 7 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [sacm] sacm bof co-chairs X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:36:13 -0000 Dan Romascanu has agreed to co-chair the BOF with Kathleen Moriarty. Dan's a long time IETF participant, was a Ops/Man Area Director for 6 years, and knows a thing or two about management. spt From stevek@tagvault.org Tue Oct 2 07:37:38 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD38621F84D7 for ; Tue, 2 Oct 2012 07:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.874 X-Spam-Level: X-Spam-Status: No, score=0.874 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, J_CHICKENPOX_28=0.6, MANGLED_FROM=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lUZ6aJv2wHj for ; Tue, 2 Oct 2012 07:37:17 -0700 (PDT) Received: from tagvault.org (tagvault.org [70.32.84.97]) by ietfa.amsl.com (Postfix) with ESMTP id E1FA021F84D4 for ; Tue, 2 Oct 2012 07:37:16 -0700 (PDT) Received: (qmail 17688 invoked from network); 2 Oct 2012 07:34:05 -0700 Received: from 108-247-126-13.lightspeed.sntcca.sbcglobal.net (HELO ?192.168.0.77?) (108.247.126.13) by tagvault.org with SMTP; 2 Oct 2012 07:34:04 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <00C069FD01E0324C9FFCADF539701DB32389D452@ex2k10mb2.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB32389D452@ex2k10mb2.corp.yaanatech.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----TY4J2HR0X5MD4M53JB1Z1RSG27DIYR" From: Steve Klos Date: Tue, 02 Oct 2012 07:33:52 -0700 To: sacm@ietf.org Message-ID: <05517118-0dbf-4b47-b03f-fb0ef2777d03@email.android.com> Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 14:37:38 -0000 ------TY4J2HR0X5MD4M53JB1Z1RSG27DIYR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Mike, Actually, I can't tell you who to trust. The SWID tags provide the trust chain (which may include multiple signatures from a variety of sources that include things like pgp and digital certs from a CA). What a particular organization then sets up as the entities, or certificates they trust is up to each org. Cheers, SK 408.202.1900 -- Sent from a mobile device. Please excuse brevity and typos. Michael Hammer wrote: >Steve, > > > >For #3, I would hope that trust is based on more than being well-known. >After all, we have known some well-known government agencies that have >failed miserably at security from time to time. Same thing with some >rather >large, well-known companies. Mom and Pop might actually be much better >at >doing it right because their very existence depends on it. > > > >Better to define trust as something you gain by following well-proven >methodologies that are traceable and testable. > > > >Mike > > > > > >From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >Steve Klos >Sent: Monday, October 01, 2012 11:59 PM >To: sacm@ietf.org >Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request > > > >Folks, > > > >A few notes now and I will follow-up at the IT SAC conference in >one-on-one >sessions, during various BoF sessions and I’m more than happy to >continue >this discussion thread as we move forward. > > > >Brant already provided many details and I’ve seen a variety of comments >on >this reflector covering various different topics on SWID tags. Let me >summarize in bullet points: > > > >1) SWID Tags provide authoritative identification information >provided >by the software publisher (authoritative by nature due to the digital >signatures applied by the publishers). > >2) SWID Tags do not need to be “registered” or “certified” to be >useful, but doing so ensure that the data provided in the tag meets a >well-known minimum data set and it also follows registered and >enumerated >values to ensure normalization. > >3) SWID tags can be created by third party organizations and will >vary >in the “trust” level based on the identification of the organization >creating the SWID tag. SWID tags created by “NIST”, for example would >have >a much higher degree of trust than tags created by “Mom and Pop Shop >Inc.” >Digital signatures (that include recognition by a CA) are used to >recognize >the creator. > >4) SWID tags provide support for suites/bundles and the various >software relationships within those software groupings. > >5) SWID tags also provide support for patches with the >identification >of which software the patch is targeted at. > >6) SWID tags support efforts to mitigate the software supply chain >security risk by including (in the secure asset management level of >certification), the footprint of each file on the installation media as >well >as for each file that may be copied onto the device the software is >being >installed on. These file level details utilize the SHA 2 (256) >algorithm >and are also digitally signed with the publishers signature. > >7) Through work with MITRE, NIST and others, the SWID standard has >been >extended to support many of the fields necessary to map against the CPE >name >structure – Brant and others have already referenced this work and the >document behind it. Note that TagVault.org is heavily involved in the >ISO >standards development efforts and these extensions are already targeted >to >be incorporated back into an amendment to the 19770-2 standard. > >8) To ensure we don’t “mix” standards – the effort for the SWID >tag >standard is to ensure the fields are defined properly and that software >publishers are required to include the data in these fields, however, >the >CPE name is defined as a process to concatenate fields. This enables >NIST, >IETF, or others to manage the CPE standard as required and for the >process >used to create the CPE names to be used as an integration point between >the >standards. > >9) Due to the fact that there is a vast library of tools, >processes, >etc invested in CPE names, my perspective on the integration is to keep >CPE >essentially as is, add the integration with SWID tag names and to >utilize >this information with the systems around it to normalize names and >terms for >both systems. > >10) SW Publishers are quickly coming to the realization that SWID >tags >lower their overall infrastructure costs due to many factors, they >provide >the data their customers have been requesting for quite some time and >they >provide the added value of ensuring that the customer is receiving only >what >the publisher published, so they add a level of supply chain risk >management >to the distribution process. Microsoft and Symantec have certainly >recognized and embraced these benefits and are quickly working to >integrate >certified SWID tags into their build environments to provide the >highest >value to their customers. > > > >My presentation is on Wed afternoon from 4:30 to 5:30 and as many on >this >distribution are aware – this is an area I’m passionate about. Many IT >processes from compliance to security to logistics require >authoritative >identification of software. Anyone who’s worked with tools in this >area >knows that existing systems vary dramatically in their abilities and >generally data sets between different tools cannot be easily reconciled >against each other. The fact that SWID tags can provide solutions to >these >areas, are being supported directly by publishers and can be integrated >into >the SCAP infrastructure and can even provide a direct bridge between >discovery data and CPE names, seem to make this technology an ideal fit >for >this community. > > > >Looking forward to seeing many of you on Wed! > > > >Regards, > > > >Steve Klos > >From: Cheikes, Brant A. [mailto:bcheikes@mitre.org] >Sent: Monday, October 01, 2012 7:40 AM >To: Adam Montville; Jan-Oliver Wagner; sacm@ietf.org >Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon >Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request > > > >I’m sorry I didn’t join this thread sooner, but I’ll try to catch up. >I’ve >been leading the CPE project at MITRE for the last three years, and for >the >last year-plus have been working closely with Steve Klos, the Executive >Director of TagVault.org, to assess similarities/differences between >the CPE >and SWID tag standards, and to develop a roadmap that enables the two >standards to interoperate in some fashion. Steve and I chaired a >session at >the recent Developer Days workshop on the topic; see: > >http://cpe.mitre.org/news/index.html#jul272012b > > > >CPE names and SWID tags are very different things, with overlapping and >non-overlapping use cases, different value propositions to >stakeholders, and >different procedures for creation and maintenance. The CPE v2.3 >standard is >documented in a suite of NIST IRs, and the SWID tag standard is >documented >in ISO/IEC 19770-2:2009. This is not the proper venue for tutorials on >either CPE or SWID; I would encourage those who know CPE to learn more >about >SWIDs using TagVault.org resources. Also note that Steve Klos will be >speaking today at ITSAC. > > > >In my view, both CPE and SWID need to be considered when discussing >asset >inventory solutions. I suspect that SWID tags will eventually replace >CPE >names, but that will depend on market uptake and on how well we can >deploy >and use so-called “third-party” SWID tags—non-authoritative tags >created by >entities other than the software publisher/creator. Adam is right that >SWID >tagging is a relatively new concept. There aren’t many vendors yet who >have >adopted tags, but there definitely are some, including Symantec and >most >recently Microsoft. SWIDs are today where CPE was perhaps five years >ago, >in terms of adoption and coverage. Give it time. > > > >SWID tags are full-fledged XML documents, whereas CPE names are just >identifying strings assigned by a third party (NIST) to software >products. >Embedded within the SWID tag document is a unique ID, which lacks the >readability of a CPE name but could serve the same function as a CPE >name. >SWID tags are associated with individual product releases; CPE names >can >also be associated with individual products, but also have the >capability to >identify broader classes of a product. You can create a CPE name that >generically refers to “all Windows 7 operating systems”, but you can’t >do >that with a SWID tag. > > > >The main issue with CPE is that it has a relatively unsustainable O&M >profile. Since software publishers haven’t (and largely won’t) adopt >CPE >and build CPE names somehow into their products (whatever that might >mean; >CPE thus far hasn’t addressed this issue), we need a central >authority—NIST—to devote ongoing resources to maintaining the CPE >dictionary, with names arriving only when submitted by a member of the >“CPE >community” in response to a naming need. In contrast, software >publishers >who adopt SWID tagging create the tags at product release time, and the >tag >is included in the installation package for the product. When the >product >is installed, the tag is placed on the endpoint. When the product is >uninstalled, the tag is removed. With the addition of certification >and >digital signing of tags (not available in CPE), one can have some >guarantee >that the tag has not been tampered with. The TagVault community is >considering the addition of a “secure asset management” certification >level, >which would require certified tags to include a “package footprint” >element >documenting the individual files which comprise the tagged product. >These >are features well beyond CPE. > > > >There was a question about CPE’s ability to represent product >suites/groups. >You can create a CPE name for “Microsoft Office 2010 Professional”, and >you >can create separate CPE names for all the products in that suite (Word, >PowerPoint, etc.), but CPE provides no way to represent the fact that >by >installing MS Office 2010 you also install all the individual products >that >are included. SWID tags let you do that explicitly. > > > >That’s all for now—I’ve gone on long enough. I’ll try to keep a closer >eye >on this thread and do a better job of answering questions as they come >up. > > > >Cheers, > >/Brant > > > >Brant A. Cheikes >The MITRE Corporation >202 Burlington Road, M/S K302 >Bedford, MA 01730-1420 >Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352 > > > >From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of >Adam >Montville >Sent: Wednesday, September 26, 2012 9:23 AM >To: Jan-Oliver Wagner; sacm@ietf.org >Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon >Subject: [sacm] SWID and CPE: WAS - Re: SACM BoF Request > > > >This seems like an important discussion. Asset management is, >arguably, the >most important foundational piece of an effective information security >program, as our use case document [1] recognizes (asset management is >the >first recognized capability in support of Use Case 1). Clearly, there >are >pros and cons to leveraging CPE and/or SWID, and after quickly reading >through some of the information available at TagVault [2], it seems >clear >that SWIDs are roughly equivalent to CPE for operating systems and >applications. > > > >Before looking at the differences between CPE and SWID, it's probably a >good >idea to understand exactly what we need from a software asset >classification >scheme not only within our use cases, but also from a couple of control >frameworks our use cases support (I prefer to look at the Critical >Audit >Guidelines (CAG) published by SANS and ISO 27002). > > > >Both the CAG and 27002 make reference to managing assets, but only in >terms >of keeping an inventory. The CAG goes further by explicitly stating >(in >Critical Control 2) that we need to have an inventory of all authorized >and >unauthorized software. I don't believe either really mentions anything >about corrective actions, except implicitly in sections related to >incident >response. > > > >So, we have a clear need to look at an instance of software, classify >it, >and build or contribute to an identity profile for it for continued >reference. Can CPE handle this classification for for us? Yes. Can >SWID >handle this classification for us? It seems so. Note that we should >not >rely on either of these methods to identify software for targeted >actions – >that would be the domain of Asset Identification (we could use CPE or >SWID >to specify classes of targets for actions). > > > >Distribution and operational identification seems important to consider >as >well. CPEs aren't installed with the software and require some >assessment >action to derive. SWIDs, on the other hand, appear to be distributed >by the >software publisher [3]. Moreover, SWIDs are certified and signed by >TagVault. I'm unsure of the details about how SWIDs become available >on a >given system (they still need to be actively collected from a target >system >at some point). > > > >At this point, the difference between the two is really volume of >available >"tags" (we can reasonably call a CPE name a "tag" in this context), and >this >is where I see the rubber meeting the road – when an operational >component >is implicitly or explicitly required for a standard to work as intended >at >scale. > > > >There seems to be very little information about SWID volumes available >(at >least in the limited time I've had to search around), so it's difficult >to >judge how well they've penetrated the market. The last press release >from >TagVault is from 2010, which may suggest a dropping off of the effort >or a >satisfaction that they've done enough. Information about CPE volume >seems >most readily available from NVD [5]. > > > >Can anyone on this list provide additional details about SWID? > > > >I think it may be useful, from a community perspective, to be able to >handle both software identification types, provided both are >operationally >feasible and foreseeably sustainable. For example, the ai:software >element >defined by the Asset Identification draft [4] has an optional CPE >attribute >that could just as easily be complemented by an optional SWID >attribute. > > > > > >[1] http://tools.ietf.org/html/waltermire-sacm-use-cases-02 > >[2] http://www.tagvault.org > >[3] http://www.tagvault.org/swid-tag-lifecycle > >[4] >http://trac.tools.ietf.org/html/draft-montville-sacm-asset-identification-00 > > >[5] http://nvd.nist.gov/cpe.cfm > > > > > > > >On 9/26/12 3:28 AM, "Jan-Oliver Wagner" > >wrote: > > > >On Mittwoch, 26. September 2012, Baker, Jon wrote: > >I am a big fan of SWIDs and believe that we would really benefit from >widespread SWID adoption. In my previous message, I was attempting to >state >that we need capabilities offer by both CPE and SWID. > > > >I am a big fan of CPE and believe it is fully compatible with Open >Source >reference > >implementation and widespread use/adoption in Open Source tools, >especially >also > >in commercial environments. > > > >Neglecting CPE in favour of SWID would IMHO be a drawback for >widespread >security > >automation because, as to my understanding, SWID is not fully >compatible >with the vendor-independent > >approaches. Convince me I am wrong and I'd be happy ;-) > > > > > >(Sorry for jumping in here, it was just something I am worried about >since >some time already > >so I spontaneously reacted on the keywords :-) > > > > > >-- > >Dr. Jan-Oliver Wagner | ++49-541-335084-0 | >http://www.greenbone.net/ > >Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG >Osnabrück, HR >B 202460 > >Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner > > > > > > > > ------TY4J2HR0X5MD4M53JB1Z1RSG27DIYR Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Mike,

Actually, I can't tell you who to trust. The SWID tags provide the trust chain (which may include multiple signatures from a variety of sources that include things like pgp and digital certs from a CA).

What a particular organization then sets up as the entities, or certificates they trust is up to each org.

Cheers,

SK
408.202.1900
--
Sent from a mobile device. Please excuse brevity and typos.

Michael Hammer <michael.hammer@yaanatech.com> wrote:

Steve,

 

For #3, I would hope that trust is based on more than being well-known.  After all, we have known some well-known government agencies that have failed miserably at security from time to time.  Same thing with some rather large, well-known companies.  Mom and Pop might actually be much better at doing it right because their very existence depends on it.

 

Better to define trust as something you gain by following well-proven methodologies that are traceable and testable.

 

Mike

 

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Steve Klos
Sent: Monday, October 01, 2012 11:59 PM
To: sacm@ietf.org
Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request

 

Folks,

 

A few notes now and I will follow-up at the IT SAC conference in one-on-one sessions, during various BoF sessions and I’m more than happy to continue this discussion thread as we move forward.

< span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#993366">

 

Brant already provided many details and I’ve seen a variety of comments on this reflector covering various different topics on SWID tags.  Let me summarize in bullet points:

 

1)      SWID Tags provide authoritative identification information provided by the so ftware publisher (authoritative by nature due to the digital signatures applied by the publishers).

2)      SWID Tags do not need to be “registered” or “certified” to be useful, but doing so ensure that the data provided in the tag meets a well-known minimum data set and it also follows registered and enumerated values to ensure normalization.

3)      SWID tags can be created by third party organizations and will vary in the “trust” level based on the identification of the organization creating the SWID tag.  SWID tags created by “NIST”, for example would have a much higher degree of trust than tags created by “Mom and Pop Shop Inc.”  Digital signatures (that include recognition by a CA) are used to recognize the creator.

4)      SWID tags provide support for suites/bundles and the various software relationships within those software groupings. 

5)      SWID tags also provide support for patches with the identification of which software the patch is targeted at.

6)      SWID tags support efforts to mitigate the software supply chain security risk by including (in the secure asset management level of certification), the footprint of each file on the installation media as well as for each file that may be copied onto the device the software is being installed on.  These file level details utilize the SHA 2 (256) algorithm and are also digitally signed with the publishers signature.

7)      Through work with MITRE , NIST and others, the SWID standard has been extended to support many of the fields necessary to map against the CPE name structure – Brant and others have already referenced this work and the document behind it.  Note that TagVault.org is heavily involved in the ISO standards development efforts and these extensions are already targeted to be incorporated back into an amendment to the 19770-2 standard.

8)      To ensure we don’t “mix” standards – the effort for the SWID tag standard is to ensure the fields are defined properly and that software publishers ar e required to include the data in these fields, however, the CPE name is defined as a process to concatenate fields.  This enables NIST, IETF, or others to manage the CPE standard as required and for the process used to create the CPE names to be used as an integration point between the standards.

9)      Due to the fact that there is a vast library of tools, processes, etc invested in CPE names, my perspective on the integration is to keep CPE essentially as is, add the integration with SWID tag names and to utilize this information with the systems around it to normalize names and t erms for both systems.

10)   SW Publishers are quickly coming to the realization that SWID tags lower their overall infrastructure costs due to many factors, they provide the data their customers have been requesting for quite some time and they provide the added value of ensuring that the customer is receiving only what the publisher published, so they add a level of supply chain risk management to the distribution process.  Microsoft and Symantec have certainly recognized and embraced these benefits and are quickly working to integrate certified SWID tags into their build environments to provide the highest value to thei r customers.

 

My presentation is on Wed afternoon from 4:30 to 5:30 and as many on this distribution are aware – this is an area I’m passionate about.  Many IT processes from compliance to security to logistics require authoritative identification of software.  Anyone who’s worked with tools in this area knows that existing systems vary dramatically in their abilities and generally data sets between different tools cannot be easily reconciled against each other.  The fact that SWID tags can provide solutions to these areas, are being supported directly by publishers and can be integrated into the SCAP infrastructure and can even provide a direct bridge between discovery data and CPE names, seem to make this technology an ideal fit for this community.

 

Looking forward to seeing many of you on Wed!

 

Regards,

 

Steve Klos

From: Cheikes, Brant A. [mailto:bcheikes@mitre.org]
Sent: Monday, October 01, 2012 7:40 AM
To: Adam Montville; Jan-Oliver Wagner; sacm@ietf.org
Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon
Subject: Re: [sacm] SWID and CPE: WAS - Re: SACM BoF Request

 

I’m sorry I didn’t join this thread sooner, but I’ll try to catch up.  I’ve been leading the CPE project at MITRE for the last three years, and for the last year-plus have been working closely with Steve Klos, the Executive Director of TagVault.org, to assess similarities/differences between the CPE and SWID tag standards, and to develop a roadmap that enables the two standards to interoperate in some fashion.  Steve and I chaired a session at the recent Developer Days workshop on the topic; see:

http://cpe.mitre.org/news/index.html#jul272012b

 

CPE names and SWID tags are very different things, with overlapping and non-overlapping use cases, different value propositions to stakeholders, and different procedures for creation and maintenance.  The CPE v2.3 standard is documented in a suite of NIST IRs, and the SWID tag standard is documented in ISO/IEC 19770-2:2009.  This is not the proper venue for tutorials on either CPE or SWID; I would encourage those who know CPE to learn more about SWIDs using TagVault.org resources.  Also note that Steve Klos will be speaking today at ITSAC.

 

In my view, both CPE and SWID need to be considered when discussing asset inventory solutions.  I suspect that SWID tags will eventually replace CPE names, but that will depend on market uptake and on how well we can deploy and use so-called “third-party” SWID tags—non-authoritative tags created by entities other than the software publisher/creator.  Adam is right that SWID tagging is a relatively new concept.  There aren’t many vendors yet who have adopted tags, but there definitely are some, including Symantec and most recently Microsoft.  SWIDs are today where CPE was perhaps five years ago, in terms of adoption and coverage.  Give it time.

 

SWID tags are full-fledged XML documents, whereas CPE names are just identifying strings assigned by a third party (NIST) to software products.  Embedded within the SWID tag document is a unique ID, which lacks the readability of a CPE name but could serve the same function as a CPE name.  SWID tags are associated with individual product releases; CPE names can also be associated with individual products, but also have the capability to identify broader classes of a product.  You can create a CPE name that generically refers to “all Windows 7 operating systems”, but you can’t do that with a SWID tag.

 

The main issue with CPE is that it has a relatively unsustainable O&M profile.  Since software publishers haven’t (and largely won’t) adopt CPE and build CPE names somehow into their products (whatever that might mean; CPE thus far hasn’t addressed this issue), we need a central authority—NIST—to devote ongoing resources to maintaining the CPE dictionary, with names arriving only when submitted by a member of the “CPE community” in response to a naming need.  In contrast, software publishers who adopt SWID tagging create the tags at product release time, and the tag is included in the installation package for the product.  When the product is installed, the tag is placed on the endpoint.  When the product is uninstalled, the tag is removed.  With the addition of certification and digital signing of tags (not available in CPE), one can have some guarantee that the tag has not been tampered with.  The TagVault community is considering the addition of a “secure asset management” certification level, which would require certified tags to include a “package footprint” element documenting the individual files which comprise the tagged product.  These are features well beyond CPE.

 

There was a question about CPE’s ability to represent product suites/groups.  You can create a CPE name for “Microsoft Office 2010 Professional”, and you can create separate CPE names for all the products in that suite (Word, PowerPoint, etc.), but CPE provides no way to represent the fact that by installing MS Office 2010 you also install all the individual products that are included.  SWID tags let you do that explicitly.

 

That’s all for now—I’ve gone on long enough.  I’ll try to keep a closer eye on this thread and do a better job of answering questions as they come up.

 

Cheers,

/Brant

 

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Wednesday, September 26, 2012 9:23 AM
To: Jan-Oliver Wagner; sacm@ietf.org
Cc: Moriarty, Kathleen; Waltermire, David A.; Baker, Jon
Subject: [sacm] SWID and CPE: WAS - Re: SACM BoF Request

 

This seems like an important discussion.  Asset management is, arguably, the most important foundational piece of an effective information security program, as our use case document [1] recognizes (asset management is the first recognized capability in support of Use Case 1).  Clearly, there are pros and cons to leveraging CPE and/or SWID, and after quickly reading through some of the information available at TagVault [2], it seems clear that SWIDs are roughly equivalent to CPE for operating systems and applications.

 

Before looking at the differences between CPE and SWID, it's probably a good idea to understand exactly what we need from a software asset classification scheme not only within our use cases, but also from a couple of control frameworks our use cases support (I prefer to look at the Critical Audit Guidelines (CAG) published by SANS and ISO 27002).

 

Both the CAG and 27002 make reference to managing assets, but only in terms of keeping an inventory.  The CAG goes further by explicitly stating (in Critical Control 2) that we need to have an inventory of all authorized and unauthorized software.  I don't believe either really mentions anything about corrective actions, except implicitly in sections related to incident response.  

 

So, we have a clear need to look at an instance of software, classify it, and build or contribute to an identity profile for it for continued reference.  Can CPE handle this classification for for us?  Yes.  Can SWID handle this classification for us?  It seems so.  Note that we should not rely on either of these methods to identify software for targeted actions – that would be the domain of Asset Identification (we could use CPE or SWID to specify classes of targets for actions).

 

Distribution and operational identification seems important to consider as well.  CPEs aren't installed with the software and require some assessment action to derive.  SWIDs, on the other hand, appear to be distributed by the software publisher [3].  Moreover, SWIDs are certified and signed by TagVault.  I'm unsure of the details about how SWIDs become available on a given system (they still need to be actively collected fr om a target system at some point).

 

At this point, the difference between the two is really volume of available "tags" (we can reasonably call a CPE name a "tag" in this context), and this is where I see the rubber meeting the road – when an operational component is implicitly or explicitly required for a standard to work as intended at scale.  

 

There seems to be very little information about SWID volumes available (at least in the limited time I've had to search around), so it's difficult to judge how well they've penetrated the market.  The last press release from TagVault is from 2010, which may suggest a dropping off of the effort or a satisfaction that they've done enough.  Information about CPE volume seems most readily available from NVD [5].

 

Can anyone on this list provide additional details about SWID?

 

I think it may be useful, from a  community perspective, to be able to handle both software identification types, provided both are operationally feasible and foreseeably sustainable.  For example, the ai:software element defined by the Asset Identification draft [4] has an optional CPE attribute that could just as easily be complemented by an optional SWID attribute.

 

 

 

 

 

On 9/26/12 3:28 AM, "Jan-Oliver Wagner" <Jan-Oliver.Wagner@greenbone.net> wrote:

 

On Mittwoch, 26. September 2012, Baker, Jon wrote:

I am a big fan of SWIDs and believe that we would really benefit from widespread SWID adoption. In my previous message, I was attempting to state that we need capabilities offer by both CPE and SWID.

 

I am a big fan of CPE and believe it is fully compatible with Open Source reference

implementation and widespread use/adoption in Open Source to ols, especially also

in commercial environments.

 

Neglecting CPE in favour of SWID would IMHO be a drawback for widespread security

automation because, as to my understanding, SWID is not fully compatible with the vendor-independent

approaches. Convince me I am wrong and I'd be happy ;-)

 

 

(Sorry for jumping in here, it was just something I am worried about since some time already

so I spontaneously reacted on the keywords :-)

 

 

--

Dr. Jan-Oliver Wagner |  ++49-541-335084-0  |  http://www.greenbone.net/

Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 202460

Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner

 

 

 

 

------TY4J2HR0X5MD4M53JB1Z1RSG27DIYR-- From stevek@tagvault.org Tue Oct 2 09:40:10 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FAC21F852E for ; Tue, 2 Oct 2012 09:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6VRZ2X2ZQGi for ; Tue, 2 Oct 2012 09:40:09 -0700 (PDT) Received: from tagvault.org (tagvault.org [70.32.84.97]) by ietfa.amsl.com (Postfix) with ESMTP id 1135921F8532 for ; Tue, 2 Oct 2012 09:40:08 -0700 (PDT) Received: (qmail 8154 invoked from network); 2 Oct 2012 09:36:58 -0700 Received: from tagvault.org (HELO ?172.31.67.235?) (64.168.229.50) by tagvault.org with SMTP; 2 Oct 2012 09:36:55 -0700 User-Agent: Kaiten Mail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----VV2HSVLTRPYJH1YJRDUJGY3Y4JKTVR" From: Steve Klos Date: Tue, 02 Oct 2012 09:36:53 -0700 To: sacm@ietf.org Message-ID: Subject: [sacm] SWID Tags and Open Source Software X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 16:40:10 -0000 ------VV2HSVLTRPYJH1YJRDUJGY3Y4JKTVR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Jan, SWID's apply to open source software in exactly the same way. The XSD for the SWID tag is located here - http://standards.iso.org/iso/19770/-2/2009/. The next version of the TagVault.org certification requirements will also be posted on the TagVault.org web site for everyone to download. Finally, as the XSD is likely not quite sufficient for the use of open source developers, there is one piece of documentation missing - we essentially need to create a document that provides the descriptive information from 19770-2 in a freely downloadable document. I can't provide specifics, but I can tell you that I know at least one installation tool for Windows software is very much promoting open source access to the SWID standard - including full support for PGP digital signatures. If you're at the IT SAC conference, I'd love to catch up with you to learn more about the requirements you believe the open source community may have that SWID tags don't address... Cheers, SK thanks to all for the comprehensive insights into SWID vs. CPE. However, I come back to my original concerns, cited below, which so far remained mostly unanswered. Most insights were about technical aspects. I still saw no argument why SWID is well compatible with Open Source community and vendor-independent approaches. CPE seems by far more competitive and compatible in this regard. At least I found no clarifying statements from SWID side. Maybe I did not manage to find it. At least such were not brought to attention in this thread. I am starting to have doubts about the non-technical genes of SWID to solve the challenge of helpful product enumeration for security automation. If we only target a part of the IT industry, there will always be a gap in security coverage. It has to be filled with another concept and automatically we end up with two of them. Which in turn will make IT security more expensive for customers. I'd really love to be prooven wrong with my pessimistic concerns! All the best Jan Cheers, SK 408.202.1900 -- Sent from a mobile device. Please excuse brevity and typos. ------VV2HSVLTRPYJH1YJRDUJGY3Y4JKTVR Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Jan,

SWID's apply to open source software in exactly the same way.  The XSD for the SWID tag is located here - http://standards.iso.org/iso/19770/-2/2009/.  The next version of the TagVault.org certification requirements will also be posted on the TagVault.org web site for everyone to download.  Finally, as the XSD is likely not quite sufficient for the use of open source developers, there is one piece of documentation missing - we essentially need to create a document that provides the descriptive information from 19770-2 in a freely downloadable document.

I can't provide specifics, but I can tell you that I know at least one installation tool for Windows software is very much promoting open source access to the SWID standard - including full support for PGP digital signatures.

If you're at the IT SAC conference, I'd love to catch up with you to learn more about the requirements you believe the open source community may have that SWID tags don't address...

Cheers,

SK

thanks to all for the comprehensive insights into SWID vs. CPE.

However, I come back to my original concerns, cited below, which so far remained mostly unanswered.

Most insights were about technical aspects. I still saw no argument why SWID is well compatible with Open Source community and vendor-independent approaches. CPE seems by far more competitive and compatible in this regard. At least I found no clarifying statements from SWID side. Maybe I did not manage to find it. At least such were not brought to attention in this thread.

I am starting to have doubts about the non-technical genes of SWID to solve the challenge of helpful product enumeration for security automation. If we only target a part of the IT industry, there will always be a gap in security coverage. It has to be filled with another concept and automatically we end up with two of them. Which in turn will make IT security more expensive for customers.

I'd really love to be prooven wrong with my pessimistic concerns!

All the best

Jan


Cheers,

SK
408.202.1900
--
Sent from a mobile device. Please excuse brevity and typos. ------VV2HSVLTRPYJH1YJRDUJGY3Y4JKTVR-- From blibbet@gmail.com Tue Oct 2 11:08:39 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4985621F845F for ; Tue, 2 Oct 2012 11:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3iZngikFXsH for ; Tue, 2 Oct 2012 11:08:38 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E66021F8445 for ; Tue, 2 Oct 2012 11:08:38 -0700 (PDT) Received: by padfb11 with SMTP id fb11so5579242pad.31 for ; Tue, 02 Oct 2012 11:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=5eZuzFNEsNEH+Adre585Hq4NCewJtc0pqhY+yqr68cI=; b=K3WHNeZaDeVDQzPf2/5TN/eEIL2gyIShvNwHZDLxMIS5AA6A1x00Ud6zDBf4kzq5Vm FGT1FEXCuQVOO9calQFcpbAeida7wO7yC4JNemT6jLgyNsFIBm5f8+x9+v7d5OFG2UQp x3hfO2hLejh18PHNZqkSYv0X144EiHsCgP382VOTCHxUmXc6LcE53REfitZaHnc++rmF o1AD+2vkLO+jjWfu5q7hSCsKW2BILDTyJb2tyW0dSXFe1MHmtC/HOQ55dZYWMtKhhj3x 8OOlrNICxudkOHpNKuOa+tWGwKWbdvfD8ZMydurgdMsWzlY7V8A2HjJBouh+y1yjN/lI 3BKQ== Received: by 10.68.230.232 with SMTP id tb8mr6424706pbc.19.1349201318062; Tue, 02 Oct 2012 11:08:38 -0700 (PDT) Received: from box.local (50-54-224-51.evrt.wa.frontiernet.net. [50.54.224.51]) by mx.google.com with ESMTPS id bn1sm1067625pab.8.2012.10.02.11.08.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 02 Oct 2012 11:08:35 -0700 (PDT) Message-ID: <506B2DD1.6070500@gmail.com> Date: Tue, 02 Oct 2012 11:09:21 -0700 From: Lee Fisher User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sacm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sacm] SWID Tags and Open Source Software X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 18:08:39 -0000 Can the SWID specs be packaged up into a Debian package, or does the TagVault legal barriers prevent this? I think this is possible with SCAP, and SPDX, but not with SWID. Without base packages like this to depend on, then open source development isn't viable. Where is data that clarifies what Open Source licenses are viable with content using the TagVault legal restrictions? Can I use GPLv2, v3, BSD, etc with my apps, and include a snapshot of the SWID markup files needed for my open source project? I'm concerned about any IETF use of SWID standards, if you cannot freely access the spec and data without being forced to join their trade group. It seems a step backward from NIST SCAP, and IETF-style standards. I'm also slightly6 concerned with the nontechnical (legal) heritage of SWID (copy protection) and SPDX (IP violations). Hopefully the metadata they create will be not be focused on the agenda of their creators. But with SPDX, the creators control the trade group, and force you to join and agree do help with their agenda... SCAP CPE does not have this legal legacy to deal with, and is strictly focused on technical issues (security). On 10/2/12 9:36 AM, Steve Klos wrote: [...] > I can't provide specifics, but I can tell you that I know at least > one installation tool for Windows software is very much promoting > open source access to the SWID standard - including full support for > PGP digital signatures. [...] It seems odd that open source access is being promoted, yet open source developers are not able to obtain specifics about how to participate in those promotions. Unless you mean some Windows-only product is going to someday promote Windows-only open source, once released. :-) From stevek@tagvault.org Tue Oct 2 14:27:51 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D85621F85C6 for ; Tue, 2 Oct 2012 14:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwWjYLz1e2wi for ; Tue, 2 Oct 2012 14:27:50 -0700 (PDT) Received: from tagvault.org (tagvault.org [70.32.84.97]) by ietfa.amsl.com (Postfix) with ESMTP id 9E06921F8448 for ; Tue, 2 Oct 2012 14:27:49 -0700 (PDT) Received: (qmail 32290 invoked from network); 2 Oct 2012 14:27:48 -0700 Received: from 122.sub-70-196-4.myvzw.com (HELO android-dbdc3164af5d3000) (70.196.4.122) by tagvault.org with SMTP; 2 Oct 2012 14:27:48 -0700 User-Agent: Kaiten Mail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----N9H78MZ16AXQE3X0ZKW8IBX3YSWJ4E" From: Steve Klos Date: Tue, 02 Oct 2012 14:27:44 -0700 To: sacm@ietf.org Message-ID: Subject: Re: [sacm] SWID Tags and Open Source Software X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 21:27:51 -0000 ------N9H78MZ16AXQE3X0ZKW8IBX3YSWJ4E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Lee, Will try to respond to your queries below. Using a mobile system, so bear with me as I try do provide in-line comments in bold... Before proceeding, let me be clear - I'm not a lawyer and my comments should not be considered to be legal advice. You should talk with your attorney to validate any information being provided in this e-mail. Can the SWID specs be packaged up into a Debian package, or does the TagVault legal barriers prevent this? I think this is possible with SCAP, and SPDX, but not with SWID. Without base packages like this to depend on, then open source development isn't viable. The TagVault.org legal barriers are defined by the members and the organization. The goal of TagVault.org is to fix a number of issues that have been pervasive in the software industry for some time. As a program, TagVault.org is a non-profit managed under IEEE-ISTO and is not looking to profit from these efforts. The program does, however, need to do some development and needs computing and networking services to provide the structure necessary to resolve these issues. I expect that commercial organizations will be more than willing to be members of the program and to help with the definitions. That being the case, the expectation and desire is to provide as much as is possible in a form that can be redistributed. The ISO standard - obviously cannot be redistributed, however the XSD can. The expectation is that the TagVault.org materials will be able to be redistributed whenever possible. TagVault.org (and others) can also provide additional materials to help provide context to the XSD structure - it's a matter of time and resources. Where is data that clarifies what Open Source licenses are viable with content using the TagVault legal restrictions? Can I use GPLv2, v3, BSD, etc with my apps, and include a snapshot of the SWID markup files needed for my open source project? The direction I would like to move with all tools and source is to utilize Apache licenses to enable commercial use of the source. You can use whatever licensing you want since the actual SWID tag is an XML file that's based on freely available, storable and redistributable XSD files. There should not be any issue with including a SWID tag in any software product. I'm concerned about any IETF use of SWID standards, if you cannot freely access the spec and data without being forced to join their trade group. It seems a step backward from NIST SCAP, and IETF-style standards. The goal is to provide certification services to commercial organizations and to provide freely available access for materials that open source publishers/users would utilize. There is a strong desire to support both models and I've not heard anything from the board of directors that would indicate this will change. I'm also slightly6 concerned with the nontechnical (legal) heritage of SWID (copy protection) and SPDX (IP violations). Hopefully the metadata they create will be not be focused on the agenda of their creators. But with SPDX, the creators control the trade group, and force you to join and agree do help with their agenda... SCAP CPE does not have this legal legacy to deal with, and is strictly focused on technical issues (security). I do want to be perfectly clear - SWID's have nothing to do with copy protection. In fact, that was explicitly placed out of scope for the development of the standard and it's not something that TagVault.org has taken up. It certainly has not been anything that TagVault.org members have indicated they want the program to address either. The area the standard addresses is authoritative software identification from the time the software leaves the publisher, as it's patched and upgraded and eventually retired. We are working with commercial vendors to get them to help in the process of setting up the tools, repository, documentation, services, support etc. If there were a different funding model available that would still allow the program to work as a non-profit organization that will support any program world-wide, I'm completely open to discussing the possibilities. At the moment, TagVault.org is contracting with companies to create the utilities that validate and sign SWID tags as well as validate the certified tags. The goal, once we have these services up and running is to provide a parallel structure for open source utilities that will not require fees. I personally would love to do more to support the open source community, but only have so many hours in the day and have a very limited amount of money for consultants to develop the tools. If there are some in the open source community who are very interested in supporting this effort *AND* are willing to commit to providing resources to make this happen, I'd be more than happy to work with them and provide information and review efforts. We can also work through issues of getting these individuals/organizations involved with TagVault.org without requiring a membership fee. Having said that, every member added to the program requires additional support costs from the program management team, so we're in a bit of a bind - a desire to support FOSS software, but no money available to move forward with that effort... Suggestions? I'm very open to creative ideas here. Thoughts? Cheers, SK 408.202.1900 -- Sent from a mobile device. Please excuse brevity and typos. ------N9H78MZ16AXQE3X0ZKW8IBX3YSWJ4E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Lee,

Will try to respond to your queries below.  Using a mobile system, so bear with me as I try do provide in-line comments in bold...

Before proceeding, let me be clear - I'm not a lawyer and my comments should not be considered to be legal advice.  You should talk with your attorney to validate any information being provided in this e-mail.

Can the SWID specs be packaged up into a Debian package, or does the TagVault legal barriers prevent this? I think this is possible with SCAP, and SPDX, but not with SWID. Without base packages like this to depend on, then open source development isn't viable.

The TagVault.org legal barriers are defined by the members and the organization.  The goal of TagVault.org is to fix a number of issues that have been pervasive in the software industry for some time.  As a program, TagVault.org is a non-profit managed under IEEE-ISTO and is not looking to profit from these efforts.  The program does, however, need to do some development and needs computing and networking services to provide the structure necessary to resolve these issues.  I expect that commercial organizations will be more than willing to be members of the program and to help with the definitions.  That being the case, the expectation and desire is to provide as much as is possible in a form that can be redistributed. 

The ISO standard - obviously cannot be redistributed, however the XSD can.  The expectation is that the TagVault.org materials will be able to be redistributed whenever possible.  TagVault.org (and others) can also provide additional materials to help provide context to the XSD structure - it's a matter of time and resources.

Where is data that clarifies what Open Source licenses are viable with content using the TagVault legal restrictions? Can I use GPLv2, v3, BSD, etc with my apps, and include a snapshot of the SWID markup files needed for my open source project?

The direction I would like to move with all tools and source is to utilize Apache licenses to enable commercial use of the source.  You can use whatever licensing you want since the actual SWID tag is an XML file that's based on freely available, storable and redistributable XSD files.  There should not be any issue with including a SWID tag in any software product.

I'm concerned about any IETF use of SWID standards, if you cannot freely access the spec and data without being forced to join their trade group. It seems a step backward from NIST SCAP, and IETF-style standards.

The goal is to provide certification services to commercial organizations and to provide freely available access for materials that open source publishers/users would utilize.  There is a strong desire to support both models and I've not heard anything from the board of directors that would indicate this will change.

I'm also slightly6 concerned with the nontechnical (legal) heritage of SWID (copy protection) and SPDX (IP violations). Hopefully the metadata they create will be not be focused on the agenda of their creators. But with SPDX, the creators control the trade group, and force you to join and agree do help with their agenda... SCAP CPE does not have this legal legacy to deal with, and is strictly focused on technical issues (security).

I do want to be perfectly clear - SWID's have nothing to do with copy protection.  In fact, that was explicitly placed out of scope for the development of the standard and it's not something that TagVault.org has taken up.  It certainly has not been anything that TagVault.org members have indicated they want the program to address either.  The area the standard addresses is authoritative software identification from the time the software leaves the publisher, as it's patched and upgraded and eventually retired.

We are working with commercial vendors to get them to help in the process of setting up the tools, repository, documentation, services, support etc.  If there were a different funding model available that would still allow the program to work as a non-profit organization that will support any program world-wide, I'm completely open to discussing the possibilities.  At the moment, TagVault.org is contracting with companies to create the utilities that validate and sign SWID tags as well as validate the certified tags.  The goal, once we have these services up and running is to provide a parallel structure for open source utilities that will not require fees.

I personally would love to do more to support the open source community, but only have so many hours in the day and have a very limited amount of money for consultants to develop the tools.  If there are some in the open source community who are very interested in supporting this effort *AND* are willing to commit to providing resources to make this happen, I'd be more than happy to work with them and provide information and review efforts.  We can also work through issues of getting these individuals/organizations involved with TagVault.org without requiring a membership fee.  Having said that, every member added to the program requires additional support costs from the program management team, so we're in a bit of a bind - a desire to support FOSS software, but no money available to move forward with that effort...  Suggestions?

I'm very open to creative ideas here.  Thoughts?


Cheers,

SK
408.202.1900
--
Sent from a mobile device. Please excuse brevity and typos. ------N9H78MZ16AXQE3X0ZKW8IBX3YSWJ4E-- From cmschmidt@mitre.org Wed Oct 3 09:36:47 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1195121F8666 for ; Wed, 3 Oct 2012 09:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7AbLxD+xEld for ; Wed, 3 Oct 2012 09:36:46 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 252F521F866C for ; Wed, 3 Oct 2012 09:36:46 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 29DAB1F055A; Wed, 3 Oct 2012 12:36:45 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 18C7F1F053A; Wed, 3 Oct 2012 12:36:45 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.99]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.001; Wed, 3 Oct 2012 12:36:44 -0400 From: "Schmidt, Charles M." To: "xccdf-dev@nist.gov" , "oval-developer-list OVAL Developer List/Closed Public Discussion" , Multiple recipients of list , "tnc@trustedcomputinggroup.org" , "sacm@ietf.org" Thread-Topic: Announcing SCAP Messages for IF-M specification Thread-Index: Ac2hgh5hZ7yICDcAS3u8LJ+Y2hgzJw== Date: Wed, 3 Oct 2012 16:36:44 +0000 Message-ID: <80B432C0A0D105468E74A98942733F771FFC31FD@IMCMBX04.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0111_01CDA15B.5225B070" MIME-Version: 1.0 Subject: [sacm] Announcing SCAP Messages for IF-M specification X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 16:36:47 -0000 ------=_NextPart_000_0111_01CDA15B.5225B070 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hello all, I would like to announce that the Trusted Computing Group (TCG) has just released the "SCAP Messages for IF-M" draft specification for public comment. This specification describes a proposed standard for using TCG's Trusted Network Connect (TNC) (and, by extension, IETF's Network Endpoint Assessment (NEA)) to exchange SCAP content and direct SCAP assessments. Our goal with this specification is to bridge the existing communities of SCAP users and TNC users by standardizing the use of SCAP data formats and assessment conventions with TNC network protocols and functional components. The specification is currently open for public comment. You can download the specification at http://www.trustedcomputinggroup.org/resources/tnc_scap_messages_for_ifm. We are especially interested in getting input from vendors and users of both SCAP and TNC as our intent is for this standard to fit with the existing conventions and capabilities of these communities. For those of you attending the IT Security Automation Conference, I will be giving a short overview of this work on Friday at 3:30 in the Trusted Computing & Security Automation track. We have also scheduled a short BoF on this work for 3:00 on Thursday in room 350. Comments on the specification can be sent to SCAP-Messages-Comments@trustedcomputinggroup.org. We look forward to your input. Thanks, Charles ------=_NextPart_000_0111_01CDA15B.5225B070 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCCBS0w ggMVoAMCAQICEEw6UhQhT9OgRBVHf7KQ+1AwDQYJKoZIhvcNAQELBQAwKTEnMCUGA1UEAxMeTUlU UkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMB4XDTExMDQyNjE5NDU0NVoXDTIxMDQyNjE5NDgy MlowKTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUEUgUm9vdCBDQS0xMIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAtp8hR0hRq3im+Alwfb5ZHGP5k2OSY2TlVHYHIMUDH3MfW7b6 8lB3j3MwAMsxGK1ke/t6O4K0t9wRH4QDgOQ1CthmOGZW7xiN81h0vP1Yf14SNugUa7ZvH9KP3iXs y8QnOHal1bKf0Pa9KXib58qUuwfaZSCTW5P2ekqd8z4TETvfBWvPgDxyxnVsiAO6yL9WaRpMiSVM hYLWy3KRuU/gue0bVEi+qdg+hENh1NSNXpoqseS262nq5cx5wybR/PF0YstQ9NNlYDM5cLECKYHH zD6cXKJozuFXriswlE8rdna7VaxyZrfgC0ueEIY/tsj/65IyUhyPBwO0ZpW+Ls9Cd4Y+ERSu5mR5 Fd8w42eVzuosmk3s3AxrKC+Z4tXYkjaiWUduIegAiST1vJBwkS53vR+zrBX3Ep56l7MFVvW/GcsZ 9wUT2HG65JOeiVc2YzCEqLgQ3ZCBHn09oBag2lnMac+E2sKm9aKL3xzHs6cyD8qCJK9O8QLCqo3C mzASlOwtTFiLYgpPW/MSmgYOt9JrwHAzk97DHFKTFttjrXGMmhMVzadt1EjMn1Wv8t5WLBI0qSoX /MYi2CaeiDsEiWRu9Nmpu3pmi8m7tIR9csdbAVPks2soNMWOopGEpFQSDvU1+m77v2jIKQKYxYmN 2zUOJ4TJFL1osnZ/71MmLCDVd+ECAwEAAaNRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFFuHfZ/+bL4C6fPgKTqKVCUsnzgvMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqG SIb3DQEBCwUAA4ICAQAy78sXsP/eqHH8/uOYyxQ6TBDhkCBxNoy8MF2c9UDns5ADL1qyxPAlpDBs L+2h1Zzt3FvPjg0SoRE/9juyG1qxMzhlv0jdQx12tESdo3uBb61b1uuc4H/VxCJWDI4KZL/B53EI 8HGPjUBdLADgOmG99uffm5uarSkjtIX//Bz3U6QfzTPlVWFi4SmzRI2mp16GQ8RPuJ/WMloaAn8X H6EjS2oLjGZC8Pw8/C46W48NvZ1JZTrZvYZr7GmuvmplYK68SZv/T5Su+FlLRTy9uNXQLHtm6jKv nDH2yB66zTwfaDpnjILnrC2O7ANRVZc0KywiKiW3nB7Joq74/XVuMI1PiSByt2Qu+RIS/WAI5wMi bTmwSiBxQZqvuth+dXoakJyOP2Wg5jvL55v9RLZhDqMtRI5ovnOFvTgNJQqNPSekGtA+m6Ctl/vh kSg65FFCMhaSkn7vY2Il+R8HouWJN8wTaudeexnyHcD+Mlt8QaB5CErpDjeeGZfQ0FcYm+6TtlMz Dw5eFhT/J6QrABCxfgLkVFHurMcQD4JkmXXkq5bP+GNkY0Uy2LMbw/UD94OEV1LpfAqUkT+mu5Yb vxg+elFtsad+Ix8owW372xynIADh9q1bHm+j1OHPJmGALWK9miRpC4t3isfu3ZB0QpI/e2Po6MED 393Jb0YbzrcElFv6ZDCCBhwwggQEoAMCAQICCjXQ+u0AAgAAHHUwDQYJKoZIhvcNAQEFBQAwUDET MBEGCgmSJomT8ixkARkWA09SRzEVMBMGCgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRS RSBDb3Jwb3JhdGlvbiBQRSBDQS0xMB4XDTEyMDIwODE4MjYzN1oXDTE1MDIwNzE4MjYzN1owTjEL MAkGA1UEBhMCVVMxDjAMBgNVBAoTBU1JVFJFMQ8wDQYDVQQLEwZQZW9wbGUxHjAcBgNVBAMTFVNj aG1pZHQuQ2hhcmxlcy4yNTY1ODCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMrfqe4f m+ZeRZvWO7aYp89KmWSTnFKgZjWprxFQ8zmAlth3LKEVdNn4wZgdUz54uHZvi5uCvcQU0trt2iDw F/hQ6jdn3VZhZsmA7TnRHRocBYIWdhvTEjOXpsKj51kz6uizhseb3lGubSj2DwN6A6C4f5SQt5yw CkpwX0pz9WqaSrT2aGoHgWx9MOBww1+v5DS5VNhHIyCVw0eFoSJ8aZxcWMIRBDdoFOCFR33KKfU9 P+/vYaG7OiNQlko5d0vvCBApYGURyaBKde1Krd0wRTP9FCc5GD+5OYxZx4XAhBMgQuh2Hv7E8EM+ ORpRQ2fW1Pno5dTl/92Sl1RITgxcyvkCAwEAAaOCAfgwggH0MCgGA1UdJQQhMB8GCCsGAQUFBwME BgkrBgEEAXMCAQcGCCsGAQUFBwMCMB0GA1UdDgQWBBTYG13f8BosUG6c5VDRxlP6AJYFezAOBgNV HQ8BAf8EBAMCBsAwHgYDVR0RBBcwFYETY21zY2htaWR0QG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRp ZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8EQjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9y Zy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYI KwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUub3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUy MENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpodHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+Bgkr BgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwjho6WV4GNiT2CpKsShb6uAYE2g9KXfYeg+0kCAWQC AQcwFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgwNAYJKwYBBAGCNxUKBCcwJTAKBggrBgEFBQcDBDAL BgkrBgEEAXMCAQcwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQEFBQADggIBALqulox86p0q7Ry3fzT8 GOIMzBtv2HfzWXNciUVnvEtYtqfeSL+SmDU6JnVX2Mga7yzUdHnZ5J8+VfSARUpIIxoe56EI0Zc5 DJx1C4Uu5RErFCDf6Ye+YjZQHx6PI9jajX3b0Z1yyHDs5pfaDHZHLR7H5POdhJuna2SCk+d35/0g ciyUfa+yuwSZvpxsUSz6X/RnNe07w4K8631cShm3aAFE2ZQNndk+qqVDQ10MuDM/hLJMQFKCe+KV V2qqtrU879aF4nUh6aoq/i5pjHmV1c2uPx+LVX9uwaOQPOxIgbEuSC8dP6W5FAquGgLNI0bxCn5q eMza1rOXVQcpI5TCVzBtWfqPp0ipzWe/+PCl/T/aFbTeygC/JY/KjSpD+PMzOFjf7lhGjIx/bQUp pgbrcaUU2YX3ueygXDn9MyZZdS58hu49tC1Juq2TmhG8q/HAgD631tqRde6a2fuKfQX6cE0L6T2/ +bU39U+EExPz00bBzc2aMKMgayCFoqU2xH/nl2r8I9FiZbjcBwl02kvumOYcRTftIzesoj59LgGR y6iS728LHv1SJw11FE2yCVYb4Q1xtlKc8d9qp8p5UcCIu+zKFYqFRqSbdPBav7ZI169fR19tZWwy CzmXDYACGX6X38coRpdaTStwYC9Ed/2oB1bsr8iw57EAwD25hKX8RcbdMIIGYjCCBEqgAwIBAgIK FJcW0gAAAAAABDANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQ RSBSb290IENBLTEwHhcNMTEwNjE0MTc0NDQ0WhcNMTcwNjE0MTc1NDQ0WjBQMRMwEQYKCZImiZPy LGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUxIjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0 aW9uIFBFIENBLTEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDSxK9RXieqdTz4JWRk RMs/EOuF0P0S9SbspadLJkx/LDDnaAwmAnqfqm1n7/p82oVjy1yCye3SZu4Yp7fmDIAtWbkHvYOf xHkRv1ho/fhaNN0YRkd65oJJz2ngEbNZxdIiCoialQfX/iWU7ApQ+ovKbFV60v5E0p2mPncs20NY RfsaetdhnBZbFD9flDcXwJqSvGGGBfm7ifFCR1LrtEcNKjMwf7YEWZO0Vk3ZyhVq+k7JNLEbKv0O fBz8DU8GiGU+j88QlrgGW8PLkwNk7nsS/DJp8aLudTuVqIE2CA9mqn5QjU/EZYNHGzSfCr+/usUm bojyVSJukhhrAXspRAMz+Cia3yi3q3w8TnAljXWN1dhx1iuUv5GxyzMjfqK1tMuCUU2XzGNNqoVa 1mqolBiyDTCOr9d/IC0YHYMBSpQ+xi0x9zjXKt4FmQmkEAZgF4hsZZqcJYL/iCQiwiz8fEyVPZuv oWvdEXOozFYCpmkT0MZCJwyIux0Z6vJp6VLtN/6rZgc2y54HlTrp3ifazmpsfrk3NdHxlZTZug9k jEI+vEoyp/79nAPyTWQQ1MEP0ErCWav80/HOi0MLx/7lIUfvVOjkOFgFb+iDvR4T3RAQrnEpgTO+ fc7Jyzh9LpFDqm0slwDP4Hj9cC3IzdED5BU43PGAe+HoZ8OD/1ovVgwo/wIDAQABo4IBYzCCAV8w EAYJKwYBBAGCNxUBBAMCAQIwIwYJKwYBBAGCNxUCBBYEFFCiOtgZb+Zdflkw5sC2y01sUQaVMB0G A1UdDgQWBBRpZyAh1EjB0BsGbvMIKOI6gn1BMTAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRbh32f/my+Aunz4Ck6ilQl LJ84LzBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBv cmF0aW9uJTIwUEUlMjBSb290JTIwQ0EtMS5jcmwwWwYIKwYBBQUHAQEETzBNMEsGCCsGAQUFBzAC hj9odHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUlMjBSb290JTIw Q0EtMS5jcnQwDQYJKoZIhvcNAQELBQADggIBAHnDPfdYKxqNOtAYXMyyel83Vs8cCDAQZhSuIB0c 6GkGoEdFrmWH9pwi42V96rCp7TvbNNKNJXbVHfJUAp+uqw663DL/sXXff9ZFxPxKOdPnpA8cKM7R BH9e437Nw3d28A7PaGbP6tXmSqhXAhYZ4U12y1U5cOf2G/phUoAAMlnVJdfmXzMazvLo2SIeixAJ yCze6rHQTFQ/N+gAjbVuRJ+Hs8FEKVzMSwqlNoupe2ELqL4dMAKT6P08sAfxm2SrRlQvcWPYvqM/ 1C10bgc2tdu+WGzRuP5Wx9Yr15KO9SW4z7fn2RVEXQgoDDno5vCIcfUPuKB5n+Kt9eBCitsgSD9y YsNUN9LEVIvjAb8MV2LWLfge1bumo6g7QMRa4Fgifw5siGwi7V2EaJQo6UAIVvxKKFC7W4p6CkrY 2ga1d7GIQ0DPiWZOezOakJVAxL5gf+3WdNt0igKc/yLfbdHn6hCd1KPgDqkSKr8zWOZI/jiDBW95 7xAmaO6QdGQDBZrQHWpIVwQGzF5bGrqms2kq49l3t7KmBu0C/9tExqKAmlf4Y5lfQGdCbKQpAq71 2DVQHYuDXmVQEAc2vlJ1C5hS3Iw9DwBWTfJ4vyB48buhBhbIhPiFta5OizXlKcsIi99ikA1yiZx/ DBtjaw4JU6qJzWUFB2ecyGCNPtNbYjURA0A9MIIGhTCCBG2gAwIBAgIKNdD96gACAAAcdjANBgkq hkiG9w0BAQUFADBQMRMwEQYKCZImiZPyLGQBGRYDT1JHMRUwEwYKCZImiZPyLGQBGRYFTUlUUkUx IjAgBgNVBAMTGU1JVFJFIENvcnBvcmF0aW9uIFBFIENBLTEwHhcNMTIwMjA4MTgyNjM4WhcNMTUw MjA3MTgyNjM4WjBOMQswCQYDVQQGEwJVUzEOMAwGA1UEChMFTUlUUkUxDzANBgNVBAsTBlBlb3Bs ZTEeMBwGA1UEAxMVU2NobWlkdC5DaGFybGVzLjI1NjU4MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAorGFoUP/zIAgRw12Ip6aDMZvkFCAOAQaWFer+PdAqnFNTH1v758Y3SaoCVYV8A+l 4FQryRUFLooFo4iGAGIom2pJ+gOO0McZdIZV77mzpaKIGavG2ER4nNcR6Hmo/iN/SxxK8yCskq9/ gUU/M+OjsQlCihw/6eEDZLyMwH9ugtPbtlt64xKSXQMDAarayTWs6mnW52RQdHukS2Z2PknWnug2 fg1oujCHFhr7ozY8+ACo6A5efGv8mbHupUlKmldD0HImJXSPinWG7eNzhIYG1/TArbMIfngiImIf iHpJM+xUSWDd5Uj1d6BphpdKRjaqr45xpTrdA4epQNj2WP8v7QIDAQABo4ICYTCCAl0wEwYDVR0l BAwwCgYIKwYBBQUHAwQwgZQGCSqGSIb3DQEJDwSBhjCBgzAOBggqhkiG9w0DAgICAIAwDgYIKoZI hvcNAwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAS0w CwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBGTALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEFMB0GA1Ud DgQWBBQoJcp1KJQWbg6AC0wyjvYg3JaECDAOBgNVHQ8BAf8EBAMCBSAwHgYDVR0RBBcwFYETY21z Y2htaWR0QG1pdHJlLm9yZzAfBgNVHSMEGDAWgBRpZyAh1EjB0BsGbvMIKOI6gn1BMTBJBgNVHR8E QjBAMD6gPKA6hjhodHRwOi8vcGtpLm1pdHJlLm9yZy9NSVRSRSUyMENvcnBvcmF0aW9uJTIwUEUl MjBDQS0xLmNybDB/BggrBgEFBQcBAQRzMHEwRwYIKwYBBQUHMAKGO2h0dHA6Ly9wa2kubWl0cmUu b3JnL01JVFJFJTIwQ29ycG9yYXRpb24lMjBQRSUyMENBLTEoMikuY3J0MCYGCCsGAQUFBzABhhpo dHRwOi8vb2NzcC5taXRyZS5vcmcvb2NzcDA+BgkrBgEEAYI3FQcEMTAvBicrBgEEAYI3FQiDrqwj ho6WV4GNiT2CpKsShb6uAYE2hquSaISo7EUCAWQCAQ8wFgYDVR0gBA8wDTALBgkrBgEEAXMCAQgw GwYJKwYBBAGCNxUKBA4wDDAKBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAHKX0H9OV/dwo Z9iKg2gM3SWDeGQ2fxCS3LW4Bp865NB2wlv8CP74O1xfFXIWqrKtqJZKStZ3D516vwhe6hP9AllS qyoAc6m7gqrpZlcbwyurBXXFhvZ3ZpEyasgyFhVSPqCIn4IOeAeHZSiMIh/rIUspSVW/DsYhpNpd CoiL3R3br1oAfJ+ijTxtTFvo/LLp/xnNONtpObqQylxO0HIU/3boqmFWy+w5P/GooxPwfwczLjks Cdo8RSUh/qZmYOaSRQPlgLMkqIrYwa2TGVWm00K2uIs7V5r3qlulobOccKjM649dORGnJnwCygsd zUbFutDHYSPEpmfY7Bj0oZo2qsJNstpAPqXSX4WvjVroYtV6P2fJ0PsYiTWwQtzBg9gQJfVUSVi6 MvExmrGJLI5kHUtuFGxkyq4arl2nvTGsi6D+75qXktGXaMHC2pPoUa2NXkJ2ogDw/7QPF60DuHJ3 RZ1XYebDKV/JURT6feN5LJvqxxd0KhvEyPZaxPZlkXvbToRWMGUthfYkhaZMvO7TV0nU4+gEjyWG z2AVh9G7nf5D+w/KlQSHrMCxGbwAVgUUIzcQhpD061hCYHisOpsyW/Th0lFgFFcFZeanVsyaLHkq 6cwnCQyPAdBqsKpArS11BP5zt36v7m8M/bm/OYPgNnqNXMU7PqRFVvbXRWV/qlsxggMjMIIDHwIB ATBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTATBgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UE AxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIKNdD67QACAAAcdTAJBgUrDgMCGgUAoIIBmjAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEwMDMxNjM2MjVaMCMG CSqGSIb3DQEJBDEWBBSPFKbAka3TwuYWzPqu8sWH2b2LWTBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDAHBgUrDgMCGjBtBgkrBgEEAYI3EAQxYDBeMFAxEzARBgoJkiaJk/IsZAEZFgNPUkcxFTAT BgoJkiaJk/IsZAEZFgVNSVRSRTEiMCAGA1UEAxMZTUlUUkUgQ29ycG9yYXRpb24gUEUgQ0EtMQIK NdD96gACAAAcdjBvBgsqhkiG9w0BCRACCzFgoF4wUDETMBEGCgmSJomT8ixkARkWA09SRzEVMBMG CgmSJomT8ixkARkWBU1JVFJFMSIwIAYDVQQDExlNSVRSRSBDb3Jwb3JhdGlvbiBQRSBDQS0xAgo1 0P3qAAIAABx2MA0GCSqGSIb3DQEBAQUABIIBACDGPsy+iq7IDo6XJZ54/j408rlJV4+VH7kkZdht DZlhIULs+yteCMBfK/I1vFDlmq/P7vg/qP/275+LUMNQP+kOkLWjcv4Tq9aIzIgcTjkfScfdddaR hSBsw4e06W17eUZSWz94OR1PA8mvJsF3Y/jPqz3nrzwubWIsgQ8rq9vqK1/s6W9UA9pygVCzsk+/ ERsoKAhxQ1sWBImJZ6n8kqW1Nw23SrYhJz8PXjlXyw5xHHEoi/zg+Aupb5Pjz60V+kJTHioFFCoG YwEWMI64MocTMHusdN8U2b9AZypj10IRMFKMfJAmmHkqEdjYMOrlaGfR+/8Vr6vrUD2QWxrNWnUA AAAAAAA= ------=_NextPart_000_0111_01CDA15B.5225B070-- From dromasca@avaya.com Wed Oct 3 10:36:42 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F46421F85A1 for ; Wed, 3 Oct 2012 10:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.294 X-Spam-Level: X-Spam-Status: No, score=-103.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbdWT2Yh36MN for ; Wed, 3 Oct 2012 10:36:42 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id E14D721F852B for ; Wed, 3 Oct 2012 10:36:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAJALJ2bFCHCzI1/2dsb2JhbABFuy2BPngEgQ+BCIIiAQEDEh4KMSABFRUGDAwHVwEEGxqHY5YthCWcfYtagmOCQGADm22KJ4Jv X-IronPort-AV: E=Sophos;i="4.80,529,1344225600"; d="scan'208";a="327179123" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Oct 2012 13:30:58 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Oct 2012 13:14:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Oct 2012 19:36:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: preparing for the BOF in Atlanta Thread-Index: Ac2hjaPqcqQgGdTjTfWSQKcqwHZC/A== From: "Romascanu, Dan (Dan)" To: Subject: [sacm] preparing for the BOF in Atlanta X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 17:36:42 -0000 Hi,=20 I am the other BOF chair, the one who is not Kathleen. As some of you know I was an OPS AD for a while, and although I am not a SACM expert I am a fast and enthusiastic learner. I am here to help runing a successful BOF, and I will welcome all the help I can get.=20 We have only a few weeks left until the Atlanta IETF. We need a focused effort to create the material and put together the information that will help the IESG decide whether there is enough interest, expertise, active contributors and implementers that will allow for the creation of a new WG, or what further actions need to be undertaken until such a decision can be reached.=20 >From Sean's message speaking as shepherding AD I understand that he expects contributions that will help focus the work, explain what's proposed for the IETF and what's not, what are the proposed entities to support sacm, how proposals relate to already published work in this space.=20 To remind everybody, the important meeting dates for I-D submissions are:=20 *2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00 *2012-10-22 (Monday): Internet Draft final submission cut-off by UTC 24:00 We strongly prefer that all agenda slots that will be used at the BOF be based upon I-Ds.=20 Let us get to work.=20 Regards, Dan From johnp.field@emc.com Wed Oct 3 12:58:32 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86BE11E80BF; Wed, 3 Oct 2012 12:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytfNG3VRw3SP; Wed, 3 Oct 2012 12:58:31 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id AA79611E80AE; Wed, 3 Oct 2012 12:58:31 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q93JwO0b026743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 15:58:28 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 3 Oct 2012 15:58:17 -0400 Received: from mxhub20.corp.emc.com (mxhub20.corp.emc.com [10.254.93.49]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q93JwBDV001943; Wed, 3 Oct 2012 15:58:11 -0400 Received: from mx14a.corp.emc.com ([169.254.1.172]) by mxhub20.corp.emc.com ([10.254.93.49]) with mapi; Wed, 3 Oct 2012 15:58:10 -0400 From: "Field, John" To: Luis Nunez Date: Wed, 3 Oct 2012 15:58:09 -0400 Thread-Topic: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt Thread-Index: Ac2MRtb5CUom2+9vTeiOHaLaHD6oZAVV2OZw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "mile@ietf.org" , "sacm@ietf.org" Subject: Re: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 19:58:32 -0000 Luis, Sorry for the delay in responding, I have been quite busy with a few projec= ts and also traveling. Thanks for the feedback; scaprepo does look interes= ting... =20 I can easily imagine an integration where the representation of an "inciden= t" or "indicator" resource could also include a link to a corresponding SCA= P repository resource, say an OVAL benchmark or an OVAL def, etc. that is r= elated to the requested resource...a quick hack of an example might look so= mething like... HTTP/1.1 200 OK Date: Wed, 03 Oct 2012 17:30:11 GMT Content-Length: nnn Content-Type: application/atom+xml;type=3Dentry;charset=3D"utf-8" =20 http://www.example.org/csirt/private/incidents/123456 Sample Incident 2012-08-04T18:13:51.0Z 2012-08-05T18:13:51.0Z =20 =20 ... =20 =20 The possibility of such an integration is exactly what motivated the draft.= The issues that would need to be resolved include making the authenticatio= n to the scaprepo seamless (possible, at least in principal, using existing= Web Single Sign On protocols) and dealing with differences in interaction = style...for example, I notice that scaprepo seems to prefer the use of POST= for all operations (including a read operation). As a general rule, it is= best to support GET for read operations, and reserve POST for write operat= ions. But, this is a relatively minor issue at this point. The more impor= tant point is that by using a REST approach such an integration would becom= e possible, and that would be of benefit to users dealing with indicators, = incident response, and assessment and compliance, etc....we could tie it al= l together quite nicely. Thanks for commenting. I'll take a deeper look at scaprepo when I get some= more time. Regards, John -----Original Message----- From: Luis Nunez [mailto:lnunez@c3isecurity.com]=20 Sent: Thursday, September 06, 2012 11:36 AM To: Field, John Cc: sacm@ietf.org; mile@ietf.org Subject: Re: [sacm] New draft for review and comment: draft-field-mile-roli= e-00.txt John, this definitely is of interest and could be related to past discussions aro= und content repositories. =20 I know of two publicly accessible (REST) repositories that could potential = host this type of content. http://scaprepo.com/SCAPRepoWebService http://scapsync.com/api/ NIST is also working on a repository with webservices. It would be interesting to prototype a sample document and flesh out issues= . -ln On Sep 6, 2012, at 11:10 AM, Field, John wrote: > All, >=20 > Cross posting this announcement from MILE to SACM, as I think this may be= of interest within the SCAP community as well. =20 >=20 > The new draft referenced below describes a RESTful HTTP binding for shari= ng incident, indicator, and other cyber security-related information. In p= articular, the draft includes a suggested approach to retrieving a related = benchmark resource. =20 >=20 > I hope you'll find this draft to be of interest. =20 >=20 > Please post any questions or comments to the MILE list. >=20 > Regards, > John >=20 > // John P. Field=20 > // Security Architect=20 > // EMC Office of the CTO=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Field, John=20 > Sent: Thursday, September 06, 2012 10:53 AM > To: > Subject: New draft for review and comment: draft-field-mile-rolie-00.txt >=20 > All, >=20 > Please note that I have just posted a new draft for review and comment. = As stated in the abstract, the draft describes a RESTful HTTP binding for s= haring incident, indicator, and other cyber security-related information. = I hope you'll find this document to be of interest, and I look forward to d= iscussing any questions and/or comments that the group may have. >=20 > Regards, > John >=20 > // John P. Field=20 > // Security Architect=20 > // EMC Office of the CTO=20 >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Wednesday, September 05, 2012 9:59 PM > To: Field, John > Subject: New Version Notification for draft-field-mile-rolie-00.txt >=20 >=20 > A new version of I-D, draft-field-mile-rolie-00.txt > has been successfully submitted by John P. Field and posted to the > IETF repository. >=20 > Filename: draft-field-mile-rolie > Revision: 00 > Title: Resource-Oriented Lightweight Indicator Exchange > Creation date: 2012-09-05 > WG ID: Individual Submission > Number of pages: 41 > URL: http://www.ietf.org/internet-drafts/draft-field-mile-rol= ie-00.txt > Status: http://datatracker.ietf.org/doc/draft-field-mile-rolie > Htmlized: http://tools.ietf.org/html/draft-field-mile-rolie-00 >=20 >=20 > Abstract: > This document defines a resource-oriented approach to cyber security > information sharing. Using this approach, a CSIRT or other > stakeholder may share and exchange representations of cyber security > incidents, indicators, and other related information as Web- > addressable resources. The transport protocol binding is specified > as HTTP(S) with a MIME media type of Atom+XML. An appropriate set of > link relation types specific to cyber security information sharing is > defined. The resource representations leverage the existing IODEF > [RFC5070] and RID [RFC6545] specifications as appropriate. > Coexistence with deployments that conform to existing specifications > including RID [RFC6545] and Transport of Real-time Inter-network > Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via > appropriate use of HTTP status codes. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Wed Oct 3 13:11:45 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371AD21F8518 for ; Wed, 3 Oct 2012 13:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2so9liVEoy7B for ; Wed, 3 Oct 2012 13:11:40 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 33D4D21F851E for ; Wed, 3 Oct 2012 13:11:40 -0700 (PDT) Received: from mail218-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 3 Oct 2012 20:11:39 +0000 Received: from mail218-tx2 (localhost [127.0.0.1]) by mail218-tx2-R.bigfish.com (Postfix) with ESMTP id 4845140263 for ; Wed, 3 Oct 2012 20:11:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz98dI9371I936eI1432Izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839h944hd25he5bhf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received: from mail218-tx2 (localhost.localdomain [127.0.0.1]) by mail218-tx2 (MessageSwitch) id 1349295097300273_16815; Wed, 3 Oct 2012 20:11:37 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.246]) by mail218-tx2.bigfish.com (Postfix) with ESMTP id 34E74940043 for ; Wed, 3 Oct 2012 20:11:37 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 3 Oct 2012 20:11:35 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 777292321242 for ; Wed, 3 Oct 2012 13:05:50 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id D5EBC23211ED; Wed, 3 Oct 2012 13:05:49 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Wed, 3 Oct 2012 13:14:32 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Wed, 3 Oct 2012 13:11:33 -0700 From: Adam Montville To: "Romascanu, Dan (Dan)" Thread-Topic: [sacm] preparing for the BOF in Atlanta Thread-Index: AQHNoaNIpbEkmGGrVUSnCmQ0aPXIyQ== Date: Wed, 3 Oct 2012 20:11:32 +0000 Message-ID: <8766BAFC-D8B7-489D-9D22-3B24EA1AF33D@tripwire.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VPM-MSG-ID: 88f286e1-a426-41fd-825b-594b82453d93 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Cc: "sacm@ietf.org" Subject: Re: [sacm] preparing for the BOF in Atlanta X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:11:45 -0000 On Oct 3, 2012, at 1:36 PM, "Romascanu, Dan (Dan)" wro= te: > Hi,=20 >=20 Hi, Dan. Welcome! > I am the other BOF chair, the one who is not Kathleen. As some of you > know I was an OPS AD for a while, and although I am not a SACM expert I > am a fast and enthusiastic learner. I am here to help runing a > successful BOF, and I will welcome all the help I can get.=20 >=20 > We have only a few weeks left until the Atlanta IETF. We need a focused > effort to create the material and put together the information that will > help the IESG decide whether there is enough interest, expertise, active > contributors and implementers that will allow for the creation of a new > WG, or what further actions need to be undertaken until such a decision > can be reached.=20 >=20 Are you up to date with what has transpired on the list so far? We have a = proposed charter, draft use case document, draft Asset Identification docum= ent, and a draft Asset Summary Reporting document. The use cases need some= additional work, I think, and I'm sure there are comments on the AI and AS= R documents, though I have yet to see any come across this list. > From Sean's message speaking as shepherding AD I understand that he > expects contributions that will help focus the work, explain what's > proposed for the IETF and what's not, what are the proposed entities to > support sacm, how proposals relate to already published work in this > space.=20 >=20 > To remind everybody, the important meeting dates for I-D submissions > are:=20 >=20 > *2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00) > submission by UTC 24:00 > *2012-10-22 (Monday): Internet Draft final submission cut-off by UTC > 24:00 >=20 > We strongly prefer that all agenda slots that will be used at the BOF be > based upon I-Ds.=20 What are the agenda slots that are taken, but do not yet have an associated= I-D? >=20 > Let us get to work.=20 >=20 > Regards, >=20 > Dan >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From dromasca@avaya.com Thu Oct 4 02:00:03 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1103421F85E6 for ; Thu, 4 Oct 2012 02:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.292 X-Spam-Level: X-Spam-Status: No, score=-103.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gd2cvXIHIi11 for ; Thu, 4 Oct 2012 02:00:02 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA7621F85FC for ; Thu, 4 Oct 2012 02:00:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAJObVCHCzI1/2dsb2JhbABFvwuBCIIgAQEBAQIBEh4KPwwEAgEIDQEHAQwGDAsBBgFFEQIEEwgah10Gm1+dDosjhTxgA5ttiieCbw X-IronPort-AV: E=Sophos;i="4.80,534,1344225600"; d="scan'208";a="370030723" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 Oct 2012 04:54:15 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 04 Oct 2012 04:38:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Oct 2012 10:59:59 +0200 Message-ID: In-Reply-To: <8766BAFC-D8B7-489D-9D22-3B24EA1AF33D@tripwire.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sacm] preparing for the BOF in Atlanta Thread-Index: AQHNoaNIpbEkmGGrVUSnCmQ0aPXIyZeo15sA References: <8766BAFC-D8B7-489D-9D22-3B24EA1AF33D@tripwire.com> From: "Romascanu, Dan (Dan)" To: "Adam Montville" Cc: sacm@ietf.org Subject: Re: [sacm] preparing for the BOF in Atlanta X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 09:00:03 -0000 Hi Adam,=20 See in-line.=20 Regards, Dan > -----Original Message----- > From: Adam Montville [mailto:amontville@tripwire.com] > Sent: Wednesday, October 03, 2012 10:12 PM ... >=20 >=20 > Are you up to date with what has transpired on the list so far? We have > a proposed charter, draft use case document, draft Asset Identification > document, and a draft Asset Summary Reporting document. The use cases > need some additional work, I think, and I'm sure there are comments on > the AI and ASR documents, though I have yet to see any come across this > list. >=20 >=20 [[DR]] Yes, I have read the I-Ds, and part of the discussions on the list. I have my own questions and comments, and I would invite everybody to send their own comments to the list.=20 >=20 >=20 > > From Sean's message speaking as shepherding AD I understand that he > > expects contributions that will help focus the work, explain what's > > proposed for the IETF and what's not, what are the proposed entities > to > > support sacm, how proposals relate to already published work in this > > space. > > > > To remind everybody, the important meeting dates for I-D submissions > > are: > > > > *2012-10-15 (Monday): Internet Draft Cut-off for initial document (- > 00) > > submission by UTC 24:00 > > *2012-10-22 (Monday): Internet Draft final submission cut-off by UTC > > 24:00 > > > > We strongly prefer that all agenda slots that will be used at the BOF > be > > based upon I-Ds. >=20 >=20 > What are the agenda slots that are taken, but do not yet have an > associated I-D? >=20 [[DR]] The proposed phase one in the charter includes much more items than the material covered by now in the I-Ds. Of course, not all these items need to be discussed at the BOF, but it's better that by the time we propose items for the charter the thinking and original directions are already documented in I-Ds.=20 From lnunez@c3isecurity.com Thu Oct 4 04:06:50 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0506921F865B for ; Thu, 4 Oct 2012 04:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOd3NWenq8zq for ; Thu, 4 Oct 2012 04:06:48 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9531021F8647 for ; Thu, 4 Oct 2012 04:06:48 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id c10so313382qca.31 for ; Thu, 04 Oct 2012 04:06:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=x4+S97Evw9DeEKAuerbuR0r63Cl1kCBXHdfe/4Cta9w=; b=aAqPwljNVFPFvswutkbsHHxb+Tb9FHKhOioyRQ816OJnrMdk/4Hed9t7kIDHwWVQVz PuLHXIyEz+JSURAdzm0uUtX4zIHHVXDVaBmyH97dtalU9Nl6GSalvWQLwr8p4I1Y+ZRK XGTUs+Mc2eK2zU+ZJjrivf1oILByelN3dGEkG5Db8uXpN+5adYhw7j1Kw1GwOLikax3/ PBTrE2ruPqyJrFRjybpz5To9OFqbECqENstjqQdcR9tRXMY7olQ/j16g40xMv8J/AAE0 EP7dfbErHmphxovSEEIcknArYsZI9HxkcVdM+KGGJ34de2BJdws3UX4SM5cq602jyaOW XK2g== Received: by 10.49.72.199 with SMTP id f7mr18079162qev.43.1349348807853; Thu, 04 Oct 2012 04:06:47 -0700 (PDT) Received: from [10.71.77.129] ([74.10.226.222]) by mx.google.com with ESMTPS id ep8sm6917750qab.22.2012.10.04.04.06.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Oct 2012 04:06:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Luis Nunez In-Reply-To: Date: Thu, 4 Oct 2012 07:06:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Field, John" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnvvJnK9vIgxePstdOUK4Q2zXLK4AD/Nkv5iaVHkkUw0+z3fM65J2pyBFzuB81g4S/zlFS5 Cc: "mile@ietf.org" , "sacm@ietf.org" Subject: Re: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 11:06:50 -0000 I agree with your motivation. This great timing to publish such draft. = I am at the ITSAC this week talking to folks about possibility = prototyping this specification into repositories such as scaprepo.com = and also scapsync.com. =20 I think once we have a live prototype we can also address authentication = and entitlement capabilities. Entitlements to public and private = content I think will help in opening up further access into content = repositories.=20 thanks. -ln On Oct 3, 2012, at 3:58 PM, Field, John wrote: > Luis, >=20 > Sorry for the delay in responding, I have been quite busy with a few = projects and also traveling. Thanks for the feedback; scaprepo does = look interesting... =20 >=20 > I can easily imagine an integration where the representation of an = "incident" or "indicator" resource could also include a link to a = corresponding SCAP repository resource, say an OVAL benchmark or an OVAL = def, etc. that is related to the requested resource...a quick hack of an = example might look something like... >=20 > HTTP/1.1 200 OK > Date: Wed, 03 Oct 2012 17:30:11 GMT > Content-Length: nnn > Content-Type: application/atom+xml;type=3Dentry;charset=3D"utf-8" >=20 > =20 > > http://www.example.org/csirt/private/incidents/123456 > Sample Incident > > > 2012-08-04T18:13:51.0Z > 2012-08-05T18:13:51.0Z >=20 > > > >=20 > > >=20 > > > > ... =20 > > > >=20 >=20 > The possibility of such an integration is exactly what motivated the = draft. The issues that would need to be resolved include making the = authentication to the scaprepo seamless (possible, at least in = principal, using existing Web Single Sign On protocols) and dealing with = differences in interaction style...for example, I notice that scaprepo = seems to prefer the use of POST for all operations (including a read = operation). As a general rule, it is best to support GET for read = operations, and reserve POST for write operations. But, this is a = relatively minor issue at this point. The more important point is that = by using a REST approach such an integration would become possible, and = that would be of benefit to users dealing with indicators, incident = response, and assessment and compliance, etc....we could tie it all = together quite nicely. >=20 > Thanks for commenting. I'll take a deeper look at scaprepo when I get = some more time. >=20 > Regards, > John >=20 >=20 > -----Original Message----- > From: Luis Nunez [mailto:lnunez@c3isecurity.com]=20 > Sent: Thursday, September 06, 2012 11:36 AM > To: Field, John > Cc: sacm@ietf.org; mile@ietf.org > Subject: Re: [sacm] New draft for review and comment: = draft-field-mile-rolie-00.txt >=20 > John, > this definitely is of interest and could be related to past = discussions around content repositories. =20 >=20 > I know of two publicly accessible (REST) repositories that could = potential host this type of content. >=20 > http://scaprepo.com/SCAPRepoWebService > http://scapsync.com/api/ >=20 > NIST is also working on a repository with webservices. >=20 > It would be interesting to prototype a sample document and flesh out = issues. >=20 >=20 > -ln >=20 > On Sep 6, 2012, at 11:10 AM, Field, John wrote: >=20 >> All, >>=20 >> Cross posting this announcement from MILE to SACM, as I think this = may be of interest within the SCAP community as well. =20 >>=20 >> The new draft referenced below describes a RESTful HTTP binding for = sharing incident, indicator, and other cyber security-related = information. In particular, the draft includes a suggested approach to = retrieving a related benchmark resource. =20 >>=20 >> I hope you'll find this draft to be of interest. =20 >>=20 >> Please post any questions or comments to the MILE list. >>=20 >> Regards, >> John >>=20 >> // John P. Field=20 >> // Security Architect=20 >> // EMC Office of the CTO=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Field, John=20 >> Sent: Thursday, September 06, 2012 10:53 AM >> To: >> Subject: New draft for review and comment: = draft-field-mile-rolie-00.txt >>=20 >> All, >>=20 >> Please note that I have just posted a new draft for review and = comment. As stated in the abstract, the draft describes a RESTful HTTP = binding for sharing incident, indicator, and other cyber = security-related information. I hope you'll find this document to be of = interest, and I look forward to discussing any questions and/or comments = that the group may have. >>=20 >> Regards, >> John >>=20 >> // John P. Field=20 >> // Security Architect=20 >> // EMC Office of the CTO=20 >>=20 >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 >> Sent: Wednesday, September 05, 2012 9:59 PM >> To: Field, John >> Subject: New Version Notification for draft-field-mile-rolie-00.txt >>=20 >>=20 >> A new version of I-D, draft-field-mile-rolie-00.txt >> has been successfully submitted by John P. Field and posted to the >> IETF repository. >>=20 >> Filename: draft-field-mile-rolie >> Revision: 00 >> Title: Resource-Oriented Lightweight Indicator = Exchange >> Creation date: 2012-09-05 >> WG ID: Individual Submission >> Number of pages: 41 >> URL: = http://www.ietf.org/internet-drafts/draft-field-mile-rolie-00.txt >> Status: = http://datatracker.ietf.org/doc/draft-field-mile-rolie >> Htmlized: http://tools.ietf.org/html/draft-field-mile-rolie-00 >>=20 >>=20 >> Abstract: >> This document defines a resource-oriented approach to cyber security >> information sharing. Using this approach, a CSIRT or other >> stakeholder may share and exchange representations of cyber security >> incidents, indicators, and other related information as Web- >> addressable resources. The transport protocol binding is specified >> as HTTP(S) with a MIME media type of Atom+XML. An appropriate set = of >> link relation types specific to cyber security information sharing = is >> defined. The resource representations leverage the existing IODEF >> [RFC5070] and RID [RFC6545] specifications as appropriate. >> Coexistence with deployments that conform to existing specifications >> including RID [RFC6545] and Transport of Real-time Inter-network >> Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via >> appropriate use of HTTP status codes. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >> _______________________________________________ >> sacm mailing list >> sacm@ietf.org >> https://www.ietf.org/mailman/listinfo/sacm >=20 >=20 From bchandra@secpod.com Thu Oct 4 06:33:47 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8275B21F8648; Thu, 4 Oct 2012 06:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, SARE_OBFU_SPLIT_HR2=0.183] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rasjn+zynzSo; Thu, 4 Oct 2012 06:33:46 -0700 (PDT) Received: from cpanel23.interactivedns.com (cpanel23.interactivedns.com [184.173.122.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8598D21F8647; Thu, 4 Oct 2012 06:33:46 -0700 (PDT) Received: from [182.72.99.242] (port=2564 helo=hpPC) by cpanel23.interactivedns.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TJlYe-0002l4-Qo; Thu, 04 Oct 2012 19:03:45 +0530 From: "Chandrashekhar B" To: "'Field, John'" , "'Luis Nunez'" References: In-Reply-To: Date: Thu, 4 Oct 2012 19:03:38 +0530 Organization: SecPod Technologies Message-ID: <013e01cda234$def74ac0$9ce5e040$@secpod.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDkLRwduFPN/39ahIvZ01+DQBPpAF1d2SmAqBmgbiXHJXcYA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel23.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - secpod.com X-Source: X-Source-Args: X-Source-Dir: Cc: mile@ietf.org, sacm@ietf.org Subject: Re: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bchandra@secpod.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 13:33:47 -0000 Thanks John. Authentication was the primary reason for a POST request, we'll look into your suggestion. The example helped quickly grasp the idea. We'll look into the draft in detail and come back with any comments. There are three specs now which are somewhat related although each for different purposes, 1. SCAP Messages for IF-M draft - http://www.trustedcomputinggroup.org/resources/tnc_scap_messages_for_ifm 2. Resource-Oriented Lightweight Indicator Exchange - http://www.ietf.org/id/draft-field-mile-rolie-00.txt 3. Content Repository interface - http://tools.ietf.org/html/draft-waltermire-content-repository-00 I think all should align on a similar content exchange mechanism. Just a thought, am not sure if it really make sense, haven't gone through each of them in detail. Thanks, Chandra. -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Field, John Sent: Thursday, October 04, 2012 1:28 AM To: Luis Nunez Cc: mile@ietf.org; sacm@ietf.org Subject: Re: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt Luis, Sorry for the delay in responding, I have been quite busy with a few projects and also traveling. Thanks for the feedback; scaprepo does look interesting... I can easily imagine an integration where the representation of an "incident" or "indicator" resource could also include a link to a corresponding SCAP repository resource, say an OVAL benchmark or an OVAL def, etc. that is related to the requested resource...a quick hack of an example might look something like... HTTP/1.1 200 OK Date: Wed, 03 Oct 2012 17:30:11 GMT Content-Length: nnn Content-Type: application/atom+xml;type=entry;charset="utf-8" http://www.example.org/csirt/private/incidents/123456 Sample Incident 2012-08-04T18:13:51.0Z 2012-08-05T18:13:51.0Z ... The possibility of such an integration is exactly what motivated the draft. The issues that would need to be resolved include making the authentication to the scaprepo seamless (possible, at least in principal, using existing Web Single Sign On protocols) and dealing with differences in interaction style...for example, I notice that scaprepo seems to prefer the use of POST for all operations (including a read operation). As a general rule, it is best to support GET for read operations, and reserve POST for write operations. But, this is a relatively minor issue at this point. The more important point is that by using a REST approach such an integration would become possible, and that would be of benefit to users dealing with indicators, incident response, and assessment and compliance, etc....we could tie it all together quite nicely. Thanks for commenting. I'll take a deeper look at scaprepo when I get some more time. Regards, John -----Original Message----- From: Luis Nunez [mailto:lnunez@c3isecurity.com] Sent: Thursday, September 06, 2012 11:36 AM To: Field, John Cc: sacm@ietf.org; mile@ietf.org Subject: Re: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt John, this definitely is of interest and could be related to past discussions around content repositories. I know of two publicly accessible (REST) repositories that could potential host this type of content. http://scaprepo.com/SCAPRepoWebService http://scapsync.com/api/ NIST is also working on a repository with webservices. It would be interesting to prototype a sample document and flesh out issues. -ln On Sep 6, 2012, at 11:10 AM, Field, John wrote: > All, > > Cross posting this announcement from MILE to SACM, as I think this may be of interest within the SCAP community as well. > > The new draft referenced below describes a RESTful HTTP binding for sharing incident, indicator, and other cyber security-related information. In particular, the draft includes a suggested approach to retrieving a related benchmark resource. > > I hope you'll find this draft to be of interest. > > Please post any questions or comments to the MILE list. > > Regards, > John > > // John P. Field > // Security Architect > // EMC Office of the CTO > > > > > > -----Original Message----- > From: Field, John > Sent: Thursday, September 06, 2012 10:53 AM > To: > Subject: New draft for review and comment: draft-field-mile-rolie-00.txt > > All, > > Please note that I have just posted a new draft for review and comment. As stated in the abstract, the draft describes a RESTful HTTP binding for sharing incident, indicator, and other cyber security-related information. I hope you'll find this document to be of interest, and I look forward to discussing any questions and/or comments that the group may have. > > Regards, > John > > // John P. Field > // Security Architect > // EMC Office of the CTO > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, September 05, 2012 9:59 PM > To: Field, John > Subject: New Version Notification for draft-field-mile-rolie-00.txt > > > A new version of I-D, draft-field-mile-rolie-00.txt > has been successfully submitted by John P. Field and posted to the > IETF repository. > > Filename: draft-field-mile-rolie > Revision: 00 > Title: Resource-Oriented Lightweight Indicator Exchange > Creation date: 2012-09-05 > WG ID: Individual Submission > Number of pages: 41 > URL: http://www.ietf.org/internet-drafts/draft-field-mile-rolie-00.txt > Status: http://datatracker.ietf.org/doc/draft-field-mile-rolie > Htmlized: http://tools.ietf.org/html/draft-field-mile-rolie-00 > > > Abstract: > This document defines a resource-oriented approach to cyber security > information sharing. Using this approach, a CSIRT or other > stakeholder may share and exchange representations of cyber security > incidents, indicators, and other related information as Web- > addressable resources. The transport protocol binding is specified > as HTTP(S) with a MIME media type of Atom+XML. An appropriate set of > link relation types specific to cyber security information sharing is > defined. The resource representations leverage the existing IODEF > [RFC5070] and RID [RFC6545] specifications as appropriate. > Coexistence with deployments that conform to existing specifications > including RID [RFC6545] and Transport of Real-time Inter-network > Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via > appropriate use of HTTP status codes. > > > > > The IETF Secretariat > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From kathleen.moriarty@emc.com Thu Oct 11 11:53:20 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786B121F8643 for ; Thu, 11 Oct 2012 11:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jB0G57ntf4ib for ; Thu, 11 Oct 2012 11:53:19 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFE021F865E for ; Thu, 11 Oct 2012 11:53:19 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9BIrGup007933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Oct 2012 14:53:17 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Thu, 11 Oct 2012 14:53:06 -0400 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9BIr4Mp003028 for ; Thu, 11 Oct 2012 14:53:05 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Thu, 11 Oct 2012 14:53:04 -0400 From: "Moriarty, Kathleen" To: "sacm@ietf.org" Date: Thu, 11 Oct 2012 14:53:03 -0400 Thread-Topic: SACM BoF Agenda and *requests for presentation slots* Thread-Index: Ac2n4aSZr20xfqQGRaGM/+FhqHwFGQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F2409595612MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [sacm] SACM BoF Agenda and *requests for presentation slots* X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 18:53:20 -0000 --_000_F5063677821E3B4F81ACFB7905573F2409595612MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Dan and I would like to organize the agenda with the list members to ensure= those planning to present have a chance to request a time slot and submit = the supporting draft for that slot prior to the October 15th deadline for -= 00 drafts. The high-level agenda is as follows: Discussion on Use Cases Presentations on drafts to support Use cases ** Please request a time slot and ensure a draft is submitted to support t= he presentation ** Tough Questions Charter Review Important Dates Reminder: -00 Drafts: Oct 15, 2012 -01 and higher: Oct 22, 2012 Full list of important dates: https://www.ietf.org/meeting/cutoff-dates-2012.html#IETF85 The cut off dates are important to ensure participates have enough time to = review the materials in preparation for the meeting. This enables useful d= iscussions to progress the work items. Thank you in advance for your work on supporting drafts! Best regards, Kathleen --_000_F5063677821E3B4F81ACFB7905573F2409595612MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
Dan and I would like to organize the agenda with the list members to e= nsure those planning to present have a chance to request a time slot and su= bmit the supporting draft for that slot prior to the October 15th deadline for -00 drafts. 
 
The high-level agenda is as follows:
 
Discussion on Use Cases
Presentations on drafts to support Use cases
** Please request a time slot and ensure a draft is submitted to supp= ort the presentation **
Tough Questions
Charter Review
 
 
Important Dates Reminder:
-00 Drafts: Oct 15, 2012
-01 and higher: Oct 22, 2012
Full list of important dates:
 
The cut off dates are important to ensure participates have enough tim= e to review the materials in preparation for the meeting.  This enable= s useful discussions to progress the work items. 
 
Thank you in advance for your work on supporting drafts!
 
Best regards,
Kathleen
 
 --_000_F5063677821E3B4F81ACFB7905573F2409595612MX15Acorpemccom_-- From amontville@tripwire.com Fri Oct 12 11:26:00 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2564B21F87C9 for ; Fri, 12 Oct 2012 11:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.772 X-Spam-Level: X-Spam-Status: No, score=-3.772 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXt2lLj-BpTZ for ; Fri, 12 Oct 2012 11:25:59 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1C60621F87C8 for ; Fri, 12 Oct 2012 11:25:59 -0700 (PDT) Received: from mail210-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Fri, 12 Oct 2012 18:25:58 +0000 Received: from mail210-va3 (localhost [127.0.0.1]) by mail210-va3-R.bigfish.com (Postfix) with ESMTP id 250875800E0 for ; Fri, 12 Oct 2012 18:25:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371Ic85fhc540Kzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839he5bhf0ah107ah1288h12a5h12bdh137ah1441hbe3k1155h) Received: from mail210-va3 (localhost.localdomain [127.0.0.1]) by mail210-va3 (MessageSwitch) id 1350066355870046_22271; Fri, 12 Oct 2012 18:25:55 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.239]) by mail210-va3.bigfish.com (Postfix) with ESMTP id D29CFB40044 for ; Fri, 12 Oct 2012 18:25:55 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 12 Oct 2012 18:25:55 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id A4B5D2321249 for ; Fri, 12 Oct 2012 11:19:25 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 0CBDC23211E3; Fri, 12 Oct 2012 11:19:25 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Fri, 12 Oct 2012 11:29:41 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Fri, 12 Oct 2012 11:25:53 -0700 From: Adam Montville To: "Moriarty, Kathleen" , "sacm@ietf.org" Thread-Topic: [sacm] SACM BoF Agenda and *requests for presentation slots* Thread-Index: Ac2n4aSZr20xfqQGRaGM/+FhqHwFGQAxV1mA Date: Fri, 12 Oct 2012 18:25:52 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_CC9DA8515442amontvilletripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 10c0ba6f-0701-44e0-bfda-74d18c41ee91 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] SACM BoF Agenda and *requests for presentation slots* X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 18:26:00 -0000 --_000_CC9DA8515442amontvilletripwirecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Dave Waltermire and/or I would like the opportunity to present the use case= draft [1]. Time required: 45 minutes. I would expect most of this time t= o be open for discussion. I would additionally like to present the Asset Identification draft [2]. T= ime required: 30 minutes. As a note, all I intend to do with this is empha= size that I simply transformed the AI 1.1 specification from PDF to RFC and= present a list of potential improvements. Again, I would expect most of t= his time to be open for discussion. Regards, Adam [1] http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02 [2] http://tools.ietf.org/html/draft-montville-sacm-asset-identification-00 From: , "kathleen.moriarty@emc.com" > Date: Thursday, October 11, 2012 11:53 AM To: "sacm@ietf.org" > Subject: [sacm] SACM BoF Agenda and *requests for presentation slots* Hello, Dan and I would like to organize the agenda with the list members to ensure= those planning to present have a chance to request a time slot and submit = the supporting draft for that slot prior to the October 15th deadline for -= 00 drafts. The high-level agenda is as follows: Discussion on Use Cases Presentations on drafts to support Use cases ** Please request a time slot and ensure a draft is submitted to support th= e presentation ** Tough Questions Charter Review Important Dates Reminder: -00 Drafts: Oct 15, 2012 -01 and higher: Oct 22, 2012 Full list of important dates: https://www.ietf.org/meeting/cutoff-dates-2012.html#IETF85 The cut off dates are important to ensure participates have enough time to = review the materials in preparation for the meeting. This enables useful d= iscussions to progress the work items. Thank you in advance for your work on supporting drafts! Best regards, Kathleen --_000_CC9DA8515442amontvilletripwirecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8A7DCAA4507F9D469299CB9BB217ECC9@tripwire.com> Content-Transfer-Encoding: quoted-printable
Hello,

Dave Waltermire and/or I would like the opportunity to present the use= case draft [1].  Time required: 45 minutes.  I would expect most= of this time to be open for discussion.

I would additionally like to present the Asset Identification draft [2= ].  Time required: 30 minutes.  As a note, all I intend to do wit= h this is emphasize that I simply transformed the AI 1.1 specification from= PDF to RFC and present a list of potential improvements.  Again, I would expect most of this time to be open for= discussion.

Regards,

Adam

From: <Moriarty>, "kathleen.moriarty@emc.com"= <kathleen.moriarty@emc.com= >
Date: Thursday, October 11, 2012 11= :53 AM
To: "sacm@ietf.org" <sacm@i= etf.org>
Subject: [sacm] SACM BoF Agenda and= *requests for presentation slots*

Hello,
 
Dan and I would like to organize the agenda with the list members to e= nsure those planning to present have a chance to request a time slot and su= bmit the supporting draft for that slot prior to the October 15th deadline for -00 drafts. 
 
The high-level agenda is as follows:
 
Discussion on Use Cases
Presentations on drafts to support Use cases
** Please request a time slot and ensure a draft is submitted to suppo= rt the presentation **
Tough Questions
Charter Review
 
 
Important Dates Reminder:
-00 Drafts: Oct 15, 2012
-01 and higher: Oct 22, 2012
Full list of important dates:
 
The cut off dates are important to ensure participates have enough tim= e to review the materials in preparation for the meeting.  This enable= s useful discussions to progress the work items. 
 
Thank you in advance for your work on supporting drafts!
 
Best regards,
Kathleen
 


--_000_CC9DA8515442amontvilletripwirecom_-- From shanna@juniper.net Mon Oct 15 12:10:08 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FD021F8822 for ; Mon, 15 Oct 2012 12:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVIIuGviz90A for ; Mon, 15 Oct 2012 12:10:07 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2A66B21F85E6 for ; Mon, 15 Oct 2012 12:10:07 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUHxfjn8qOwo58xvXSxYP15Wp5jWq6mF3@postini.com; Mon, 15 Oct 2012 12:10:07 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 15 Oct 2012 12:06:09 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 15 Oct 2012 12:06:08 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 15 Oct 2012 15:06:08 -0400 From: Stephen Hanna To: "sacm@ietf.org" Date: Mon, 15 Oct 2012 15:06:05 -0400 Thread-Topic: New Draft on Assessment Protocols Thread-Index: Ac2q/mGzMEMMihkARtCSiUUQcPZ5FQAAAi+g Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sacm] New Draft on Assessment Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 19:10:08 -0000 Folks, I have posted a new Internet-Draft that points out some existing protocols that address the call in the SACM BOF charter for the development of "continuous assessment interfaces". You may think that you know about all of these but I bet that you don't! I also included a suggested list of next steps in this area. The draft is only seven pages long and really only three pages of content so it's a quick read. Please look it over and comment on the list. The link is below. I'd like to request some time on the SACM BOF agenda to talk about the ideas and information included in this I-D. Such a discussion should really help us figure out how to make progress on this part of the project. Thanks, Steve -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Monday, October 15, 2012 1:56 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-hanna-sacm-assessment-protocols-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Standard Assessment Protocols and Formats for SACM Author(s) : Steve Hanna Filename : draft-hanna-sacm-assessment-protocols-00.txt Pages : 7 Date : 2012-10-15 Abstract: The draft charter for the SACM BOF at IETF 85 calls for the development of "continuous assessment interfaces". This draft points out several existing documents that provide a good start in this area. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hanna-sacm-assessment-protocols There's also a htmlized version available at: http://tools.ietf.org/html/draft-hanna-sacm-assessment-protocols-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From kathleen.moriarty@emc.com Mon Oct 15 12:32:18 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6D421F897F for ; Mon, 15 Oct 2012 12:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EIZN6SjRT1q for ; Mon, 15 Oct 2012 12:32:18 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3DE21F897D for ; Mon, 15 Oct 2012 12:32:17 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9FJWGsg015364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Oct 2012 15:32:16 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 15 Oct 2012 15:32:03 -0400 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9FJW1ae001982; Mon, 15 Oct 2012 15:32:02 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub36.corp.emc.com ([::1]) with mapi; Mon, 15 Oct 2012 15:32:02 -0400 From: "Moriarty, Kathleen" To: Stephen Hanna Date: Mon, 15 Oct 2012 15:31:53 -0400 Thread-Topic: [sacm] New Draft on Assessment Protocols Thread-Index: Ac2rC7+Ph4k7JblFT02fRKoU3FvmSQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "sacm@ietf.org" Subject: Re: [sacm] New Draft on Assessment Protocols X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 19:32:18 -0000 Thank you, Steve! If anyone else is planning to submit -00 draft, today is the deadline for t= he Atlanta meeting. Thanks, Kathleen Sent from my iPhone On Oct 15, 2012, at 3:10 PM, "Stephen Hanna" wrote: > Folks, >=20 > I have posted a new Internet-Draft that points out some existing > protocols that address the call in the SACM BOF charter for the > development of "continuous assessment interfaces". You may think > that you know about all of these but I bet that you don't! I also > included a suggested list of next steps in this area. The draft is > only seven pages long and really only three pages of content so > it's a quick read. Please look it over and comment on the list. > The link is below. >=20 > I'd like to request some time on the SACM BOF agenda to talk > about the ideas and information included in this I-D. Such a > discussion should really help us figure out how to make progress > on this part of the project. >=20 > Thanks, >=20 > Steve >=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Monday, October 15, 2012 1:56 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-hanna-sacm-assessment-protocols-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Standard Assessment Protocols and Formats for SACM > Author(s) : Steve Hanna > Filename : draft-hanna-sacm-assessment-protocols-00.txt > Pages : 7 > Date : 2012-10-15 >=20 > Abstract: > The draft charter for the SACM BOF at IETF 85 calls for the > development of "continuous assessment interfaces". This draft points > out several existing documents that provide a good start in this > area. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-hanna-sacm-assessment-protocols >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-hanna-sacm-assessment-protocols-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 From harold.booth@nist.gov Tue Oct 16 07:20:31 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F43821F87E2 for ; Tue, 16 Oct 2012 07:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scaBkSdE0YIg for ; Tue, 16 Oct 2012 07:20:30 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 606A221F87D4 for ; Tue, 16 Oct 2012 07:20:30 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.379.0; Tue, 16 Oct 2012 10:19:53 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 16 Oct 2012 10:20:08 -0400 From: "Booth, Harold" To: "sacm@ietf.org" Date: Tue, 16 Oct 2012 10:20:07 -0400 Thread-Topic: New Version Notification for draft-booth-sacm-vuln-model-00.txt Thread-Index: Ac2rHJOntfxdWKDzR8m+AdziI2dJpwAi2D+g Message-ID: References: <20121015213524.29661.9211.idtracker@ietfa.amsl.com> In-Reply-To: <20121015213524.29661.9211.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [sacm] FW: New Version Notification for draft-booth-sacm-vuln-model-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 14:20:31 -0000 SSBoYXZlIHBvc3RlZCBhIGZpcnN0IEludGVybmV0LURyYWZ0IG9mIGEgdnVsbmVyYWJpbGl0eSBt b2RlbCB0aGF0IGFkZHJlc3NlcyBWdWxuZXJhYmlsaXR5IE1hbmFnZW1lbnQgdXNlIGNhc2UgaW4g dGhlIHVzZSBjYXNlIGRyYWZ0IFsxXS4gIEkgaG9wZSB0byBtYWtlIHNvbWUgaW1wcm92ZW1lbnRz IHRvIHRoaXMgbW9kZWwgb3ZlciB0aGUgbmV4dCB3ZWVrIGFuZCBpZiBhbnlvbmUgaGFzIGFueSBj b21tZW50cyBJIHdpbGwgYmUgaGFwcHkgdG8gd29yayB3aXRoIHRoZW0gdG8gaW5jb3Jwb3JhdGUg dGhlaXIgZmVlZGJhY2sgcHJpb3IgdG8gdGhlIGRlYWRsaW5lIGZvciB1cGRhdGVkIGRyYWZ0cyBv biBPY3RvYmVyIDIyLg0KIA0KSSB3b3VsZCBsaWtlIHRvIHJlcXVlc3Qgc29tZSB0aW1lIG9uIHRo ZSBTQUNNIEJPRiBhZ2VuZGEgZm9yIHNvbWVvbmUgdG8gdGFsayBhYm91dCB0aGUgbW9kZWwgYW5k IGluZm9ybWF0aW9uIGluY2x1ZGVkIGluIHRoZSBkcmFmdC4NCg0KWzFdIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXdhbHRlcm1pcmUtc2FjbS11c2UtY2FzZXMtMDIjc2VjdGlvbi00 LjEuMi4yDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9u ZGF5LCBPY3RvYmVyIDE1LCAyMDEyIDU6MzUgUE0NClRvOiBCb290aCwgSGFyb2xkDQpTdWJqZWN0 OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJvb3RoLXNhY20tdnVsbi1tb2Rl bC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYm9vdGgtc2FjbS12dWxu LW1vZGVsLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBIYXJvbGQg Qm9vdGggYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRy YWZ0LWJvb3RoLXNhY20tdnVsbi1tb2RlbA0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgU29mdHdh cmUgVnVsbmVyYWJpbGl0eSBEYXRhIE1vZGVsIGFuZCBEYXRhIEV4Y2hhbmdlIEZvcm1hdA0KQ3Jl YXRpb24gZGF0ZToJIDIwMTItMTAtMTUNCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K TnVtYmVyIG9mIHBhZ2VzOiA2MA0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ib290aC1zYWNtLXZ1bG4tbW9kZWwtMDAudHh0DQpTdGF0 dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm9vdGgt c2FjbS12dWxuLW1vZGVsDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWJvb3RoLXNhY20tdnVsbi1tb2RlbC0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhp cyBJbnRlcm5ldC1EcmFmdCBkZXNjcmliZXMgdGhlIFZ1bG5lcmFiaWxpdHkgRGF0YSBNb2RlbCAo VkRNKQ0KICAgdmVyc2lvbiAxLjAsIGEgdmVuZG9yIG5ldXRyYWwgZGF0YSBtb2RlbCBmb3IgZXhw cmVzc2luZyBkYXRhIGFuZA0KICAgbWV0YWRhdGEgZm9yIGluZGl2aWR1YWwgdnVsbmVyYWJpbGl0 aWVzLCBhbmQgYW4gWE1MIGZvcm1hdCB0aGF0IGNhbg0KICAgYmUgdXNlZCB0byBleGNoYW5nZSB2 dWxuZXJhYmlsaXR5IGRhdGEgbW9kZWwgaW5mb3JtYXRpb24uICBWRE0NCiAgIHByb3ZpZGVzIHN0 YW5kYXJkIGZpZWxkcywgZm9ybWF0cyBhbmQgdm9jYWJ1bGFyaWVzIHRoYXQgY2FuIGJlIHVzZWQN CiAgIHRvIHRyYW5zbWl0IGluZm9ybWF0aW9uIGFib3V0IHNvZnR3YXJlIHZ1bG5lcmFiaWxpdGll cyBiZXR3ZWVuDQogICBlbnRpdGllcyBpbiBhbiBpbnRlcm9wZXJhYmxlIG1hbm5lci4gIFZETSBp cyBzdWl0ZWQgZm9yIGEgd2lkZQ0KICAgdmFyaWV0eSBvZiB1c2UgY2FzZXMsIGFuZCBwcm92aWRl cyBleHRlbnNpb24gcG9pbnRzIHRvIGZhY2lsaXRhdGUNCiAgIGFkZGl0aW9uYWwgdXNlIGNhc2Vz Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0K From kathleen.moriarty@emc.com Tue Oct 16 07:50:18 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4952721F8821 for ; Tue, 16 Oct 2012 07:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxMjTywwxWkE for ; Tue, 16 Oct 2012 07:50:12 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E744521F880C for ; Tue, 16 Oct 2012 07:50:11 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9GEoAmi007244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2012 10:50:11 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 16 Oct 2012 10:49:52 -0400 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9GEnpUn026457; Tue, 16 Oct 2012 10:49:51 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub14.corp.emc.com ([128.222.70.235]) with mapi; Tue, 16 Oct 2012 10:49:51 -0400 From: "Moriarty, Kathleen" To: "Booth, Harold" , "sacm@ietf.org" Date: Tue, 16 Oct 2012 10:49:50 -0400 Thread-Topic: [sacm] FW: New Version Notification for draft-booth-sacm-vuln-model-00.txt Thread-Index: Ac2rHJOntfxdWKDzR8m+AdziI2dJpwAi2D+gAAFdZNA= Message-ID: References: <20121015213524.29661.9211.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] FW: New Version Notification for draft-booth-sacm-vuln-model-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 14:50:18 -0000 Thank you, Harold! How much time do you need on the agenda? Best regards, Kathleen -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Boo= th, Harold Sent: Tuesday, October 16, 2012 10:20 AM To: sacm@ietf.org Subject: [sacm] FW: New Version Notification for draft-booth-sacm-vuln-mode= l-00.txt I have posted a first Internet-Draft of a vulnerability model that addresse= s Vulnerability Management use case in the use case draft [1]. I hope to m= ake some improvements to this model over the next week and if anyone has an= y comments I will be happy to work with them to incorporate their feedback = prior to the deadline for updated drafts on October 22. =20 I would like to request some time on the SACM BOF agenda for someone to tal= k about the model and information included in the draft. [1] http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02#section-4= .1.2.2 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, October 15, 2012 5:35 PM To: Booth, Harold Subject: New Version Notification for draft-booth-sacm-vuln-model-00.txt A new version of I-D, draft-booth-sacm-vuln-model-00.txt has been successfully submitted by Harold Booth and posted to the IETF repo= sitory. Filename: draft-booth-sacm-vuln-model Revision: 00 Title: Software Vulnerability Data Model and Data Exchange Format Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 60 URL: http://www.ietf.org/internet-drafts/draft-booth-sacm-vuln-= model-00.txt Status: http://datatracker.ietf.org/doc/draft-booth-sacm-vuln-mode= l Htmlized: http://tools.ietf.org/html/draft-booth-sacm-vuln-model-00 Abstract: This Internet-Draft describes the Vulnerability Data Model (VDM) version 1.0, a vendor neutral data model for expressing data and metadata for individual vulnerabilities, and an XML format that can be used to exchange vulnerability data model information. VDM provides standard fields, formats and vocabularies that can be used to transmit information about software vulnerabilities between entities in an interoperable manner. VDM is suited for a wide variety of use cases, and provides extension points to facilitate additional use cases. = =20 The IETF Secretariat _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From harold.booth@nist.gov Tue Oct 16 08:12:38 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9AD21F89C2 for ; Tue, 16 Oct 2012 08:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Dhv2A0k5ktp for ; Tue, 16 Oct 2012 08:12:37 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id B6EB91F0429 for ; Tue, 16 Oct 2012 08:12:33 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.379.0; Tue, 16 Oct 2012 11:11:56 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 16 Oct 2012 11:12:11 -0400 From: "Booth, Harold" To: "Moriarty, Kathleen" , "sacm@ietf.org" Date: Tue, 16 Oct 2012 11:12:10 -0400 Thread-Topic: [sacm] FW: New Version Notification for draft-booth-sacm-vuln-model-00.txt Thread-Index: Ac2rHJOntfxdWKDzR8m+AdziI2dJpwAi2D+gAAFdZNAAAMmlYA== Message-ID: References: <20121015213524.29661.9211.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sacm] FW: New Version Notification for draft-booth-sacm-vuln-model-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 15:12:38 -0000 10 minutes should suffice. Thanks. -Harold -----Original Message----- From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] Sent: Tuesday, October 16, 2012 10:50 AM To: Booth, Harold; sacm@ietf.org Subject: RE: [sacm] FW: New Version Notification for draft-booth-sacm-vuln-model-00.txt Thank you, Harold! How much time do you need on the agenda? Best regards, Kathleen -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Booth, Harold Sent: Tuesday, October 16, 2012 10:20 AM To: sacm@ietf.org Subject: [sacm] FW: New Version Notification for draft-booth-sacm-vuln-model-00.txt I have posted a first Internet-Draft of a vulnerability model that addresses Vulnerability Management use case in the use case draft [1]. I hope to make some improvements to this model over the next week and if anyone has any comments I will be happy to work with them to incorporate their feedback prior to the deadline for updated drafts on October 22. I would like to request some time on the SACM BOF agenda for someone to talk about the model and information included in the draft. [1] http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02#section-4.1.2.2 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, October 15, 2012 5:35 PM To: Booth, Harold Subject: New Version Notification for draft-booth-sacm-vuln-model-00.txt A new version of I-D, draft-booth-sacm-vuln-model-00.txt has been successfully submitted by Harold Booth and posted to the IETF repository. Filename: draft-booth-sacm-vuln-model Revision: 00 Title: Software Vulnerability Data Model and Data Exchange Format Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 60 URL: http://www.ietf.org/internet-drafts/draft-booth-sacm-vuln-model-00.txt Status: http://datatracker.ietf.org/doc/draft-booth-sacm-vuln-model Htmlized: http://tools.ietf.org/html/draft-booth-sacm-vuln-model-00 Abstract: This Internet-Draft describes the Vulnerability Data Model (VDM) version 1.0, a vendor neutral data model for expressing data and metadata for individual vulnerabilities, and an XML format that can be used to exchange vulnerability data model information. VDM provides standard fields, formats and vocabularies that can be used to transmit information about software vulnerabilities between entities in an interoperable manner. VDM is suited for a wide variety of use cases, and provides extension points to facilitate additional use cases. The IETF Secretariat _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Tue Oct 16 08:56:53 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C29721F8A0F for ; Tue, 16 Oct 2012 08:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.035 X-Spam-Level: X-Spam-Status: No, score=-6.035 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmdRDR3Q5mOp for ; Tue, 16 Oct 2012 08:56:52 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 3937D21F8A07 for ; Tue, 16 Oct 2012 08:56:52 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.379.0; Tue, 16 Oct 2012 11:56:36 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 16 Oct 2012 11:56:51 -0400 From: "Waltermire, David A." To: "Booth, Harold" , "Moriarty, Kathleen" , "sacm@ietf.org" Date: Tue, 16 Oct 2012 11:56:49 -0400 Thread-Topic: [sacm] FW: New Version Notification for draft-booth-sacm-vuln-model-00.txt Thread-Index: Ac2rHJOntfxdWKDzR8m+AdziI2dJpwAi2D+gAAFdZNAAAMmlYAABc+Sw Message-ID: References: <20121015213524.29661.9211.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sacm] FW: New Version Notification for draft-booth-sacm-vuln-model-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 15:56:53 -0000 Unless Harold can give the talk remotely, I will likely need to be the presentator in the room. Is there an option for remote presentation? Sincerely, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Booth, Harold > Sent: Tuesday, October 16, 2012 11:12 AM > To: Moriarty, Kathleen; sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-booth-sacm- > vuln-model-00.txt > > 10 minutes should suffice. Thanks. > > -Harold > > -----Original Message----- > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > Sent: Tuesday, October 16, 2012 10:50 AM > To: Booth, Harold; sacm@ietf.org > Subject: RE: [sacm] FW: New Version Notification for draft-booth-sacm- > vuln-model-00.txt > > Thank you, Harold! How much time do you need on the agenda? > > Best regards, > Kathleen > > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Booth, Harold > Sent: Tuesday, October 16, 2012 10:20 AM > To: sacm@ietf.org > Subject: [sacm] FW: New Version Notification for draft-booth-sacm-vuln- > model-00.txt > > I have posted a first Internet-Draft of a vulnerability model that > addresses Vulnerability Management use case in the use case draft [1]. > I hope to make some improvements to this model over the next week and > if anyone has any comments I will be happy to work with them to > incorporate their feedback prior to the deadline for updated drafts on > October 22. > > I would like to request some time on the SACM BOF agenda for someone to > talk about the model and information included in the draft. > > [1] http://tools.ietf.org/html/draft-waltermire-sacm-use-cases- > 02#section-4.1.2.2 > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, October 15, 2012 5:35 PM > To: Booth, Harold > Subject: New Version Notification for draft-booth-sacm-vuln-model- > 00.txt > > > A new version of I-D, draft-booth-sacm-vuln-model-00.txt > has been successfully submitted by Harold Booth and posted to the IETF > repository. > > Filename: draft-booth-sacm-vuln-model > Revision: 00 > Title: Software Vulnerability Data Model and Data Exchange > Format > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 60 > URL: http://www.ietf.org/internet-drafts/draft-booth-sacm- > vuln-model-00.txt > Status: http://datatracker.ietf.org/doc/draft-booth-sacm-vuln- > model > Htmlized: http://tools.ietf.org/html/draft-booth-sacm-vuln- > model-00 > > > Abstract: > This Internet-Draft describes the Vulnerability Data Model (VDM) > version 1.0, a vendor neutral data model for expressing data and > metadata for individual vulnerabilities, and an XML format that can > be used to exchange vulnerability data model information. VDM > provides standard fields, formats and vocabularies that can be used > to transmit information about software vulnerabilities between > entities in an interoperable manner. VDM is suited for a wide > variety of use cases, and provides extension points to facilitate > additional use cases. > > > > > The IETF Secretariat > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From kathleen.moriarty@emc.com Tue Oct 16 09:56:05 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FE521F8A6B for ; Tue, 16 Oct 2012 09:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJA+D16s5oXu for ; Tue, 16 Oct 2012 09:56:04 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 752C521F8A65 for ; Tue, 16 Oct 2012 09:56:04 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9GGtrMl010622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2012 12:56:02 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 16 Oct 2012 12:55:35 -0400 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9GGtY1l025759; Tue, 16 Oct 2012 12:55:34 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub36.corp.emc.com ([::1]) with mapi; Tue, 16 Oct 2012 12:55:34 -0400 From: "Moriarty, Kathleen" To: "Waltermire, David A." , "Booth, Harold" , "sacm@ietf.org" Date: Tue, 16 Oct 2012 12:55:33 -0400 Thread-Topic: [sacm] FW: New Version Notification for draft-booth-sacm-vuln-model-00.txt Thread-Index: Ac2rHJOntfxdWKDzR8m+AdziI2dJpwAi2D+gAAFdZNAAAMmlYAABc+SwAAIkX6A= Message-ID: References: <20121015213524.29661.9211.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [sacm] FW: New Version Notification for draft-booth-sacm-vuln-model-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 16:56:05 -0000 Hi Dave, Thanks. It is always better to have the presenter in person. If possible,= could you present and have Harold available remotely to assist with any qu= estions? Thank you! Kathleen -----Original Message----- From: Waltermire, David A. [mailto:david.waltermire@nist.gov]=20 Sent: Tuesday, October 16, 2012 11:57 AM To: Booth, Harold; Moriarty, Kathleen; sacm@ietf.org Subject: RE: [sacm] FW: New Version Notification for draft-booth-sacm-vuln-= model-00.txt Unless Harold can give the talk remotely, I will likely need to be the pres= entator in the room. Is there an option for remote presentation? Sincerely, Dave > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Booth, Harold > Sent: Tuesday, October 16, 2012 11:12 AM > To: Moriarty, Kathleen; sacm@ietf.org > Subject: Re: [sacm] FW: New Version Notification for draft-booth-sacm- > vuln-model-00.txt >=20 > 10 minutes should suffice. Thanks. >=20 > -Harold >=20 > -----Original Message----- > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > Sent: Tuesday, October 16, 2012 10:50 AM > To: Booth, Harold; sacm@ietf.org > Subject: RE: [sacm] FW: New Version Notification for draft-booth-sacm- > vuln-model-00.txt >=20 > Thank you, Harold! How much time do you need on the agenda? >=20 > Best regards, > Kathleen >=20 > -----Original Message----- > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of > Booth, Harold > Sent: Tuesday, October 16, 2012 10:20 AM > To: sacm@ietf.org > Subject: [sacm] FW: New Version Notification for draft-booth-sacm-vuln- > model-00.txt >=20 > I have posted a first Internet-Draft of a vulnerability model that > addresses Vulnerability Management use case in the use case draft [1]. > I hope to make some improvements to this model over the next week and > if anyone has any comments I will be happy to work with them to > incorporate their feedback prior to the deadline for updated drafts on > October 22. >=20 > I would like to request some time on the SACM BOF agenda for someone to > talk about the model and information included in the draft. >=20 > [1] http://tools.ietf.org/html/draft-waltermire-sacm-use-cases- > 02#section-4.1.2.2 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, October 15, 2012 5:35 PM > To: Booth, Harold > Subject: New Version Notification for draft-booth-sacm-vuln-model- > 00.txt >=20 >=20 > A new version of I-D, draft-booth-sacm-vuln-model-00.txt > has been successfully submitted by Harold Booth and posted to the IETF > repository. >=20 > Filename: draft-booth-sacm-vuln-model > Revision: 00 > Title: Software Vulnerability Data Model and Data Exchange > Format > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 60 > URL: http://www.ietf.org/internet-drafts/draft-booth-sacm- > vuln-model-00.txt > Status: http://datatracker.ietf.org/doc/draft-booth-sacm-vuln- > model > Htmlized: http://tools.ietf.org/html/draft-booth-sacm-vuln- > model-00 >=20 >=20 > Abstract: > This Internet-Draft describes the Vulnerability Data Model (VDM) > version 1.0, a vendor neutral data model for expressing data and > metadata for individual vulnerabilities, and an XML format that can > be used to exchange vulnerability data model information. VDM > provides standard fields, formats and vocabularies that can be used > to transmit information about software vulnerabilities between > entities in an interoperable manner. VDM is suited for a wide > variety of use cases, and provides extension points to facilitate > additional use cases. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm From david.waltermire@nist.gov Tue Oct 16 09:58:30 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E48021F8A6D for ; Tue, 16 Oct 2012 09:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.087 X-Spam-Level: X-Spam-Status: No, score=-6.087 tagged_above=-999 required=5 tests=[AWL=0.512, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvRCryW63R23 for ; Tue, 16 Oct 2012 09:58:27 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8716921F8A65 for ; Tue, 16 Oct 2012 09:58:27 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.379.0; Tue, 16 Oct 2012 12:58:22 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 16 Oct 2012 12:55:25 -0400 From: "Waltermire, David A." To: "Moriarty, Kathleen" , "Booth, Harold" , "sacm@ietf.org" Date: Tue, 16 Oct 2012 12:58:25 -0400 Thread-Topic: [sacm] FW: New Version Notification for draft-booth-sacm-vuln-model-00.txt Thread-Index: Ac2rHJOntfxdWKDzR8m+AdziI2dJpwAi2D+gAAFdZNAAAMmlYAABc+SwAAIkX6AAAB5LIA== Message-ID: References: <20121015213524.29661.9211.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sacm] FW: New Version Notification for draft-booth-sacm-vuln-model-00.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 16:58:30 -0000 Sure. That would be fine. Thanks, Dave > -----Original Message----- > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > Sent: Tuesday, October 16, 2012 12:56 PM > To: Waltermire, David A.; Booth, Harold; sacm@ietf.org > Subject: RE: [sacm] FW: New Version Notification for draft-booth-sacm- > vuln-model-00.txt > > Hi Dave, > > Thanks. It is always better to have the presenter in person. If > possible, could you present and have Harold available remotely to > assist with any questions? > > Thank you! > Kathleen > > -----Original Message----- > From: Waltermire, David A. [mailto:david.waltermire@nist.gov] > Sent: Tuesday, October 16, 2012 11:57 AM > To: Booth, Harold; Moriarty, Kathleen; sacm@ietf.org > Subject: RE: [sacm] FW: New Version Notification for draft-booth-sacm- > vuln-model-00.txt > > Unless Harold can give the talk remotely, I will likely need to be the > presentator in the room. Is there an option for remote presentation? > > Sincerely, > Dave > > > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Booth, Harold > > Sent: Tuesday, October 16, 2012 11:12 AM > > To: Moriarty, Kathleen; sacm@ietf.org > > Subject: Re: [sacm] FW: New Version Notification for draft-booth- > sacm- > > vuln-model-00.txt > > > > 10 minutes should suffice. Thanks. > > > > -Harold > > > > -----Original Message----- > > From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] > > Sent: Tuesday, October 16, 2012 10:50 AM > > To: Booth, Harold; sacm@ietf.org > > Subject: RE: [sacm] FW: New Version Notification for draft-booth- > sacm- > > vuln-model-00.txt > > > > Thank you, Harold! How much time do you need on the agenda? > > > > Best regards, > > Kathleen > > > > -----Original Message----- > > From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf > > Of Booth, Harold > > Sent: Tuesday, October 16, 2012 10:20 AM > > To: sacm@ietf.org > > Subject: [sacm] FW: New Version Notification for > > draft-booth-sacm-vuln- model-00.txt > > > > I have posted a first Internet-Draft of a vulnerability model that > > addresses Vulnerability Management use case in the use case draft > [1]. > > I hope to make some improvements to this model over the next week and > > if anyone has any comments I will be happy to work with them to > > incorporate their feedback prior to the deadline for updated drafts > on > > October 22. > > > > I would like to request some time on the SACM BOF agenda for someone > > to talk about the model and information included in the draft. > > > > [1] http://tools.ietf.org/html/draft-waltermire-sacm-use-cases- > > 02#section-4.1.2.2 > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Monday, October 15, 2012 5:35 PM > > To: Booth, Harold > > Subject: New Version Notification for draft-booth-sacm-vuln-model- > > 00.txt > > > > > > A new version of I-D, draft-booth-sacm-vuln-model-00.txt > > has been successfully submitted by Harold Booth and posted to the > IETF > > repository. > > > > Filename: draft-booth-sacm-vuln-model > > Revision: 00 > > Title: Software Vulnerability Data Model and Data Exchange > > Format > > Creation date: 2012-10-15 > > WG ID: Individual Submission > > Number of pages: 60 > > URL: http://www.ietf.org/internet-drafts/draft-booth- > sacm- > > vuln-model-00.txt > > Status: http://datatracker.ietf.org/doc/draft-booth-sacm- > vuln- > > model > > Htmlized: http://tools.ietf.org/html/draft-booth-sacm-vuln- > > model-00 > > > > > > Abstract: > > This Internet-Draft describes the Vulnerability Data Model (VDM) > > version 1.0, a vendor neutral data model for expressing data and > > metadata for individual vulnerabilities, and an XML format that > can > > be used to exchange vulnerability data model information. VDM > > provides standard fields, formats and vocabularies that can be > used > > to transmit information about software vulnerabilities between > > entities in an interoperable manner. VDM is suited for a wide > > variety of use cases, and provides extension points to facilitate > > additional use cases. > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm > > > > _______________________________________________ > > sacm mailing list > > sacm@ietf.org > > https://www.ietf.org/mailman/listinfo/sacm From kathleen.moriarty@emc.com Thu Oct 18 07:14:42 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869E221F8849 for ; Thu, 18 Oct 2012 07:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApSdCK2fvruO for ; Thu, 18 Oct 2012 07:14:41 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id BBDD821F8847 for ; Thu, 18 Oct 2012 07:14:41 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9IEEeCn022323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Oct 2012 10:14:40 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Thu, 18 Oct 2012 10:14:27 -0400 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9IEEOF9003647 for ; Thu, 18 Oct 2012 10:14:26 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub22.corp.emc.com ([128.222.70.134]) with mapi; Thu, 18 Oct 2012 10:14:25 -0400 From: "Moriarty, Kathleen" To: "sacm@ietf.org" Date: Thu, 18 Oct 2012 10:14:23 -0400 Thread-Topic: SACM BoF Agenda Thread-Index: Ac2tOt+I60fg6QMkR92GfVqS3uWCRw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F2409595CDEMX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [sacm] SACM BoF Agenda X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 14:14:42 -0000 --_000_F5063677821E3B4F81ACFB7905573F2409595CDEMX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello! Thank you for submitting drafts and requesting agenda slots! As of now, th= e agenda is as follows: O Discussion on Use Cases http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02 - Ada= m Montville/Dave Waltermire O Presentations on drafts to support Use cases Asset Identification Draft: http://tools.ietf.org/html/draft-montville-sacm-asset-identific= ation-00 - Adam Montville Continuous Assessment Protocol Draft: https://datatracker.ietf.org/doc/draft-hanna-sacm-assessment-protoc= ols - Steve Hanna Vulnerability Model: http://www.ietf.org/internet-drafts/draft-booth-sacm-vuln-model-00.= txt - Dave Waltermire O Tough Questions O Charter Review ** QUESTONS: I see the ASR draft was submitted, will someone be presenting this draft? http://tools.ietf.org/html/draft-davidson-sacm-asr-00 Have I missed anything? If you have submitted a draft and would like to present, please submit a re= quest. If you plan to update a draft prior to the meeting, the cutoff date= is October 22, 2012. For those attending the BoF, please read the drafts and charter in advance = of the meeting to ensure a productive session. Providing comments and fee= dback to the SACM mailing list in advance of the meeting is encouraged to f= ocus the talks on each of the drafts around hot topics rather than a review= of the drafts. Full list of important dates: https://www.ietf.org/meeting/cutoff-dates-2012.html#IETF85 Thank you in advance for reading a commenting on drafts! Best regards, Kathleen --_000_F5063677821E3B4F81ACFB7905573F2409595CDEMX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello!
 
Thank you for submitting drafts and requesting agenda slots!  As = of now, the agenda is as follows:
 
O  Discussion on Use Cases
        h= ttp://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02= - Adam Montville/Dave Waltermire
O  Presentations on drafts to support Use cases
        Asset Identification Draft:=
        Continuous Assessment Proto= col Draft:
        Vulnerability Model:
O  Tough Questions
O  Charter Review
 
** QUESTONS:
I see the ASR draft was submitted, will = someone be presenting this draft?
Have I missed anything?
 
If you have submitted a draft and would like to present, please submit= a request.  If you plan to update a draft prior to the meeting, the c= utoff date is October 22, 2012.
 
For those attending the BoF, please read the drafts and charter in adv= ance of the meeting to ensure a productive session.   Providing c= omments and feedback to the SACM mailing list in advance of the meeting is = encouraged to focus the talks on each of the drafts around hot topics rather than a review of the drafts.
 
Full list of important dates:
 
Thank you in advance for reading a commenting on drafts!
 
Best regards,
Kathleen
 
 
 --_000_F5063677821E3B4F81ACFB7905573F2409595CDEMX15Acorpemccom_-- From mdavidson@mitre.org Thu Oct 18 08:26:36 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75AD21F877F for ; Thu, 18 Oct 2012 08:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[AWL=0.951, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJRWV2IK3WGg for ; Thu, 18 Oct 2012 08:26:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A06B221F8653 for ; Thu, 18 Oct 2012 08:26:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0282E43300C4; Thu, 18 Oct 2012 11:26:35 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E7F8B1F046C; Thu, 18 Oct 2012 11:26:34 -0400 (EDT) Received: from IMCMBX02.MITRE.ORG ([169.254.2.200]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 11:26:34 -0400 From: "Davidson II, Mark S" To: "Moriarty, Kathleen" , "sacm@ietf.org" Thread-Topic: SACM BoF Agenda Thread-Index: Ac2tOt+I60fg6QMkR92GfVqS3uWCRwACc73g Date: Thu, 18 Oct 2012 15:26:34 +0000 Message-ID: <69F1FC52EB080B4983863BD1602520D80BD3869B@IMCMBX02.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.59] Content-Type: multipart/alternative; boundary="_000_69F1FC52EB080B4983863BD1602520D80BD3869BIMCMBX02MITREOR_" MIME-Version: 1.0 Subject: Re: [sacm] SACM BoF Agenda X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 15:26:36 -0000 --_000_69F1FC52EB080B4983863BD1602520D80BD3869BIMCMBX02MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I will not be making the trip to Atlanta. Is there another attendee who wou= ld want to present ASR? -Mark From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Mor= iarty, Kathleen Sent: Thursday, October 18, 2012 10:14 AM To: sacm@ietf.org Subject: [sacm] SACM BoF Agenda Hello! Thank you for submitting drafts and requesting agenda slots! As of now, th= e agenda is as follows: O Discussion on Use Cases http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02 - Ada= m Montville/Dave Waltermire O Presentations on drafts to support Use cases Asset Identification Draft: http://tools.ietf.org/html/draft-montville-sacm-asset-identific= ation-00 - Adam Montville Continuous Assessment Protocol Draft: https://datatracker.ietf.org/doc/draft-hanna-sacm-assessment-protoc= ols - Steve Hanna Vulnerability Model: http://www.ietf.org/internet-drafts/draft-booth-sacm-vuln-model-00.= txt - Dave Waltermire O Tough Questions O Charter Review ** QUESTONS: I see the ASR draft was submitted, will someone be presenting this draft? http://tools.ietf.org/html/draft-davidson-sacm-asr-00 Have I missed anything? If you have submitted a draft and would like to present, please submit a re= quest. If you plan to update a draft prior to the meeting, the cutoff date= is October 22, 2012. For those attending the BoF, please read the drafts and charter in advance = of the meeting to ensure a productive session. Providing comments and fee= dback to the SACM mailing list in advance of the meeting is encouraged to f= ocus the talks on each of the drafts around hot topics rather than a review= of the drafts. Full list of important dates: https://www.ietf.org/meeting/cutoff-dates-2012.html#IETF85 Thank you in advance for reading a commenting on drafts! Best regards, Kathleen --_000_69F1FC52EB080B4983863BD1602520D80BD3869BIMCMBX02MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I will not be making the = trip to Atlanta. Is there another attendee who would want to present ASR?

 <= /p>

-Mark

 <= /p>

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Moriarty, Kathleen
Sent: Thursday, October 18, 2012 10:14 AM
To: sacm@ietf.org
Subject: [sacm] SACM BoF Agenda

 

Hello!<= /o:p>

 <= /o:p>

Thank you fo= r submitting drafts and requesting agenda slots!  As of now, the agend= a is as follows:

 <= /o:p>

O  Disc= ussion on Use Cases

  =       h= ttp://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02 - Adam Mon= tville/Dave Waltermire

O  Pres= entations on drafts to support Use cases

  =       Asset Identification Draft:

  =       Continuous Assessment Protocol Draft:

  =       Vulnerability Model:

O  Toug= h Questions

O  Char= ter Review

 <= /o:p>

** QUESTONS:

I see the ASR draft was submitted, will someone be presenting this dra= ft?

Have I missed anything?

 <= /o:p>

If you have = submitted a draft and would like to present, please submit a request. = If you plan to update a draft prior to the meeting, the cutoff date is October 22, 2012.

 <= /o:p>

For those at= tending the BoF, please read the drafts and charter in advance of the meeti= ng to ensure a productive session.   Providing comments and feedback to the SACM mailing list in advance of the meeting is encouraged = to focus the talks on each of the drafts around hot topics rather than a re= view of the drafts.

 <= /o:p>

Full list of= important dates:

 <= /o:p>

Thank you in= advance for reading a commenting on drafts!

 <= /o:p>

Best regards= ,

Kathleen

 <= /o:p>

 <= /o:p>

--_000_69F1FC52EB080B4983863BD1602520D80BD3869BIMCMBX02MITREOR_-- From amontville@tripwire.com Thu Oct 18 09:25:00 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBB621F8743 for ; Thu, 18 Oct 2012 09:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.763 X-Spam-Level: X-Spam-Status: No, score=-3.763 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2+w-a-nWVSJ for ; Thu, 18 Oct 2012 09:24:59 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id A350C21F8741 for ; Thu, 18 Oct 2012 09:24:59 -0700 (PDT) Received: from mail80-co1-R.bigfish.com (10.243.78.231) by CO1EHSOBE009.bigfish.com (10.243.66.72) with Microsoft SMTP Server id 14.1.225.23; Thu, 18 Oct 2012 16:24:58 +0000 Received: from mail80-co1 (localhost [127.0.0.1]) by mail80-co1-R.bigfish.com (Postfix) with ESMTP id 45B45800735 for ; Thu, 18 Oct 2012 16:24:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -36 X-BigFish: VPS-36(zz9371Ic85fh1444Mc540Ka65Rzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839he5bhf0ah107ah1288h12a5h12bdh137ah1441h14ddhbe3k1155h) Received: from mail80-co1 (localhost.localdomain [127.0.0.1]) by mail80-co1 (MessageSwitch) id 135057749680735_3248; Thu, 18 Oct 2012 16:24:56 +0000 (UTC) Received: from CO1EHSMHS025.bigfish.com (unknown [10.243.78.235]) by mail80-co1.bigfish.com (Postfix) with ESMTP id 11E061C00BD for ; Thu, 18 Oct 2012 16:24:56 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CO1EHSMHS025.bigfish.com (10.243.66.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 18 Oct 2012 16:24:54 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 5040B232124A for ; Thu, 18 Oct 2012 09:17:55 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id A32AE2321248; Thu, 18 Oct 2012 09:17:54 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Thu, 18 Oct 2012 09:28:30 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Thu, 18 Oct 2012 09:24:49 -0700 From: Adam Montville To: "Davidson II, Mark S" , "Moriarty, Kathleen" , "sacm@ietf.org" Thread-Topic: [sacm] SACM BoF Agenda Thread-Index: Ac2tOt+I60fg6QMkR92GfVqS3uWCRwACc73gAAIaX4A= Date: Thu, 18 Oct 2012 16:24:48 +0000 Message-ID: In-Reply-To: <69F1FC52EB080B4983863BD1602520D80BD3869B@IMCMBX02.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_CCA57B3812312amontvilletripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: e19058f6-9800-4d73-903b-61468dc8c1f2 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: Re: [sacm] SACM BoF Agenda X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:25:00 -0000 --_000_CCA57B3812312amontvilletripwirecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If there is not another in-person attendee willing/able to present ASR, wou= ld it be possible (advisable?) for Mark to present over the phone or Meetec= ho (should we have that support)? From: "", Mark S > Date: Thursday, October 18, 2012 8:26 AM To: "kathleen.moriarty@emc.com" >, "sacm@ietf.org" > Subject: Re: [sacm] SACM BoF Agenda I will not be making the trip to Atlanta. Is there another attendee who wou= ld want to present ASR? -Mark From: sacm-bounces@ietf.org [mailto:sacm-boun= ces@ietf.org] On Behalf Of Moriarty, Kathleen Sent: Thursday, October 18, 2012 10:14 AM To: sacm@ietf.org Subject: [sacm] SACM BoF Agenda Hello! Thank you for submitting drafts and requesting agenda slots! As of now, th= e agenda is as follows: O Discussion on Use Cases http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02 - Ada= m Montville/Dave Waltermire O Presentations on drafts to support Use cases Asset Identification Draft: http://tools.ietf.org/html/draft-montville-sacm-asset-identific= ation-00 - Adam Montville Continuous Assessment Protocol Draft: https://datatracker.ietf.org/doc/draft-hanna-sacm-assessment-protoc= ols -Steve Hanna Vulnerability Model: http://www.ietf.org/internet-drafts/draft-booth-sacm-vuln-model-00.= txt - Dave Waltermire O Tough Questions O Charter Review ** QUESTONS: I see the ASR draft was submitted, will someone be presenting this draft? http://tools.ietf.org/html/draft-davidson-sacm-asr-00 Have I missed anything? If you have submitted a draft and would like to present, please submit a re= quest. If you plan to update a draft prior to the meeting, the cutoff date= is October 22, 2012. For those attending the BoF, please read the drafts and charter in advance = of the meeting to ensure a productive session. Providing comments and fee= dback to the SACM mailing list in advance of the meeting is encouraged to f= ocus the talks on each of the drafts around hot topics rather than a review= of the drafts. Full list of important dates: https://www.ietf.org/meeting/cutoff-dates-2012.html#IETF85 Thank you in advance for reading a commenting on drafts! Best regards, Kathleen --_000_CCA57B3812312amontvilletripwirecom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
If there is not another in-person attendee willing/able to present ASR= , would it be possible (advisable?) for Mark to present over the phone or M= eetecho (should we have that support)?


I will not be making the trip to A= tlanta. Is there another attendee who would want to present ASR?=

 

-Mark

 

From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Moriarty, Kathleen
Sent: Thursday, October 18, 2012 10:14 AM
To: sacm@ietf.org
Subject: [sacm] SACM BoF Agenda

 

Hello!

 

Thank you for submitting drafts = and requesting agenda slots!  As of now, the agenda is as follows:

 

O  Discussion on Use Cases<= o:p>

     &n= bsp;  h= ttp://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02 - Adam Mon= tville/Dave Waltermire

O  Presentations on drafts = to support Use cases

     &n= bsp;  Asset Identification Draft:

     &n= bsp;      http://tools.ietf.org/html/draft-montville-sacm-asset-identification-00=  - Adam Montville

     &n= bsp;  Continuous Assessment Protocol Draft:

     &n= bsp;  Vulnerability Model:

O  Tough Questions

O  Charter Review

 

** QUESTONS:

I see the ASR d= raft was submitted, will someone be presenting this draft?

Have I missed a= nything?

 

If you have submitted a draft an= d would like to present, please submit a request.  If you plan to upda= te a draft prior to the meeting, the cutoff date is October 22, 2012.

 

For those attending the BoF, ple= ase read the drafts and charter in advance of the meeting to ensure a produ= ctive session.   Providing comments and feedback to the SACM mailing list in advance of the meeting is encouraged = to focus the talks on each of the drafts around hot topics rather than a re= view of the drafts.

 

Full list of important dates:

 

Thank you in advance for reading= a commenting on drafts!

 

Best regards,<= /p>

Kathleen

 

 


--_000_CCA57B3812312amontvilletripwirecom_-- From david.oliva@verizon.net Fri Oct 19 04:17:11 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95ED21F85AF for ; Fri, 19 Oct 2012 04:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.593 X-Spam-Level: X-Spam-Status: No, score=-0.593 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9LvRBHlGNea for ; Fri, 19 Oct 2012 04:17:10 -0700 (PDT) Received: from vms173009pub.verizon.net (vms173009pub.verizon.net [206.46.173.9]) by ietfa.amsl.com (Postfix) with ESMTP id B8D3E21F8634 for ; Fri, 19 Oct 2012 04:17:10 -0700 (PDT) Received: from vznit170136pub.verizon.net ([unknown] [192.168.1.3]) by vms173009.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MC500CBZ0O7ARD0@vms173009.mailsrvcs.net> for sacm@ietf.org; Fri, 19 Oct 2012 06:16:55 -0500 (CDT) Received: from 96.241.166.234 ([96.241.166.234]) by vznit170136 (Verizon Webmail) with HTTP; Fri, 19 Oct 2012 06:16:55 -0500 (CDT) Date: Fri, 19 Oct 2012 06:16:55 -0500 (CDT) From: david.oliva@verizon.net To: mdavidson@mitre.org, sacm@ietf.org Message-id: <19281442.369918.1350645415068.JavaMail.root@vznit170136> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Mailer: Verizon Webmail X-Originating-IP: [96.241.166.234] Subject: Re: [sacm] SACM BoF Agenda X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 11:17:11 -0000
Unf= ortunately I will not be making it to Atlanta either.
 =
I encourage anybody who is attending the conference and is inter= ested in participating to take ASR on.
While there is p= erhaps yet no plan for a SCAP 1.3 (that I am aware of), ASR is highly likel= y to be included to SCAP.
 
David Oliva
=  
 
On 10/18/12, Davidson II, Mark S<mdavidson@mitre.or= g> wrote:
 

I will not be making the trip to Atlanta. Is there another= attendee who would want to present ASR?

 

-Mark

 

F= rom: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Moriarty, Kathleen
Sent: Thursday, October 18, = 2012 10:14 AM
To: sacm@ietf.org
Subject: [sacm] SACM BoF = Agenda

 

Hello!

 

Thank you for sub= mitting drafts and requesting agenda slots!  As of now, the agenda is = as follows:

O=   Discussion on Use Cases

        http://tools.ietf.org/html/draft-waltermire-sacm-use-cases-02 - Ada= m Montville/Dave Waltermire

O  Presentations on drafts to support Use cases

  &n= bsp;     Asset Identification Draft:

    &nbs= p;       http://tools.iet= f.org/html/draft-montville-sacm-asset-identification-00 - Adam Mon= tville

&nb= sp;       Continuous Assessment Protocol Draf= t:

<= SPAN style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">  &nbs= p;     https://datatracker.ietf.org/doc/draft-hanna-sa= cm-assessment-protocols - Steve Hanna

   &nbs= p;    Vulnerability Model:

O  Tough Questions

O  Charter Review

 

** QUESTONS:

<= /DIV>

I= see the ASR draft was submitted, will someone be presenting this draft?

Have I missed anything?

 

If you have submitted a draft and would like to present,= please submit a request.  If you plan to update a draft prior to the = meeting, the cutoff date is October 22, 2012.

 

For those attending the BoF, please read t= he drafts and charter in advance of the meeting to ensure a productive sess= ion.   Providing comments and feedback to the SACM mailing list i= n advance of the meeting is encouraged to focus the talks on each of the dr= afts around hot topics rather than a review of the drafts.

=

 

Full list of important dates:=

ht= tps://www.ietf.org/meeting/cutoff-dates-2012.html#IETF85

 

<= DIV>

Thank you in advance for re= ading a commenting on drafts!

Best regards,

Kathleen

 



________= _______________________________________
sacm mailing list
sacm@ietf.org=
https://www.ietf.org/mailman/listinfo/sacm
=
From harold.booth@nist.gov Mon Oct 22 15:22:16 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0EF11E80A2 for ; Mon, 22 Oct 2012 15:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BT5oHx+lRDwU for ; Mon, 22 Oct 2012 15:22:15 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 680E511E8097 for ; Mon, 22 Oct 2012 15:22:05 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.421.2; Mon, 22 Oct 2012 18:21:40 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 22 Oct 2012 18:21:42 -0400 From: "Booth, Harold" To: "sacm@ietf.org" Date: Mon, 22 Oct 2012 18:21:41 -0400 Thread-Topic: New Version Notification for draft-booth-sacm-vuln-model-01.txt Thread-Index: Ac2woyNgJbfKSJd9TCeipXZ6iQLtWQAAA0gA Message-ID: References: <20121022221817.7138.33966.idtracker@ietfa.amsl.com> In-Reply-To: <20121022221817.7138.33966.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [sacm] FW: New Version Notification for draft-booth-sacm-vuln-model-01.txt X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 22:22:16 -0000 VXBkYXRlZCBkcmFmdCBvZiB0aGUgdnVsbmVyYWJpbGl0eSBtb2RlbCBoYXMgYmVlbiBwb3N0ZWQu DQpBIGxhcmdlIG51bWJlciBvZiBpc3N1ZXMgaW4gdGhlIHNjaGVtYSBhbmQgZG9jdW1lbnRhdGlv biBoYXZlIGJlZW4gZml4ZWQuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmdd IA0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDIyLCAyMDEyIDY6MTggUE0NClRvOiBCb290aCwgSGFy b2xkDQpDYzoga2FyZW5Ac2NhcmZvbmVjeWJlcnNlY3VyaXR5LmNvbQ0KU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1ib290aC1zYWNtLXZ1bG4tbW9kZWwtMDEudHh0 DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJvb3RoLXNhY20tdnVsbi1tb2RlbC0w MS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSGFyb2xkIEJvb3RoIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1ib290 aC1zYWNtLXZ1bG4tbW9kZWwNClJldmlzaW9uOgkgMDENClRpdGxlOgkJIFZ1bG5lcmFiaWxpdHkg RGF0YSBNb2RlbA0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMTAtMjINCldHIElEOgkJIEluZGl2aWR1 YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA3Ng0KVVJMOiAgICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ib290aC1zYWNtLXZ1bG4tbW9k ZWwtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtYm9vdGgtc2FjbS12dWxuLW1vZGVsDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvb3RoLXNhY20tdnVsbi1tb2RlbC0wMQ0KRGlmZjog ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1ib290aC1z YWNtLXZ1bG4tbW9kZWwtMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIEludGVybmV0LURyYWZ0IGRl c2NyaWJlcyB0aGUgVnVsbmVyYWJpbGl0eSBEYXRhIE1vZGVsIChWRE0pDQogICB2ZXJzaW9uIDEu MCwgYSB2ZW5kb3IgbmV1dHJhbCBkYXRhIG1vZGVsIGZvciBleHByZXNzaW5nIGRhdGEgYW5kDQog ICBtZXRhZGF0YSBmb3IgaW5kaXZpZHVhbCB2dWxuZXJhYmlsaXRpZXMsIGFuZCBhbiBYTUwgZm9y bWF0IHRoYXQgY2FuDQogICBiZSB1c2VkIHRvIGV4Y2hhbmdlIHZ1bG5lcmFiaWxpdHkgZGF0YSBt b2RlbCBpbmZvcm1hdGlvbi4gIFZETQ0KICAgcHJvdmlkZXMgc3RhbmRhcmQgZmllbGRzLCBmb3Jt YXRzIGFuZCB2b2NhYnVsYXJpZXMgdGhhdCBjYW4gYmUgdXNlZA0KICAgdG8gdHJhbnNtaXQgaW5m b3JtYXRpb24gYWJvdXQgc29mdHdhcmUgdnVsbmVyYWJpbGl0aWVzIGJldHdlZW4NCiAgIGVudGl0 aWVzIGluIGFuIGludGVyb3BlcmFibGUgbWFubmVyLiAgVkRNIGlzIHN1aXRlZCBmb3IgYSB3aWRl DQogICB2YXJpZXR5IG9mIHVzZSBjYXNlcywgYW5kIHByb3ZpZGVzIGV4dGVuc2lvbiBwb2ludHMg dG8gZmFjaWxpdGF0ZQ0KICAgYWRkaXRpb25hbCB1c2UgY2FzZXMuDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From amontville@tripwire.com Mon Oct 22 15:34:57 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0705211E80E2 for ; Mon, 22 Oct 2012 15:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.755 X-Spam-Level: X-Spam-Status: No, score=-3.755 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBmqNBgkbo6s for ; Mon, 22 Oct 2012 15:34:56 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 49BB911E808D for ; Mon, 22 Oct 2012 15:34:56 -0700 (PDT) Received: from mail232-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Mon, 22 Oct 2012 22:34:55 +0000 Received: from mail232-va3 (localhost [127.0.0.1]) by mail232-va3-R.bigfish.com (Postfix) with ESMTP id 6C45C2001FF for ; Mon, 22 Oct 2012 22:34:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzc85ehzz1202h1d1ah1d2ahzz8275bhz2dh2a8h668h839he5bhf0ah107ah1288h12a5h12bdh137ah1441h14ddh1504hbe3k1155h) Received: from mail232-va3 (localhost.localdomain [127.0.0.1]) by mail232-va3 (MessageSwitch) id 1350945293405325_22141; Mon, 22 Oct 2012 22:34:53 +0000 (UTC) Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.243]) by mail232-va3.bigfish.com (Postfix) with ESMTP id 573F4BC0047 for ; Mon, 22 Oct 2012 22:34:53 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 22 Oct 2012 22:34:53 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 233392321206 for ; Mon, 22 Oct 2012 15:27:32 -0700 (PDT) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 85AED23211EE for ; Mon, 22 Oct 2012 15:27:31 -0700 (PDT) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Mon, 22 Oct 2012 15:38:25 -0700 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0379.000; Mon, 22 Oct 2012 15:34:50 -0700 From: Adam Montville To: "sacm@ietf.org" Thread-Topic: Potential Charter Addition? Thread-Index: AQHNsKVyZe4b6VOaPUK6g9fO7j0ePA== Date: Mon, 22 Oct 2012 22:34:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_CCAB18195848amontvilletripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 646db9a1-3fdc-411b-81e8-3443a771dc88 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: [sacm] Potential Charter Addition? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 22:34:57 -0000 --_000_CCAB18195848amontvilletripwirecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All: There has been some discussion lately about the Common Configuration Enumer= ation (CCE) specification on the CCE list. In particular, this discussion = has centered around some operational concerns with respect to scaling CCE a= s presently specified. A proposal has been made to reduce the dataset embo= died by a CCE entry, with subsequent ideas coming out of a potential schema= change. I believe we would all agree that what CCE provides =96 the ability to accu= rately reference a configuration item =96 is important to security automati= on. What do others think about exploring the possibility of bringing this capab= ility into the proposed SCAM WG as part of our charter? Yes, our charter i= s already large, but if the CCE community is actively seeking to improve th= eir schema, it seems a good time to consider inviting that community to joi= n ours in our common automation goals =96 especially for something that is = as foundational as CCE. Thoughts? Adam --_000_CCAB18195848amontvilletripwirecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <617DA687AA6C2A4FB531C0E94774F558@tripwire.com> Content-Transfer-Encoding: quoted-printable
All:

There has been some discussion lately about the Common Configuration E= numeration (CCE) specification on the CCE list.  In particular, this d= iscussion has centered around some operational concerns with respect to sca= ling CCE as presently specified.  A proposal has been made to reduce the dataset embodied by a CCE entry, with subseque= nt ideas coming out of a potential schema change.

I believe we would all agree that what CCE provides =96 the ability to= accurately reference a configuration item =96 is important to security aut= omation.  

What do others think about exploring the possibility of bringing this = capability into the proposed SCAM WG as part of our charter?  Yes, our= charter is already large, but if the CCE community is actively seeking to = improve their schema, it seems a good time to consider inviting that community to join ours in our common automa= tion goals =96 especially for something that is as foundational as CCE.

Thoughts?

Adam
--_000_CCAB18195848amontvilletripwirecom_-- From bchandra@secpod.com Tue Oct 23 23:52:25 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7318A21F8C94; Tue, 23 Oct 2012 23:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQT9mtQabxzy; Tue, 23 Oct 2012 23:52:24 -0700 (PDT) Received: from cpanel23.interactivedns.com (cpanel23.interactivedns.com [184.173.122.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5D34821F8D34; Tue, 23 Oct 2012 23:52:24 -0700 (PDT) Received: from [122.172.9.233] (port=14579 helo=hpPC) by cpanel23.interactivedns.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TQupC-0001sa-Rq; Wed, 24 Oct 2012 12:22:23 +0530 From: "Chandrashekhar B" To: "'Luis Nunez'" , "'Adam Montville'" References: <8F587404-FBC7-445A-B5D3-2DB5511424C2@c3isecurity.com> In-Reply-To: <8F587404-FBC7-445A-B5D3-2DB5511424C2@c3isecurity.com> Date: Wed, 24 Oct 2012 12:22:14 +0530 Organization: SecPod Technologies Message-ID: <016601cdb1b4$1c59f6e0$550de4a0$@secpod.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIzweHfw3vs7m8GczxPbJrxnBlvCwKeEaFFlubpdHA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel23.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - secpod.com X-Source: X-Source-Args: X-Source-Dir: Cc: SCAP-DEV , scap_interest@ietf.org, sacm@ietf.org Subject: Re: [sacm] [scap_interest] Just throwing this out there: Compliance Frameworks X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bchandra@secpod.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 06:52:25 -0000 Hello All, We used the NIST 800-53 - CCE mappings (http://static.nvd.nist.gov/feeds/xml/cce/nvdcce-0.1-feed.xml) and incorporated this into the CCEs reference in SCAP Repo (www.scaprepo.com). We can now search based on the 800-53 control ID's like AC-3, CM-6 etc and list the CCEs that map to it. And we also used the CCM (Cloud Control Matrix) mappings to NIST 800-53 and to other regulatory standards and arrived at CCEs related to each regulatory standard. We can now search for "pcidss cce" or "COBIT CCE", for example. The objective is to arrive at common set of technical requirements for each of the regulatory standard and hence the mapping to CCE. Thanks to Luis and Cloud Security Alliance. As a next step, we took up an exercise to map individual regulatory requirements to the right CCEs and started with NERC CIP to CCE mapping. If there is any interest in this work or any collaboration possibility, we would be happy to work together, please mail me. Thanks, Chandra. -----Original Message----- From: scap_interest-bounces@ietf.org [mailto:scap_interest-bounces@ietf.org] On Behalf Of Luis Nunez Sent: Wednesday, February 15, 2012 2:47 AM To: Adam Montville Cc: scap_interest@ietf.org 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 > scap_interest@ietf.org > https://www.ietf.org/mailman/listinfo/scap_interest _______________________________________________ scap_interest mailing list scap_interest@ietf.org https://www.ietf.org/mailman/listinfo/scap_interest ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2197 / Virus Database: 2437/5207 - Release Date: 08/18/12 From dromasca@avaya.com Wed Oct 24 09:24:25 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5695E21F85F3 for ; Wed, 24 Oct 2012 09:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.858 X-Spam-Level: X-Spam-Status: No, score=-102.858 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cbhh8KQcTn12 for ; Wed, 24 Oct 2012 09:24:24 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id A191121F85BF for ; Wed, 24 Oct 2012 09:24:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMIViFDGmAcF/2dsb2JhbABEwXSBCIIgAQEDEh4KUQEVFQYMDAdXAQQbGodiC5s/hC2dFQSPKoJDYQObeYozgnE X-IronPort-AV: E=Sophos;i="4.80,641,1344225600"; d="scan'208";a="33043738" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 24 Oct 2012 12:15:59 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Oct 2012 12:15:06 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Oct 2012 18:24:22 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: preliminary agenda for the BOF Thread-Index: Ac2yBAZhqOXGbl4hRXW4UBPDwLCjNA== From: "Romascanu, Dan (Dan)" To: Subject: [sacm] preliminary agenda for the BOF X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 16:24:25 -0000 Hi, I uploaded the preliminary agenda for the BOF at https://datatracker.ietf.org/meeting/85/agenda/sacm/. Plenty of time was reserved for discussions with focus on the use cases, scope of the proposed work, tough questions and next steps.=20 Questions and comments are welcome.=20 Regards, Dan From david.oliva@verizon.net Sat Oct 27 15:49:08 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D289C21F848A for ; Sat, 27 Oct 2012 15:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.556 X-Spam-Level: * X-Spam-Status: No, score=1.556 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPeYl4x0vK68 for ; Sat, 27 Oct 2012 15:49:07 -0700 (PDT) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by ietfa.amsl.com (Postfix) with ESMTP id 8924F21F845C for ; Sat, 27 Oct 2012 15:49:04 -0700 (PDT) Received: from vms170029pub.verizon.net ([unknown] [192.168.1.3]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MCK001BXQ1CZB10@vms173003.mailsrvcs.net> for sacm@ietf.org; Sat, 27 Oct 2012 17:48:49 -0500 (CDT) Received: from 96.241.166.234 ([96.241.166.234]) by vms170029 (Verizon Webmail) with HTTP; Sat, 27 Oct 2012 17:48:48 -0500 (CDT) Date: Sat, 27 Oct 2012 17:48:48 -0500 (CDT) From: david.oliva@verizon.net To: sacm@ietf.org, bchandra@secpod.com Message-id: <14409297.777207.1351378128668.JavaMail.root@vms170029> MIME-version: 1.0 Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable X-Mailer: Verizon Webmail X-Originating-IP: [96.241.166.234] Subject: [sacm] SACM/CCE terminology in other compliance frameworks X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 22:49:08 -0000
Cha= ndra and all:
 
I see this as a step in= the right direction.
 
CobiT has a full spreadshe= et mapping of their compliance requirements to SP 800-53 (under research).&= nbsp; The "CobiT CCE" that Chandra suggests is a good marketing&n= bsp;idea in my opinion.
I do not know that PCI-DSS has been mappe= d to SP 800-53, but the "pcidss CCE" is also a new interesting idea (opinio= n also).
 
However, I see SACM product capabilitie= s as a "scan-once and map to any compliance model" strategy.
The = "CCE to other compliance models" can only be achieved with SP 800-53 to oth= er compliance model mappings.
 
The mappings will = probably be a springboard for vendors to make their products relevant to or= ganizations needing to comply with governance models other than FISMA.
 
Notetworthy and of marketting value for internationa= l business is that, for semi-automatable compliance requirements, they can = use SACM/OCIL.
 
I also would like to emphasize th= at SCAP content and SCAP products that can map to governance compliance&nbs= p;models are tier IV (as specified in SP 800-70)
 
David Oliva
 

 


-----Original Message----= -
From: Chandrashekhar B [mailto:bchandra@secpod.com]
Sent: Wedne= sday, October 24, 2012 2:52 AM
To: 'Luis Nunez'; 'Adam Montville'
Cc:= SCAP-DEV; scap_interest@ietf.org; sacm@ietf.org
Subject: Re: [sacm= ] [scap_interest] Just throwing this out there: Compliance Frameworks
Hello All,

We used the NIST 800-53 - CCE mappings
(http://static.nvd.nist.gov/feeds/xml/cce/nvdcce-0.1-fe= ed.xml) and incorporated this into the CCEs reference in SCAP Repo (www.sc= aprepo.com).
We can now search based on the 800-53 control ID's like= AC-3, CM-6 etc and list the CCEs that map to it.

And we also used t= he CCM (Cloud Control Matrix) mappings to NIST 800-53 and to other regulato= ry standards and arrived at CCEs related to each regulatory standard. We ca= n now search for "pcidss cce" or "COBIT CCE", for example.
The objective= is to arrive at common set of technical requirements for each of the regul= atory standard and hence the mapping to CCE.

Thanks to Luis and Clo= ud Security Alliance.

As a next step, we took up an exercise to map= individual regulatory requirements to the right CCEs and started with NERC= CIP to CCE mapping. If there is any interest in this work or any collabora= tion possibility, we would be happy to work together, please mail me.
<= BR>Thanks,
Chandra.

-----Original Message-----
From: scap_interest-bounces@ietf.org [mailto:scap_interest-bounces= @ietf.org]
On Behalf Of Luis Nunez
Sent: Wednesday, February 15, = 2012 2:47 AM
To: Adam Montville
Cc: scap_interest@ietf.org
= Subject: Re: [scap_interest] Just throwing this out there: Compliance Frame= works

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

Link: https://cloudsecurityalliance.org/researc= h/ccm/

-ln


On Feb 14, 2012, at 4:09 PM, Adam Montvill= e wrote:

> All,
>
> I had a brief discussion with se= veral members of this list with
> respect to
compliance framework= s, which met some resistance. Still, I think presenting the idea to a large= r audience to solicit feedback is a good idea.
>
> From an aut= omation perspective, it seems that some method of being
> able tomap benchmark-level tests to some higher level policy representation may b= e warranted. At the end of the day, we perform assessments to ensure that w= e are in a secure state - to be compliant with a particular set of policies= .
>
> Is there any interest in being able to represent a compl= iance
> framework
with either a new specification or potentially = revitalizing and extending an existing specification (CCI: http://i= ase.disa.mil/stigs/cci.html), or to simply rely upon any existing comme= rcial efforts, such as UCF (https://www.unifiedcompliance.com)?<= BR>>
> Or, is this type of representation simply not needed - the= re's enough
there, the present demand doesn't justify the work, or somet= hing else?
>
> Thoughts?
>
> Regards,
> > Adam W. Montville | Security and Compliance Architect
>
>= ; Direct: 503 276-7661
> Mobile: 360 471-7815
>
> TRIPWI= RE | Take CONTROL
> http://www.tripwire.com
>
> _______= ________________________________________
> scap_interest mailing list=
> scap_interest@ietf.org
> ht= tps://www.ietf.org/mailman/listinfo/scap_interest

______________= _________________________________
scap_interest mailing list
scap_= interest@ietf.org
https://www.ietf.org/mailm= an/listinfo/scap_interest
-----
No virus found in this message.Checked by AVG - www.avg.com
Version: 2012.0.2197 / Virus Database: 2437/5= 207 - Release Date: 08/18/12



From dhaynes@mitre.org Mon Oct 29 03:53:25 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7C321F85E0; Mon, 29 Oct 2012 03:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRPmZa97K1cF; Mon, 29 Oct 2012 03:53:25 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D91F721F85B3; Mon, 29 Oct 2012 03:53:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2E4B21F054B; Mon, 29 Oct 2012 06:53:24 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 0E2021F0416; Mon, 29 Oct 2012 06:53:24 -0400 (EDT) Received: from IMCMBX03.MITRE.ORG ([169.254.3.117]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.004; Mon, 29 Oct 2012 06:53:23 -0400 From: "Haynes, Dan" To: "Robert Rota (CONT)" , 'SCAP-DEV' , "scap_interest@ietf.org" , "sacm@ietf.org" Thread-Topic: [scap-dev] Vulnerability Scanner with SCAP formatted audits? Thread-Index: AQHNs6QfhxAU7ZHFz0mXcVy50EDXOJfQGS8A Date: Mon, 29 Oct 2012 10:53:23 +0000 Message-ID: <6A1F6FD3001BDD40A94503E2223CEBD5016BC851@IMCMBX03.MITRE.ORG> References: <8F587404-FBC7-445A-B5D3-2DB5511424C2@c3isecurity.com> <016601cdb1b4$1c59f6e0$550de4a0$@secpod.com> <00fe01cdb3a4$0c2c7120$24855360$@navy.mil> In-Reply-To: <00fe01cdb3a4$0c2c7120$24855360$@navy.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sacm] [scap-dev] Vulnerability Scanner with SCAP formatted audits? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 10:53:25 -0000 Hi Rob, In addition to the list of SCAP Validated Products (http://nvd.nist.gov/sca= pproducts.cfm), you may also want to check out the list of products partici= pating in the OVAL Adoption Program (http://oval.mitre.org/adoption/partici= pants.html). There is a fair amount of overlap between the two lists, but,= you may find something that fits your needs. Thanks, Danny >-----Original Message----- >From: scap-dev-bounces@nist.gov [mailto:scap-dev-bounces@nist.gov] On >Behalf Of Robert Rota (CONT) >Sent: Friday, October 26, 2012 2:02 PM >To: 'SCAP-DEV'; scap_interest@ietf.org; sacm@ietf.org >Subject: [scap-dev] Vulnerability Scanner with SCAP formatted audits? > >Hello, > >Is anyone aware of a vulnerability scanner that has the number of checks >comparable to Retina or Nessus that has all of the checks in a SCAP format= ? >Retina is xml but not SCAP and Nessus is .audit. I know they can import SC= AP >format but that is not what I need. DoD has mandatory tools that will impo= rt >SCAP but I can't find a comprehensive vulnerability scan (patches, >zero-days, etc.) in SCAP format that I can use? > >I spoke with a few guys that tried to convert the Nessus and Retina checks >to SCAP with a dead end once the checks were too dependent on the scan >engine. > >Any help would be appreciated. Or, please forward to a more appropriate >group. I am aware of the list on the NIST NVD site but these are SCAP >compliant importers that don't have all of their proprietary checks in SCA= P >format. > > >Thanks! > > >Rob >-- >Robert Rota >SPAWAR Network Security >Contractor, SAIC CISBU >SSC Pacific Tel# 619-553-1523 >Mobile Tel# 619-405-8979 > >"Everything that I ever knew - my life, my loved ones, the Navy - >everything, the whole world was behind my thumb." -James Lovell > From bchandra@secpod.com Mon Oct 29 08:50:25 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2ED21F8743; Mon, 29 Oct 2012 08:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgB6jYDuu6E0; Mon, 29 Oct 2012 08:50:24 -0700 (PDT) Received: from cpanel23.interactivedns.com (cpanel23.interactivedns.com [184.173.122.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C08221F8745; Mon, 29 Oct 2012 08:50:20 -0700 (PDT) Received: from [182.72.99.242] (port=2446 helo=hpPC) by cpanel23.interactivedns.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TSrbX-0001Js-9r; Mon, 29 Oct 2012 21:20:20 +0530 From: "Chandrashekhar B" To: "'Robert Rota \(CONT\)'" , "'SCAP-DEV'" , , References: <8F587404-FBC7-445A-B5D3-2DB5511424C2@c3isecurity.com> <016601cdb1b4$1c59f6e0$550de4a0$@secpod.com> <00fe01cdb3a4$0c2c7120$24855360$@navy.mil> In-Reply-To: <00fe01cdb3a4$0c2c7120$24855360$@navy.mil> Date: Mon, 29 Oct 2012 21:20:13 +0530 Organization: SecPod Technologies Message-ID: <00f101cdb5ed$18188870$48499950$@secpod.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIzweHfw3vs7m8GczxPbJrxnBlvCwKeEaFFAwfbeaUB1AfprpbIhNhA Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel23.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - secpod.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [sacm] [scap-dev] Vulnerability Scanner with SCAP formatted audits? X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bchandra@secpod.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 15:50:25 -0000 Hello Robert, If you are looking at SCAP content that you can import into an SCAP enabled scanner, we have pretty good coverage for the vulnerability and patch detection in SCAP format. You could look at www.scaprepo.com for more details or mail me. Thanks, Chandra. -----Original Message----- From: scap-dev-bounces@nist.gov [mailto:scap-dev-bounces@nist.gov] On Behalf Of Robert Rota (CONT) Sent: Friday, October 26, 2012 11:32 PM To: 'SCAP-DEV'; scap_interest@ietf.org; sacm@ietf.org Subject: [scap-dev] Vulnerability Scanner with SCAP formatted audits? Hello, Is anyone aware of a vulnerability scanner that has the number of checks comparable to Retina or Nessus that has all of the checks in a SCAP format? Retina is xml but not SCAP and Nessus is .audit. I know they can import SCAP format but that is not what I need. DoD has mandatory tools that will import SCAP but I can't find a comprehensive vulnerability scan (patches, zero-days, etc.) in SCAP format that I can use? I spoke with a few guys that tried to convert the Nessus and Retina checks to SCAP with a dead end once the checks were too dependent on the scan engine. Any help would be appreciated. Or, please forward to a more appropriate group. I am aware of the list on the NIST NVD site but these are SCAP compliant importers that don't have all of their proprietary checks in SCAP format. Thanks! Rob -- Robert Rota SPAWAR Network Security Contractor, SAIC CISBU SSC Pacific Tel# 619-553-1523 Mobile Tel# 619-405-8979 "Everything that I ever knew - my life, my loved ones, the Navy - everything, the whole world was behind my thumb." -James Lovell ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2741 / Virus Database: 2616/5846 - Release Date: 10/21/12 From bchandra@secpod.com Tue Oct 30 07:17:43 2012 Return-Path: X-Original-To: sacm@ietfa.amsl.com Delivered-To: sacm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A1121F845C for ; Tue, 30 Oct 2012 07:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2RfLTd+ewth for ; Tue, 30 Oct 2012 07:17:26 -0700 (PDT) Received: from cpanel23.interactivedns.com (cpanel23.interactivedns.com [184.173.122.2]) by ietfa.amsl.com (Postfix) with ESMTP id 12AC921F850E for ; Tue, 30 Oct 2012 07:17:25 -0700 (PDT) Received: from [182.72.99.242] (port=1552 helo=hpPC) by cpanel23.interactivedns.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TTCd9-000589-Gd; Tue, 30 Oct 2012 19:47:25 +0530 From: "Chandrashekhar B" To: , References: <14409297.777207.1351378128668.JavaMail.root@vms170029> In-Reply-To: <14409297.777207.1351378128668.JavaMail.root@vms170029> Date: Tue, 30 Oct 2012 19:47:16 +0530 Organization: SecPod Technologies Message-ID: <020a01cdb6a9$460f0490$d22d0db0$@secpod.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_020B_01CDB6D7.5FCD0CF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEUlEw9TLYbwSHqBOv9vic5lU/LiZlEJQsg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel23.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - secpod.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [sacm] SACM/CCE terminology in other compliance frameworks X-BeenThere: sacm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bchandra@secpod.com List-Id: "Discussion List for IETFers interested in the Security Content Automation Protocol \(SCAP\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2012 14:17:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_020B_01CDB6D7.5FCD0CF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable David, =20 Comments inline=E2=80=A6 =20 From: david.oliva@verizon.net [mailto:david.oliva@verizon.net]=20 Sent: Sunday, October 28, 2012 4:19 AM To: sacm@ietf.org; bchandra@secpod.com Subject: SACM/CCE terminology in other compliance frameworks =20 Chandra and all: =20 I see this as a step in the right direction. =20 CobiT has a full spreadsheet mapping of their compliance requirements to = SP 800-53 (under research). The "CobiT CCE" that Chandra suggests is a = good marketing idea in my opinion. =20 This is very useful, do you have a link for the CobiT to 800-53 = mappings? =20 I do not know that PCI-DSS has been mapped to SP 800-53, but the "pcidss = CCE" is also a new interesting idea (opinion also). =20 However, I see SACM product capabilities as a "scan-once and map to any = compliance model" strategy. The "CCE to other compliance models" can only be achieved with SP 800-53 = to other compliance model mappings. =20 Good idea! If all compliance model map to SP 800-53, which would in-turn = allows us to reach to the CCEs.=20 =20 The mappings will probably be a springboard for vendors to make their = products relevant to organizations needing to comply with governance = models other than FISMA. =20 Notetworthy and of marketting value for international business is that, = for semi-automatable compliance requirements, they can use SACM/OCIL. =20 I also would like to emphasize that SCAP content and SCAP products that = can map to governance compliance models are tier IV (as specified in SP = 800-70) =20 David Oliva =20 =20 -----Original Message----- From: Chandrashekhar B [mailto:bchandra@secpod.com]=20 Sent: Wednesday, October 24, 2012 2:52 AM To: 'Luis Nunez'; 'Adam Montville' Cc: SCAP-DEV; scap_interest@ietf.org; sacm@ietf.org Subject: Re: [sacm] [scap_interest] Just throwing this out there: = Compliance Frameworks Hello All, We used the NIST 800-53 - CCE mappings (http://static.nvd.nist.gov/feeds/xml/cce/nvdcce-0.1-feed.xml) and = incorporated this into the CCEs reference in SCAP Repo (www.scaprepo.com = ). We can now search based on the 800-53 control ID's like AC-3, CM-6 etc = and list the CCEs that map to it. And we also used the CCM (Cloud Control Matrix) mappings to NIST 800-53 = and to other regulatory standards and arrived at CCEs related to each = regulatory standard. We can now search for "pcidss cce" or "COBIT CCE", = for example. The objective is to arrive at common set of technical requirements for = each of the regulatory standard and hence the mapping to CCE.=20 Thanks to Luis and Cloud Security Alliance.=20 As a next step, we took up an exercise to map individual regulatory = requirements to the right CCEs and started with NERC CIP to CCE mapping. = If there is any interest in this work or any collaboration possibility, = we would be happy to work together, please mail me.=20 Thanks, Chandra. -----Original Message----- From: scap_interest-bounces@ietf.org = [mailto:scap_interest-bounces@ietf.org] On Behalf Of Luis Nunez Sent: Wednesday, February 15, 2012 2:47 AM To: Adam Montville Cc: scap_interest@ietf.org 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, >=20 > I had a brief discussion with several members of this list with=20 > 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. >=20 > From an automation perspective, it seems that some method of being=20 > 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. >=20 > Is there any interest in being able to represent a compliance=20 > 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 = )? >=20 > Or, is this type of representation simply not needed - there's enough there, the present demand doesn't justify the work, or something else? >=20 > Thoughts? >=20 > Regards, >=20 > Adam W. Montville | Security and Compliance Architect >=20 > Direct: 503 276-7661 > Mobile: 360 471-7815 >=20 > TRIPWIRE | Take CONTROL > http://www.tripwire.com =20 >=20 > _______________________________________________ > scap_interest mailing list > scap_interest@ietf.org > https://www.ietf.org/mailman/listinfo/scap_interest _______________________________________________ scap_interest mailing list scap_interest@ietf.org https://www.ietf.org/mailman/listinfo/scap_interest ----- No virus found in this message. Checked by AVG - www.avg.com =20 Version: 2012.0.2197 / Virus Database: 2437/5207 - Release Date: = 08/18/12 _____ =20 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2742 / Virus Database: 2617/5856 - Release Date: = 10/26/12 ------=_NextPart_000_020B_01CDB6D7.5FCD0CF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

David,

 

Comments inline=E2=80=A6

 

From:= = david.oliva@verizon.net [mailto:david.oliva@verizon.net] =
Sent: Sunday, October 28, 2012 4:19 AM
To: = sacm@ietf.org; bchandra@secpod.com
Subject: SACM/CCE = terminology in other compliance frameworks

 

Ch= andra and all:

&n= bsp;

I = see this as a step in the right = direction.

&n= bsp;

Co= biT has a full spreadsheet mapping of their compliance requirements to = SP 800-53 (under research).  The "CobiT CCE" that = Chandra suggests is a good marketing idea in my = opinion.

 

This is very useful, do you have a link for the CobiT to 800-53 = mappings?

 

I = do not know that PCI-DSS has been mapped to SP 800-53, but the = "pcidss CCE" is also a new interesting idea (opinion = also).

&n= bsp;

Ho= wever, I see SACM product capabilities as a "scan-once and map to = any compliance model" strategy.

Th= e "CCE to other compliance models" can only be achieved with = SP 800-53 to other compliance model = mappings.

=  

Good idea! If all compliance model map to SP 800-53, which would = in-turn allows us to reach to the CCEs.

 

Th= e mappings will probably be a springboard for vendors to make their = products relevant to organizations needing to comply with governance = models other than FISMA.

&n= bsp;

No= tetworthy and of marketting value for international business is that, = for semi-automatable compliance requirements, they can use = SACM/OCIL.

&n= bsp;

I = also would like to emphasize that SCAP content and SCAP products that = can map to governance compliance models are tier IV (as specified = in SP 800-70)

&n= bsp;

Da= vid Oliva

&n= bsp;

 


-----Original Message-----
From: Chandrashekhar B = [mailto:bchandra@secpod.com]
Sent: Wednesday, = October 24, 2012 2:52 AM
To: 'Luis Nunez'; 'Adam Montville'
Cc: = SCAP-DEV; scap_interest@ietf.org; sacm@ietf.org
Subject: Re: [sacm] = [scap_interest] Just throwing this out there: Compliance = Frameworks

Hello All,

We used the NIST 800-53 - CCE = mappings
(http://static.nvd.nist.gov/feeds/xml/cce/nvdcce-0.1-fee= d.xml) and incorporated this into the CCEs reference in SCAP Repo = (www.scaprepo.com).
We can now search based on = the 800-53 control ID's like AC-3, CM-6 etc and list the CCEs that map = to it.

And we also used the CCM (Cloud Control Matrix) mappings = to NIST 800-53 and to other regulatory standards and arrived at CCEs = related to each regulatory standard. We can now search for "pcidss = cce" or "COBIT CCE", for example.
The objective is to = arrive at common set of technical requirements for each of the = regulatory standard and hence the mapping to CCE.

Thanks to Luis = and Cloud Security Alliance.

As a next step, we took up an = exercise to map individual regulatory requirements to the right CCEs and = started with NERC CIP to CCE mapping. If there is any interest in this = work or any collaboration possibility, we would be happy to work = together, please mail me. =

Thanks,
Chandra.

-----Original Message-----
From: = scap_interest-bounces@ietf.org [mailto:scap_interest-bounces@ietf.org]
On = Behalf Of Luis Nunez
Sent: Wednesday, February 15, 2012 2:47 = AM
To: Adam Montville
Cc: scap_interest@ietf.org
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
> scap_interest@ietf.org
> https://www.ietf.org/mailman/listinfo/scap_interest=

_______________________________________________
scap_interest = mailing list
scap_interest@ietf.org
https://www.ietf.org/mailman/listinfo/scap_interest=
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2197 / Virus = Database: 2437/5207 - Release Date: = 08/18/12


No virus = found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2742 / = Virus Database: 2617/5856 - Release Date: = 10/26/12

------=_NextPart_000_020B_01CDB6D7.5FCD0CF0--