OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cacao message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Comments on Playbook Requirements


I apologize that I have let my voting rights lapse. If I could have voted, I would have voted yes with comments. My comments are:

In section 2.2, Interop 2, Extensions: I propose changing âSupport vendor-specific extensionsâ to âSupport industry-specific, enterprise-specific, and vendor-specific extensionsâ. My logic is the previous bullet says âSupport deployment and use within an enterprise consisting of different vendors. Allow sharing of playbooks between enterprises with different environments, solutions, and vendorsâ. I agree vendors will want to specify how to meet generic needs with their specific technology (the original wording) but I think that users might also need similar customizations (enterprise-specific) and that the ISACs/ISAOs might similarly also need customizations (industry-specific).

In section 2.10, Sec.2, Transport: âAll requests and responses must be conveyed over a secure (encrypted and authenticated) transport protocol such as HTTPS (but not limited).â â I think there are more cases than specified and not all cases in all situations have same the requirements.

  • Case 1: the playbook executor and device doing the action â I agree mutual authentication is required. I think non-repudiation is also required. I donât agree that confidentiality (ie encrypted channel) is required in all cases. I believe  there are cases in IoT where confidentiality is not required on the content (eg mass update to new software version) as long as integrity in maintained, and the cost of full encryption (in either processing or delay) would be higher than justified. Iâm thinking in particular of cases where SPA (single packet authentication) is used.
  • Case 2: playbook creator to playbook executor â I agree authentication of creator is required but not necessarily mutual authentication. I believe there would be cases where playbooks could be âpublicâ for anyone to view. I think non-repudiation of creator would always be required. And confidentiality (eg full encryption) would be unnecessary in some cases (eg âpublicâ), and required in others.

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

I welcome VSRE emails. Learn more at http://vsre.info/

 

 

From: <cacao@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Tuesday, March 17, 2020 at 7:35 PM
To: "cacao@lists.oasis-open.org" <cacao@lists.oasis-open.org>
Subject: Re: [cacao] Groups - Ballots opened: 2

 

As mentioned on the working call today, the Requirements and Terminology documents have been posted for ballot approval.

 

Both documents are committee notes and are stakes in the ground on what our specifications will deliver on.

 

The minutes from the call including the slides will be posted shortly if not already done.

 

For anyone not on the call today we would highly encourage you review the slides as we will be delivering a draft specification at the next working call.

 

Allan

 

From: <workgroup_mailer@lists.oasis-open.org> on behalf of "tc_admin@oasis-open.org" <tc_admin@oasis-open.org>
Date: Tuesday, March 17, 2020 at 3:09 PM
To: Allan Thomson <athomson@lookingglasscyber.com>
Subject: [cacao] Groups - Ballots opened: 2

 

THIS EMAIL ORIGINATES FROM OUTSIDE OF LOOKINGGLASS

"Approval of Playbook Requirements Version 1.0 WD 02 as Committee Note Draft 01" has opened.

Ballot Title: Approval of Playbook Requirements Version 1.0 WD 02 as Committee Note Draft 01



Question
Do you approve the Playbook Requirements Version 1.0 WD 02 as Committee Note Draft 01?

Closing Date: Wednesday, 1 April 2020 @ 10:00 pm EDT

Description
Do you approve Playbook Requirements Version 1.0 WD 02 and all associated artifacts packaged together in the release listed below as a Committee Note Draft and designate the MS Word version of the document as authoritative?



WD02 Release: https://www.oasis-open.org/committees/document.php?document_id=66717&wg_abbrev=cacao



This document defines the core requirements for how cyber security playbooks can be created, documented, and shared in a structured and standardized way across organizational boundaries and technological solutions.

Vote

  • Yes
  • No
  • Abstain

Group: OASIS Collaborative Automated Course of Action Operations (CACAO) for Cyber Security TC
Date Opened: Tuesday, 17 March 2020 @ 6:00 pm EDT


"Approval for Playbook Terminology Version 1.0 WD 01 as a Committee Note Draft 01" has opened.

Ballot Title: Approval for Playbook Terminology Version 1.0 WD 01 as a Committee Note Draft 01



Question
Do you approve Playbook Terminology Version 1.0 WD 01 and all associated artifacts as a Committee Note Draft 01?

Closing Date: Wednesday, 1 April 2020 @ 10:00 pm EDT

Description
Do you approve Playbook Terminology Version 1.0 WD 01 and all associated artifacts packaged together in the release listed below as a Committee Note Draft and designate the MS Word version of the document as authoritative?



WD01 Release: https://www.oasis-open.org/committees/document.php?document_id=66718&wg_abbrev=cacao



This document defines the terminology for cyber security playbooks.

Vote

  • Yes
  • No
  • Abstain

Group: OASIS Collaborative Automated Course of Action Operations (CACAO) for Cyber Security TC
Date Opened: Tuesday, 17 March 2020 @ 6:00 pm EDT

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]