Subject: [sacm] FW: SACM BoF Request

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 12 Sep 2012 08:57:02 -0400

I sent in a request to hold a SACM BoF at the IETF 85 meeting in Atlanta, GA.  The details are below for anyone interested.  At this point we need to complete preparations for the BoF.  To be successful, we will need your participation in the BoF and your help getting ready.

Here are meeting details if you are interested in making travel arrangements:

http://www.ietf.org/meeting/85/index.html

At this point we need additional drafts to be submitted to augment the agenda and support the BoF.  I'd be happy to work with anyone interested in preparing drafts for any of the existing specifications in this area (e.g. CPE, Asset Identification, ARF, ASR, etc.)  We should probably do a direct conversion of existing specifications for -00 versions before making any changes.  The -00 deadline for the IETF 85 meeting is 10/15 with any updated drafts due a week later on 10/22.  Any volunteers?

We will also need speakers to present drafts.  Please let me or Kathleen know if you are interested in making a short presentation.

We also need to continue to refine the charter (included below) and use case documents. Any additional comments/changes would be appreciated.

Sincerely,
Dave

From: Waltermire, David A.
Sent: Monday, September 10, 2012 6:45 PM
To: [email-masked]'; [email-masked]'; 'Moriarty, Kathleen'
Subject: SACM BoF Request

Please find the our request for a WG formation BoF below.  I have also included a draft charter that we have been developing with feedback from the SACM list.  Please let me know if you have any questions or if you would like any additional details.

Sincerely,
Dave Waltermire

--

BOF full name: Security Automation and Continuous Monitoring [SACM]
AREA: Security
BOF Chairs: Kathleen Moriarty ([email-masked]<mailto:[email-masked]>)
            David Waltermire ([email-masked]<mailto:[email-masked]>)
Agenda:

* Review the draft charter
* Review draft-waltermire-sacm-use-cases-02
* Review drafts submitted in support of the charter
  - draft-waltermire-content-repository-00
  - More expected before -00 deadline

Full Description of BOF: The SACM BoF is intended to progress the work from the SACM mailing list to solidify discussions on a proposed charter, use cases and milestones in support of moving to an IETF working group.

CONFLICTS to avoid: SAAG, MILE
Expected Attendance: 40, not sure what the previous attendance was?
Special Requests: Meetecho support
Number of sessions: 1
Length of session: 2 hours

Draft Charter:

Proposed Working Group Charter

Chairs:
TBD
TBD

Security Area Directors:
     Stephen Farrell <[email-masked]<mailto:[email-masked]>>
     Sean Turner <[email-masked]<mailto:[email-masked]>>

Security Area Advisor:
     Sean Turner <[email-masked]<mailto:[email-masked]>>

Mailing Lists:
     General Discussion: [email-masked]<mailto:[email-masked]>
     To Subscribe:       http://www.ietf.org/mailman/listinfo/sacm
     Archive:            http://www.ietf.org/mail-archive/web/sacm

Description of Working Group

Securing information and the systems that store, process, and transmit that information has become a challenging task for organizations of all sizes, and we find that security practitioners spend most of their time on manual processes relegating them to ineffectiveness. Security automation to verify system configurations with the ability to prioritize risk based on increased situational awareness from shared intelligence is the key to escaping this rut. This working group will develop security automation standards in support of information security processes and practices where practical. These standards will help security practitioners to be better utilized within their organizations by automating routine tasks related to endpoint and server security so that practitioners can focus on more advanced tasks. The initial focus of this work is to address enterprise use cases.

The working group will achieve this by consuming shared intelligence and continuing (with cooperation) the security automation work already performed by various organizations around the world.  The initial work has been fruitful, and the data formats previously published are ready for expansion on the international stage. Of particular interest to this working group are the security automation specifications supporting asset, change, configuration, and vulnerability management. Of additional interest to this working group are the emerging security automation interfaces and data formats relating to event management and continuous assessment.  The continuous assessment capabilities enable organizational situational awareness through frequent snapshots of the operating state of their environment, with risk prioritized based on consumed information provided by shared intelligence (vulnerabilities, threats, etc.).

By undertaking this work, we recognize that there are multiple categories of problems in the security automation domain: defining expressions for particular domain concepts (i.e. data formats), establishing a standards-based foundation supporting the curation and exchange of security automation content collections in content repositories, and enabling interoperability through the development and use of standard interfaces and communications protocols. Content based on rich data standards and protocols will provide the authoritative instructions needed by data-driven tools to enable the automated collection and exchange of configuration and vulnerability data pertaining to enterprise assets. Information produced by these tools will provide accurate and timely situational awareness in support of organizational decision making.

This working group will provide solutions to these categories of problems and the main areas of focus for this working group are described as follows:

1. Define, either by normative reference, adoption, or creation, a set of standards that can be used for the purpose of assessing and aggregating device states and comparing these device states against expected values, and reporting on those results in a predefined or ad hoc manner.  This area of focus provides for necessary language and data format specifications.

2. Define, either by normative reference, adoption, or creation, a set of standards that can be used to continuously assess and report on the state of systems, composed of many different types of devices and networks, operated by varying personnel, to ensure security process effectiveness in a pre-defined or ad-hoc manner.  This area of focus provides for integration protocols supporting plug and play continuous assessment and security automation networking.

This working group will achieve the following milestones in two phases:

Phase One
- A Standards Track document specifying asset description format
- A Standards Track document specifying asset identification
- A Standards Track document specifying platform naming
- A Standards Track document specifying platform matching
- A Standards Track document specifying platform applicability
- A Standards Track document specifying a control framework representation format.
- A Standards Track document specifying benchmark configuration representation
- An Informational document stating guidelines / requirements for specifying checking languages
- Standards Track documents specifying device state checking languages
- A Standards Track document specifying an interrogative checking language
- A Standards Track document specifying asset reporting information
- Standards Track document describing how to use the languages and other content defined in this group with the NEA protocols

Phase Two
- Standards Track document specifying security automation/continuous assessment interfaces
- A Standards Track document specifying communication protocols used for security automation and continuous assessment
- A Standards Track document describing the messages and network protocols for distributing security automation content  (content repository)
- A Standards Track document describing protocols and data formats for securely sharing dynamic network state information among security systems

---

From: "Adam W. Montville" <[email-masked]>
Date: Wed, 12 Sep 2012 07:16:32 -0700

Thank you Dave!

I'd be happy to pick up Asset ID.

Sent from my iPhone

On Sep 12, 2012, at 5:57 AM, "Waltermire, David A." <[email-masked]> wrote:

> At this point we need additional drafts to be submitted to augment the agenda and support the BoF.  I’d be happy to work with anyone interested in preparing drafts for any of the existing specifications in this area (e.g. CPE, Asset Identification, ARF, ASR, etc.)  We should probably do a direct conversion of existing specifications for -00 versions before making any changes.  The -00 deadline for the IETF 85 meeting is 10/15 with any updated drafts due a week later on 10/22.  Any volunteers?
>  
> BOF Chairs: Kathleen Moriarty ([email-masked])
>             David Waltermire ([email-masked])
> Agenda:
>  
>      Stephen Farrell <[email-masked]>
>      Sean Turner <[email-masked]>
>  
> Security Area Advisor:
>      Sean Turner <[email-masked]>
>  
> Mailing Lists:
>      General Discussion: [email-masked]
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: "Waltermire, David A." <[email-masked]>
Date: Wed, 12 Sep 2012 10:43:26 -0400

Adam,

Thanks for agreeing to work on this.  If you don’t mind, I’d like to take the approach of converting the document as-is for the -00 draft.  If any changes are desired, we can then discuss them on the mailing list, develop consensus, and then update the documents to reflect the consensus.  That way everyone has input into what ends up in the specifications.  We may need to take some liberties with diagrams or data tables that may not convert well.  I’d be happy to help you work through these kinds of issues.

Sincerely,
Dave

From: Adam W. Montville [mailto:[email-masked]]
Sent: Wednesday, September 12, 2012 10:17 AM
To: Waltermire, David A.
Cc: [email-masked]
Subject: Re: [sacm] FW: SACM BoF Request

Thank you Dave!

Sent from my iPhone

On Sep 12, 2012, at 5:57 AM, "Waltermire, David A." <[email-masked]<mailto:[email-masked]>> wrote:
I sent in a request to hold a SACM BoF at the IETF 85 meeting in Atlanta, GA.  The details are below for anyone interested.  At this point we need to complete preparations for the BoF.  To be successful, we will need your participation in the BoF and your help getting ready.

Sincerely,
Dave

From: Waltermire, David A.
Sent: Monday, September 10, 2012 6:45 PM
To: [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'; 'Moriarty, Kathleen'
Subject: SACM BoF Request

Sincerely,
Dave Waltermire

--

Draft Charter:

Chairs:
TBD
TBD

Security Area Directors:

Security Area Advisor:

Mailing Lists:

Phase One

Phase Two

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

---

From: Adam Montville <[email-masked]>
Date: Wed, 12 Sep 2012 14:45:59 +0000

From: <Waltermire>, "David A." <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 12, 2012 7:43 AM
To: "Adam W. Montville" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] FW: SACM BoF Request

Adam,

No problem – happy to help.  I think that approach is appropriate, and should apply to any of the documents we intend to bring in.

Sincerely,
Dave

From: Adam W. Montville [mailto:[email-masked]]
Sent: Wednesday, September 12, 2012 10:17 AM
To: Waltermire, David A.
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] FW: SACM BoF Request

Thank you Dave!

Sent from my iPhone

Sincerely,
Dave

Sincerely,
Dave Waltermire

--

Draft Charter:

Chairs:
TBD
TBD

Security Area Directors:

Security Area Advisor:

Mailing Lists:

Phase One

Phase Two

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Fri, 21 Sep 2012 16:31:38 -0400

Hello,

I am including an updated version of the SACM Charter that includes more of an emphasis on the protocols to share and exchange data within and between enterprises/organizations.  Please feel free to provide feedback to the list!

Thanks & have a good weekend!
Kathleen

Draft Charter:

Chairs:
TBD
TBD

Security Area Directors:

Security Area Advisor:

Mailing Lists:

Securing information and the systems that store, process, and transmit that information has become a challenging task for organizations of all sizes, and we find that security practitioners spend most of their time on manual processes relegating them to ineffectiveness. Security automation to verify system configurations with the ability to prioritize risk based on increased situational awareness from shared intelligence is the key to escaping this rut. This working group will develop security automation protocols and data format standards in support of information security processes and practices where practical. These standards will help security practitioners to be better utilized within their organizations by automating routine tasks related to endpoint and server security so that practitioners can focus on more advanced tasks. The initial focus of this work is to address enterprise use cases.

The working group will achieve this by enabling the exchange of shared intelligence and continuing the security automation work already performed by various organizations around the world.  The initial work has been fruitful, and the data formats previously published are ready for expansion on the international stage. Of particular interest to this working group are the security automation specifications supporting asset, change, configuration, and vulnerability management. Of additional interest to this working group are the emerging security automation interfaces and data formats relating to event management and continuous assessment.  The continuous assessment capabilities enable organizational situational awareness through frequent snapshots of the operating state of their environment, with risk prioritized based on consumed information provided by shared intelligence (vulnerabilities, threats, etc.).

By undertaking this work, we recognize that there are multiple categories of problems in the security automation domain: enabling interoperable data exchanges through standardized protocols, defining expressions for particular domain concepts (i.e. data formats), establishing a standards-based foundation supporting the curation and exchange of security automation content collections in content repositories, and enabling interoperability through the development and use of standard interfaces and communications protocols. Content based on rich data standards and protocols will provide the authoritative instructions needed by data-driven tools to enable the automated collection and exchange of configuration and vulnerability data pertaining to enterprise assets. Information produced by these tools will provide accurate and timely situational awareness in support of organizational decision making.

The data exchange protocols will need to meet several exchange types including those between and within organizations for sharing intelligence data to increase situational awareness, report exchanges both internal and external to an enterprise, and those between enterprise servers and end points for assessments

1. Define, either by normative reference, adoption, or creation, a set of standards to enable the exchange of data to increase situational awareness or gain access to shared content to improve the security posture of an enterprise.  This area of focus provides for the integration of interoperable protocols to access shared data repositories between organizations to increase situational awareness and reduce risks to an enterprise.  In support of accessing shared intelligence for expected system state and related risks, define, either by normative reference, adoption, or creation, a set of standards that can be used for the purpose of assessing and aggregating device states and comparing these device states against expected values, and reporting on those results in a predefined or ad hoc manner.  This area of focus provides for necessary language and data format specifications.

3. Define, either by normative reference, adoption, or creation, a set of standards that can be used to continuously assess and report on the state of systems, composed of many different types of devices and networks, operated by varying personnel, to ensure security process effectiveness in a pre-defined or ad-hoc manner.  This area of focus provides for integration protocols supporting plug and play continuous assessment and security automation networking within an enterprise.

Phase One
- A standards track document to define a protocol for interacting with content repositories

Phase Two

---

From: "Baker, Jon" <[email-masked]>
Date: Sun, 23 Sep 2012 09:51:25 +0000

>I am including an updated version of the SACM Charter that includes more of
>an emphasis on the protocols to share and exchange data within and between
>enterprises/organizations.

Why the shift in emphasis to sharing and exchanging data between organizations? This seems to be new to this group.

Also in the section that lists the focus areas it looks like you intended for there to be three focus areas but accidently merged the second focus area into the first. Your wording in the first focus area appears to start describing a new focus area and your number goes from 1 to 3 skipping number 2.

Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [email-masked]

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Moriarty, Kathleen
>Sent: Friday, September 21, 2012 4:32 PM
>To: Waltermire, David A.; [email-masked]
>Subject: Re: [sacm] SACM BoF Request
>
>Hello,
>
>I am including an updated version of the SACM Charter that includes more of
>an emphasis on the protocols to share and exchange data within and between
>enterprises/organizations.  Please feel free to provide feedback to the list!
>
>Full Description of BOF: The SACM BoF is intended to progress the work from
>the SACM mailing list to solidify discussions on a proposed charter, use cases
>and milestones in support of moving to an IETF working group.
>
>Securing information and the systems that store, process, and transmit that
>information has become a challenging task for organizations of all sizes, and
>we find that security practitioners spend most of their time on manual
>processes relegating them to ineffectiveness. Security automation to verify
>system configurations with the ability to prioritize risk based on increased
>situational awareness from shared intelligence is the key to escaping this rut.
>This working group will develop security automation protocols and data
>format standards in support of information security processes and practices
>where practical. These standards will help security practitioners to be better
>utilized within their organizations by automating routine tasks related to
>endpoint and server security so that practitioners can focus on more
>advanced tasks. The initial focus of this work is to address enterprise use
>cases.
>
>The working group will achieve this by enabling the exchange of shared
>intelligence and continuing the security automation work already performed
>by various organizations around the world.  The initial work has been fruitful,
>and the data formats previously published are ready for expansion on the
>international stage. Of particular interest to this working group are the
>security automation specifications supporting asset, change, configuration,
>and vulnerability management. Of additional interest to this working group
>are the emerging security automation interfaces and data formats relating to
>event management and continuous assessment.  The continuous assessment
>capabilities enable organizational situational awareness through frequent
>snapshots of the operating state of their environment, with risk prioritized
>based on consumed information provided by shared intelligence
>(vulnerabilities, threats, etc.).
>
>By undertaking this work, we recognize that there are multiple categories of
>problems in the security automation domain: enabling interoperable data
>exchanges through standardized protocols, defining expressions for particular
>domain concepts (i.e. data formats), establishing a standards-based
>foundation supporting the curation and exchange of security automation
>content collections in content repositories, and enabling interoperability
>through the development and use of standard interfaces and communications
>protocols. Content based on rich data standards and protocols will provide the
>authoritative instructions needed by data-driven tools to enable the
>automated collection and exchange of configuration and vulnerability data
>pertaining to enterprise assets. Information produced by these tools will
>provide accurate and timely situational awareness in support of organizational
>decision making.
>
>The data exchange protocols will need to meet several exchange types
>including those between and within organizations for sharing intelligence data
>to increase situational awareness, report exchanges both internal and
>external to an enterprise, and those between enterprise servers and end
>points for assessments
>
>This working group will provide solutions to these categories of problems and
>the main areas of focus for this working group are described as follows:
>
>1. Define, either by normative reference, adoption, or creation, a set of
>standards to enable the exchange of data to increase situational awareness or
>gain access to shared content to improve the security posture of an
>enterprise.  This area of focus provides for the integration of interoperable
>protocols to access shared data repositories between organizations to
>increase situational awareness and reduce risks to an enterprise.  In support
>of accessing shared intelligence for expected system state and related risks,
>define, either by normative reference, adoption, or creation, a set of
>standards that can be used for the purpose of assessing and aggregating
>device states and comparing these device states against expected values, and
>reporting on those results in a predefined or ad hoc manner.  This area of
>focus provides for necessary language and data format specifications.
>
>3. Define, either by normative reference, adoption, or creation, a set of
>standards that can be used to continuously assess and report on the state of
>systems, composed of many different types of devices and networks,
>operated by varying personnel, to ensure security process effectiveness in a
>pre-defined or ad-hoc manner.  This area of focus provides for integration
>protocols supporting plug and play continuous assessment and security
>automation networking within an enterprise.
>
>- A Standards Track document specifying communication protocols used for
>security automation and continuous assessment
>- A Standards Track document describing the messages and network protocols
>for distributing security automation content  (content repository)
>- A Standards Track document describing protocols and data formats for
>securely sharing dynamic network state information among security systems
>- Standards Track document describing how to use the languages and other
>content defined in this group with the NEA protocols

---

From: "Baker, Jon" <[email-masked]>
Date: Sun, 23 Sep 2012 09:58:33 +0000

>- A Standards Track document specifying platform applicability

Those seem to roughly align with CPE Naming, CPE Matching, CPE Applicability Language. Has the group considered the SWID specification (ISO/IEC 19770-2). The following page and its referenced document may be of help in considering how cpe and swids fit together:

http://tagvault.org/Automating_CPE_name_creation

Jon

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Sun, 23 Sep 2012 11:12:38 -0400

Hi Jon,

Thank you for your comments!  The data formats enable communication between entities, but without common protocols, we will miss the opportunity to create interoperability between vendor products.  We do want to enable intelligence feeds and common reporting methods, even if it is to point to other efforts like GRC Exchange.  The repository work could benefit from common access methods to address one of the additions.  The IETF is good at protocols and the SACM community is good at data formats to enable automated security. In bringing these groups together, we should try to take advantage of the expertise of the IETF to more fully solve the problem space.  As I found out with RFC6545, people will point out things needed for interoperability for which others deep in a problem space may not be aware.

Thanks for the catch on two versus three, just trying to make sure people are reading ;-)  LOL

A corrected version is listed below, with the exception of how to deal with the platform naming.  In either case, whatever we select will likely be by reference (SWID or CPE).  I like the SWID approach, but we'll need more discussion on that.

Draft Charter:

Chairs:
TBD
TBD

Security Area Directors:

Security Area Advisor:

Mailing Lists:

2. Define, either by normative reference, adoption, or creation, a set of standards that can be used to continuously assess and report on the state of systems, composed of many different types of devices and networks, operated by varying personnel, to ensure security process effectiveness in a pre-defined or ad-hoc manner.  This area of focus provides for integration protocols supporting plug and play continuous assessment and security automation networking within an enterprise.

Phase One
[- A Standards Track document specifying platform naming
- A Standards Track document specifying platform applicability]

Phase Two

Best regards,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Baker, Jon
Sent: Sunday, September 23, 2012 5:51 AM
To: Moriarty, Kathleen; Waltermire, David A.; [email-masked]
Subject: Re: [sacm] SACM BoF Request

Jon

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Sun, 23 Sep 2012 11:14:44 -0400

Hi Jon,

With the recent approval of CPE specifications by the ITU-T, these are now formal recommendations and I believe the full content was included in these Recommendations (5 total Recommendations), is that correct?  If the group were to select either CPE or SWID, it would need to be by reference now, correct?

Best regards,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Baker, Jon
Sent: Sunday, September 23, 2012 5:59 AM
To: Moriarty, Kathleen; Waltermire, David A.; [email-masked]
Subject: Re: [sacm] SACM BoF Request

Jon

---

From: Gunnar Engelbach <[email-masked]>
Date: Sun, 23 Sep 2012 13:02:38 -0400

This is looking really good, but I can also understand Jon's comment 
about the seeming focus on data interchange.

Before compliance, configuration, vulnerability, etc., data can be 
exchanged it first needs to be collected, and that collection not only 
needs to contain a certain minimum set of data elements that makes an 
unambiguous data interchange possible, but also needs to have some 
measure of trust so to how those data items were collected.

This is one of the strengths of XCCDF+OVAL.  The content is public and 
peer-reviewed for definitive data sources and the proper logic to get 
the most accurate results so that software the fully implements these 
standards (as opposed to systems that simply map results to proprietary 
tests) then have the same level of accuracy as the content.

It might be taken as a given that XCCDF/OVAL or some such standard will 
be leveraged for the endpoint collection/evaluation, but I would prefer 
to see it explicitly stated as a necessary foundation for the rest.

--gun

---

From: Adam Montville <[email-masked]>
Date: Mon, 24 Sep 2012 14:12:08 +0000

On 9/23/12 8:14 AM, "Moriarty, Kathleen" <[email-masked]> wrote:

>Hi Jon,
>
>With the recent approval of CPE specifications by the ITU-T, these are
>now formal recommendations and I believe the full content was included in
>these Recommendations (5 total Recommendations), is that correct?  If the
>group were to select either CPE or SWID, it would need to be by reference
>now, correct?

When you say "or" in the last sentence above, are you suggesting that we'd
reference one or the other, or is it inclusive?

>Baker, Jon
>Those seem to roughly align with CPE Naming, CPE Matching, CPE
>Applicability Language. Has the group considered the SWID specification
>(ISO/IEC 19770-2). The following page and its referenced document may be
>of help in considering how cpe and swids fit together:
>
>>- A standards track document to define a protocol for interacting with
>>content
>>repositories
>>- A Standards Track document specifying a control framework
>>representation
>>format.
>>- An Informational document stating guidelines / requirements for
>>specifying
>>checking languages

---

From: "Martin, Robert A." <[email-masked]>
Date: Tue, 25 Sep 2012 09:15:27 -0400

Hi Kathleen,

Regarding your statement "I believe the full content was included in 
these Recommendations (5 total Recommendations), is that correct?"

No.

The normative portions are references to the 4 NIST IRs - in the same 
manner as was done for IODEF, RID, RID-T, and XCCDF.

If you Google x.cpe.1, x.cpe.2, x.cpe.3, and x.cpe.4 you will find links 
to the four documents and their summary sections that state the approach 
taken.

Specifically for X.1528.1 (ex X.cpe.1): "...This is achieved by listing 
the relevant clauses of the NIST Interagency Report 7696 Common Platform 
Enumeration: Name Matching Specification version 2.3 and showing whether 
they are normative or informative."

Specifically for X.1528.2 (ex X.cpe.2): "...This is achieved by listing 
the relevant clauses of the NIST Interagency Report 7696 Common Platform 
Enumeration: Name Matching Specification version 2.3 and showing whether 
they are normative or informative."

Specifically for X.1528.3 (ex X.cpe.3): "...This is achieved by listing 
the relevant clauses of the NIST Interagency Report 7697 Common Platform 
Enumeration: Name Matching Specification version 2.3 and showing whether 
they are normative or informative."

Specifically for X.1528.4 (ex X.cpe.4): "...This is achieved by listing 
the relevant clauses of the NIST Interagency Report 7698: Common 
Platform Enumeration Applicability Language Specification version 2.3 
and showing whether they are normative or informative."

Regards,

Bob

On 9/23/12 11:14 AM, Moriarty, Kathleen wrote:
> .

---

From: Sean Turner <[email-masked]>
Date: Tue, 25 Sep 2012 16:25:37 -0400

Jon,

The protocol bullets were added at the request of both Security ADs. 
The IETF uses the 5 questions in s1 of 
https://datatracker.ietf.org/doc/rfc5434/ when determining whether to 
charter a WG.  If there's no protocol work to be done in the somewhat 
near future, then we'll have a debate early on in the BOF about what the 
answer to question 1 part b is because that's basically what the IETF 
does best/most.   I also say this because it takes on average 3 years 
from the start of a WG to it publishing it's first RFC.  SMIME took 2 
years 5 months from the day it was started until RFC3850 was published 
(and that was after RSA gave change control) and TLS 1.0 took 2 years 1 
month. If we're going to spend three years arguing about schema and 
naming before getting to protocol design ...

I'm not saying a WG can't form without protocol work, but there will 
certainly be less resistance if protocol work is part of the initial set 
of deliverables.

spt

---

From: "Baker, Jon" <[email-masked]>
Date: Wed, 26 Sep 2012 01:55:25 +0000

Sean, 

Thanks for pointing out the rfc. It was helpful for me to what goes into a well-run BoF..

Also, thank you for explaining why the protocol bullets were added. In the original announcement the addition seemed to come somewhat out of nowhere. I may have missed it on the list, but I had not seen it discussed. 

Thanks,

Jon

>From: Sean Turner [mailto:[email-masked]]
>Sent: Tuesday, September 25, 2012 4:26 PM
>To: Baker, Jon
>Cc: [email-masked]
>> Thank you for your comments!  The data formats enable communication
>between entities, but without common protocols, we will miss the
>opportunity to create interoperability between vendor products.  We do want
>to enable intelligence feeds and common reporting methods, even if it is to
>point to other efforts like GRC Exchange.  The repository work could benefit
>from common access methods to address one of the additions.  The IETF is
>good at protocols and the SACM community is good at data formats to enable
>automated security. In bringing these groups together, we should try to take
>advantage of the expertise of the IETF to more fully solve the problem space.
>As I found out with RFC6545, people will point out things needed for
>interoperability for which others deep in a problem space may not be aware.
>>
>> A corrected version is listed below, with the exception of how to deal with
>the platform naming.  In either case, whatever we select will likely be by
>reference (SWID or CPE).  I like the SWID approach, but we'll need more
>discussion on that.
>>
>> Full Description of BOF: The SACM BoF is intended to progress the work
>from the SACM mailing list to solidify discussions on a proposed charter, use
>cases and milestones in support of moving to an IETF working group.
>>
>> This working group will provide solutions to these categories of problems
>and the main areas of focus for this working group are described as follows:
>>
>> 2. Define, either by normative reference, adoption, or creation, a set of
>content repositories
>> - A Standards Track document describing the messages and network
>protocols for distributing security automation content  (content repository)
>representation format.
>specifying checking languages
>> Why the shift in emphasis to sharing and exchanging data between
>organizations? This seems to be new to this group.
>>
>> Also in the section that lists the focus areas it looks like you intended for
>there to be three focus areas but accidently merged the second focus area
>into the first. Your wording in the first focus area appears to start describing a
>new focus area and your number goes from 1 to 3 skipping number 2.
>>
>> Jon
>>

---

From: Sean Turner <[email-masked]>
Date: Tue, 25 Sep 2012 22:01:04 -0400

No worries it did kind of come out of nowhere ;)

Tomorrow is the IESG/IAB BOF coordination call where we discuss all the 
proposed BOFs for IETF 85 (https://wiki.tools.ietf.org/bof/trac/). 
After the call, I'll post a summary of what transpired wrt this BOF 
proposal.

spt

On 9/25/12 9:55 PM, Baker, Jon wrote:
>> from
>> and
>> protocols

---

From: "Baker, Jon" <[email-masked]>
Date: Wed, 26 Sep 2012 02:06:52 +0000

In your message below, you say "select either CPE or SWID". I really have not looked at it as a one or the other decision. 

I believe that there remains a need for both efforts. SWIDs are well suited for identifying specific instances of installed software all the way down to the patch level. However, SWIDS are not currently designed to support what we have referred to as abstract names like "Windows 7". Security guidance is generally written to target these sorts of abstractions. Vulnerability information is often reported and shared using these sorts of abstractions. For example, "Flash 1.2.3 has a zero day vulnerability that is actively being exploited." Enterprise reporting also tends to leverage this abstraction capability. To make this work you end up needing a way to determine if one name matches another (CPE Matching Spec) and a way to state that something (benchmark/vulnerability/etc) applies to a given platform (CPE Applicability). 

I think there is a near and medium term need for both efforts. There has also been a lot of recent work to harmonize the efforts. 

Jon

>From: Moriarty, Kathleen [mailto:[email-masked]]
>Sent: Sunday, September 23, 2012 11:15 AM
>To: Baker, Jon; Waltermire, David A.; [email-masked]
>Subject: RE: SACM BoF Request
>
>Hi Jon,
>
>With the recent approval of CPE specifications by the ITU-T, these are now
>formal recommendations and I believe the full content was included in these
>Recommendations (5 total Recommendations), is that correct?  If the group
>were to select either CPE or SWID, it would need to be by reference now,
>correct?
>
>Best regards,
>Kathleen
>
>Those seem to roughly align with CPE Naming, CPE Matching, CPE Applicability
>Language. Has the group considered the SWID specification (ISO/IEC 19770-2).
>The following page and its referenced document may be of help in
>considering how cpe and swids fit together:
>

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Tue, 25 Sep 2012 22:27:13 -0400

Thanks for the explanation.  I would like to hear from more folks to ensure we work to developing consensus on the approach.  The main focus should be on the charter to ensure we are able to achieve the charter objectives and associated milestones to fulfill the agreed upon use cases.  I will help with gathering the consensus on the charter discussions.

For those new to a list like SACM, a "+1" is enough to show support for a response/approach or providing alternate opinions and approaches are also welcome.

My responses will be a little delayed over the next few days.

Thank you!
Kathleen  

Sent from my iPhone

---

From: Adam Montville <[email-masked]>
Date: Wed, 26 Sep 2012 03:36:42 +0000

On 9/25/12 7:06 PM, "Baker, Jon" <[email-masked]> wrote:

>In your message below, you say "select either CPE or SWID". I really have
>not looked at it as a one or the other decision.
>
>I believe that there remains a need for both efforts. SWIDs are well
>suited for identifying specific instances of installed software all the
>way down to the patch level. However, SWIDS are not currently designed to
>support what we have referred to as abstract names like "Windows 7".
>Security guidance is generally written to target these sorts of
>abstractions. Vulnerability information is often reported and shared
>using these sorts of abstractions. For example, "Flash 1.2.3 has a zero
>day vulnerability that is actively being exploited." Enterprise reporting
>also tends to leverage this abstraction capability. To make this work you
>end up needing a way to determine if one name matches another (CPE
>Matching Spec) and a way to state that something
>(benchmark/vulnerability/etc) applies to a given platform (CPE
>Applicability). 
>
>I think there is a near and medium term need for both efforts. There has
>also been a lot of recent work to harmonize the efforts.

>From your description, it seems that SWIDs are more specific than CPEs,
and you have made a clear case in favor of leveraging CPE.  How would we
leverage SWIDs?  I ask because I am more familiar with CPEs than I am with
SWIDs, and I think I see an overlap, but not sure why both would be needed
(not saying they couldn't be - just asking what your full perspective is).

>>now
>>Applicability
>>>protocols. Content based on rich data standards and protocols will
>>>provide
>>the
>>>including those between and within organizations for sharing
>>>intelligence
>>data
>>>standards to enable the exchange of data to increase situational
>>>awareness
>>or

---

From: "Baker, Jon" <[email-masked]>
Date: Wed, 26 Sep 2012 10:00:35 +0000

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. 

SWIDs are essentially an xml file created when a package is installed that can contain detailed information about that package and some of the configuration options that were selected at install time. They are tied to a specific package and can be updated when patches are installed. The SWID may contain the name version and publisher of the software as well as installation files and their hashes, registry keys created, etc. This then can give you a fairly detailed description of the installed software on a system to support a number of use cases. 

The tagvault website has a paper that talks about the connection between swids and cpe:
http://tagvault.org/Automating_CPE_name_creation

Jon

>From: Adam Montville [mailto:[email-masked]]
>Sent: Tuesday, September 25, 2012 11:37 PM
>To: Baker, Jon; Moriarty, Kathleen; Waltermire, David A.; [email-masked]

---

From: "Jan-Oliver Wagner" <[email-masked]>
Date: Wed, 26 Sep 2012 12:28:34 +0200

> 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 SWI…

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

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 26 Sep 2012 07:53:40 -0400

Please DO jump into any of the IETF lists where you want to voice an opinion or support!  Thank you!

We are working to develop the charter for this list to become a working group and it is important to reach rough consensus from the participants who will drive and use the results.

Is there more support for both or other opinions?

Thanks,
Kathleen

Sent from my iPhone

---

From: "Adam W. Montville" <[email-masked]>
Date: Wed, 26 Sep 2012 05:16:55 -0700

> Please DO jump into any of the IETF lists where you want to voice an opinion or support!  Thank you!

+1

---

From: Adam Montville <[email-masked]>
Date: Wed, 26 Sep 2012 13:23:15 +0000

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" <[email-masked]<mailto:[email-masked]>> wrote: