Re: [sacm] SACM BoF Request

["Baker, Jon" <[e-mail]>]

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

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


>-----Original Message-----
>From: Moriarty, Kathleen [mailto:[e-mail]]
>Sent: Sunday, September 23, 2012 11:15 AM
>To: Baker, Jon; Waltermire, David A.; [e-mail]
>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
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Baker, Jon
>Sent: Sunday, September 23, 2012 5:59 AM
>To: Moriarty, Kathleen; Waltermire, David A.; [e-mail]
>Subject: Re: [sacm] SACM BoF Request
>
>Also, I noticed the following:
>
>>- A Standards Track document specifying platform naming
>>- A Standards Track document specifying platform matching
>>- 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
>
>============================================
>Jonathan O. Baker
>G022 - IA Industry Collaboration
>The MITRE Corporation
>Email: [e-mail]
>
>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>Moriarty, Kathleen
>>Sent: Friday, September 21, 2012 4:32 PM
>>To: Waltermire, David A.; [e-mail]
>>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!
>>
>>Thanks & have a good weekend!
>>Kathleen
>>
>>
>>
>>BOF full name: Security Automation and Continuous Monitoring [SACM]
>>AREA: Security
>>BOF Chairs: Kathleen Moriarty ([e-mail])
>>            David Waltermire ([e-mail])
>>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 <[e-mail]>
>>     Sean Turner <[e-mail]>
>>
>>Security Area Advisor:
>>     Sean Turner <[e-mail]>
>>
>>Mailing Lists:
>>     General Discussion: [e-mail]
>>     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 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.
>>
>>This working group will achieve the following milestones in two phases:
>>
>>Phase One
>>- A standards track document to define a protocol for interacting with
>content
>>repositories
>>- 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
>>- 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
>>
>>Phase Two
>>- 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
>>_______________________________________________
>>sacm mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/sacm
>_______________________________________________
>sacm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/sacm