Re: [sacm] SACM BoF Request

"Moriarty, Kathleen" <kathleen.moriarty@emc.com> Sun, 23 September 2012 15:13 UTC

Return-Path: <kathleen.moriarty@emc.com>
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 A9AB521F84EA for <sacm@ietfa.amsl.com>; Sun, 23 Sep 2012 08:13:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Level:
X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_00=-2.599, LONGWORDS=1.803]
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 sH48OZh3sPpY for <sacm@ietfa.amsl.com>; Sun, 23 Sep 2012 08:13:01 -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 1A58D21F84E4 for <sacm@ietf.org>; Sun, 23 Sep 2012 08:13:00 -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 q8NFCm2h031161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Sep 2012 11:12:58 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Sun, 23 Sep 2012 11:12:41 -0400
Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q8NFCedB013037; Sun, 23 Sep 2012 11:12:40 -0400
Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Sun, 23 Sep 2012 11:12:40 -0400
From: "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
To: "Baker, Jon" <bakerj@mitre.org>, "Waltermire, David A." <david.waltermire@nist.gov>, "sacm@ietf.org" <sacm@ietf.org>
Date: Sun, 23 Sep 2012 11:12:38 -0400
Thread-Topic: SACM BoF Request
Thread-Index: Ac2PpI2xUd5L9DozTL2wga4UXLDq3gBPqh4QAdU48n4AThqt4AAKyOnw
Message-ID: <F5063677821E3B4F81ACFB7905573F2409292AF3@MX15A.corp.emc.com>
References: <66930F41F45C954AA119D59EE69C06E90C69E659DF@MBCLUSTER.xchange.nist.gov>, <D7A0423E5E193F40BE6E94126930C4930BA25D8895@MBCLUSTER.xchange.nist.gov> <F5063677821E3B4F81ACFB7905573F24092B0176@MX15A.corp.emc.com> <6C1C15D8B5510B4B8FF132B10D3865130225EE78@IMCMBX03.MITRE.ORG>
In-Reply-To: <6C1C15D8B5510B4B8FF132B10D3865130225EE78@IMCMBX03.MITRE.ORG>
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] 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\)." <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sacm>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Sep 2012 15:13:02 -0000

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.

BOF full name: Security Automation and Continuous Monitoring [SACM]
AREA: Security
BOF Chairs: Kathleen Moriarty (kathleen.moriarty@emc.com)
            David Waltermire (david.waltermire@nist.gov)
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 <stephen.farrell@cs.tcd.ie>
     Sean Turner <turners@ieca.com>

Security Area Advisor:
     Sean Turner <turners@ieca.com>

Mailing Lists:
     General Discussion: sacm@ietf.org
     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.

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.

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



Best regards,
Kathleen

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

>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: bakerj@mitre.org

>-----Original Message-----
>From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of
>Moriarty, Kathleen
>Sent: Friday, September 21, 2012 4:32 PM
>To: Waltermire, David A.; sacm@ietf.org
>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 (kathleen.moriarty@emc.com)
>            David Waltermire (david.waltermire@nist.gov)
>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 <stephen.farrell@cs.tcd.ie>
>     Sean Turner <turners@ieca.com>
>
>Security Area Advisor:
>     Sean Turner <turners@ieca.com>
>
>Mailing Lists:
>     General Discussion: sacm@ietf.org
>     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
>sacm@ietf.org
>https://www.ietf.org/mailman/listinfo/sacm
_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm