Re: [Cacao] Updated Charter version 03

<mohamed.boucadair@orange.com> Fri, 08 March 2019 07:06 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: cacao@ietfa.amsl.com
Delivered-To: cacao@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5E6130EC1 for <cacao@ietfa.amsl.com>; Thu, 7 Mar 2019 23:06:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dk0EWovHxnxa for <cacao@ietfa.amsl.com>; Thu, 7 Mar 2019 23:06:01 -0800 (PST)
Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75A04130E09 for <cacao@ietf.org>; Thu, 7 Mar 2019 23:06:01 -0800 (PST)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 44Fz6v59qfz4wt2; Fri, 8 Mar 2019 08:05:59 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 44Fz6v4Dnzz8sY5; Fri, 8 Mar 2019 08:05:59 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM41.corporate.adroot.infra.ftgroup ([fe80::857d:4f67:b0a7:10d7%21]) with mapi id 14.03.0439.000; Fri, 8 Mar 2019 08:05:59 +0100
From: mohamed.boucadair@orange.com
To: Bret Jordan <jordan.ietf@gmail.com>, "cacao@ietf.org" <cacao@ietf.org>
CC: JACQUENET Christian TGI/OLN <christian.jacquenet@orange.com>
Thread-Topic: [Cacao] Updated Charter version 03
Thread-Index: AQHUucBI05+BX76iFEiRETSb1NhehKYBe/bw
Date: Fri, 08 Mar 2019 07:05:59 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA35D68@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <F53E8B84-2905-4418-A232-FCFFA587135A@gmail.com>
In-Reply-To: <F53E8B84-2905-4418-A232-FCFFA587135A@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EA35D68OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cacao/6jPvtjdsam0J9OAc1iIkQLcMLFE>
Subject: Re: [Cacao] Updated Charter version 03
X-BeenThere: cacao@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Collaborative Automated Course of Action Operations <cacao.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cacao>, <mailto:cacao-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cacao/>
List-Post: <mailto:cacao@ietf.org>
List-Help: <mailto:cacao-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cacao>, <mailto:cacao-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Mar 2019 07:06:05 -0000

Hi Bret,

Thank you for taking my comments shared on an earlier version of the draft charter.

Please see inline.

Cheers,
Med

De : Cacao [mailto:cacao-bounces@ietf.org] De la part de Bret Jordan
Envoyé : vendredi 1 février 2019 00:54
À : cacao@ietf.org
Objet : [Cacao] Updated Charter version 03

All,

Thanks for all of the great feedback on the charter text.  We have updated the document to address all comments that we have received and are releasing a new version of the text.  You can see it here: https://datatracker.ietf.org/doc/draft-jordan-cacao-charter/ and copied below.


### BEGIN

# Introduction
To defend against threat actors and their tactics, techniques, and procedures, organizations need to manually identify, create, and document prevention, mitigation, and remediation steps.
[Med]
OLD:
  need to manually identify, create, and document prevention, mitigation, and remediation steps
NEW
 usually identify, create, document, and update prevention, mitigation, and remediation steps.

These steps when grouped together into a course of action (COA) / playbook are used to protect systems, networks, data, and users. The problem is, once these steps have been created there is no standardized and structured way to document them,

[Med] s/to document them/ to document and udpate them

verify they were correctly executed, or easily share them across organizational boundaries and technology stacks.

[Med] Why "and technology stacks" is mentioned here?

This working group will create a standard that implements the playbook model based on current industry best practices for cybersecurity.
[Med] s/cybersecurity/security

This solution will specifically enable:

1. the creation and documentation of COAs in a structured machine-readable format
2. organizations to perform attestations on COAs
3. the sharing and distribution of COAs across organizational boundaries and technology stacks
[Med] s/ organizational boundaries and technology stacks/boubndaries.
4. the verification of deployed COAs.


This solution will contain (at a minimum) a standard JSON based data model
[Med] I would vote for YANG as a data model (it can be augmented, obsoleted, etc.). Mapping to JSON is straightforward. We don't need IMO to pick a protocol in the charter.

, a defined set of functional capabilities and associated interfaces, and a mandatory to implement protocol. This solution will also provide a data model for actuators to confirm the status of the COA execution,
[Med] I'm not sure if that part of the architecture will require a specific data model or if protocol-related considerations are to be taken into account. I suggest to make this change:

s/provide a data model for actuators/ provide means for actuators.

however, it will be agnostic of how the COA is implemented by the actuator.
[Med] This text is redundant with "The working group will not consider how shared actions are used/enforced"

Each collaborative course of action will consist of a sequence of cyber defense actions
[Med] delete "cyber" (and in other parts of the text).

that can be executed by the various systems that can act on those actions. Further, these COAs will be coordinated and deployed across heterogeneous cyber security systems such that both the actions requested and the resultant outcomes may be verified. These COA actions will be referenceable in a connected data structure like the OASIS STIX V2 model that provides support for connected data such as threat actors, campaigns, intrusion sets, malware, attack patterns, and other adversarial techniques, tactics, and procedures (TTPs).

[Med] delete « TTPs ».


Where possible the working group will consider existing efforts, like OASIS OpenC2 and IETF I2NSF that define the atomic actions to be included in a process or sequence.
[Med] What is meant by "process" here?

The working group will not consider how shared actions are used/enforced, except where a response is expected for a specific action or step.
[Med] Detete "step".

# Goals and Deliverables
This working group has the following major goals and deliverables. Some of the deliverables may be published through the IETF RFC stream as informational or standards track documents.

- CACAO Use Cases and Requirements
  - Specify the use cases and requirements
- CACAO Functional Architecture: Roles and Interfaces
  - Specify the system functions and roles that are needed to enable Collaborative Courses of Action
- CACAO Protocol Specification
  - Specify and standardize the configuration for at least one protocol that can be used to distribute courses of action in both a direct delivery and publish-subscribe method
- CACAO Distribution and Response Application Layer Protocol
  - Identify and document the requirements to effectively report and alert on the deployment of CACAO actions and the potential threat response to those actions

[Med] I'm not sure I would maintain this one as a separate item. I suggest to merge this item with the previous one. It is too early to decide whether one or more protocols will be required.

- CACAO JSON Data Model
  - Create a JSON data model that can capture and enable collaborative courses of action

[Med] Please update to cover both YANG and JSON.

- CACAO Interoperability Test Documents
  - Define and create a series of tests and documents to assist with interoperability of the various systems involved.

[Med] It would be helpful to scope the work to identify one or two applicability threats that will be used to assess/validate the proposed solution. Instead of the test document, it suggest to have one or more applicability statements focusing on specific attacks.

The working group may decide to not publish the use cases and requirements and test documents as RFCs. That decision will be made during the lifetime of the working group.



### END


Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."