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: RE: [EXT] Re: [cacao] Remaining work items


Regarding the required/optional issue – as discussed on today’s call, we’d like to propose the following compromise:

 

- The playbook_functionalities property on Playbook is optional

- The playbook_functionalities description includes a normative "SHOULD" (i.e., “The values for this property SHOULD come from the playbook-function-type-ov open vocabulary.”)

- The function property on Command Data is required

 

Dez

 

From: cacao@lists.oasis-open.org <cacao@lists.oasis-open.org> On Behalf Of duncan sfractal.com
Sent: Thursday, October 27, 2022 4:26 PM
To: aa tt <atcyber1000@gmail.com>; Bret Jordan <jordan.oasisopen@gmail.com>
Cc: cacao@lists.oasis-open.org
Subject: [EXT] Re: [cacao] Remaining work items

 

On the required/ optional issue, I favor optional. I hear Allan’s arguments and I resonate with allowing new users to crawl before running. If it's that valuable the market will reward the optional feature. Remember customers can require optional features. It just means not everyone requires it in all cases.  Plus making required would be a breaking. Just my 2 cents. 

Duncan

 

 

 

iPhone, iTypo, iApologize


From: cacao@lists.oasis-open.org <cacao@lists.oasis-open.org> on behalf of aa tt <atcyber1000@gmail.com>
Sent: Thursday, October 27, 2022 3:04 PM
To: Bret Jordan <jordan.oasisopen@gmail.com>
Cc: cacao@lists.oasis-open.org <cacao@lists.oasis-open.org>
Subject: Re: [cacao] Remaining work items

 

Bret -

a) The writeup that I did on meta data remains open on adding to the spec or not as far I can tell from the last call.

b) The proposed feature on functionality is not yet completely specified. Whether we make it required or optional, it is missing a lot of the meta-data attribution/classificaiton information that the feature allows a user to specify. So at this very moment the proposal is not ready to add to the spec regardless of required/optional.

c) Adding this functionality feature brings in a lot of work upon playbook authors to define such functionality instead of focusing on the mechanics of defining a playbook in the 1st place. From my perspective it is a significant increase in the burden to do for every playbook and I’m not convinced all use cases will rely on it or want to have to do it. Therefore I was willing to support its inclusion in the spec (which it HAS NOT BEEN APPROVED) provided it is optional. However, if the proponents insist that this feature be required then I will say that the entire feature SHOULD NOT BE ADDED to the spec at all.

I’m a firm supporter of proving value in the marketplace and making the barrier to entry for using playbooks very low and easy. If an optional feature (any of them) gets used reliably and well in the marketplace then the outcome is the same.

The idea that a spec can force people to do something they don’t want to do is a fallacy. And increasing the complexity of CACAO playbooks even more than they already have is a mistake that will only result in the entire project being undermined.

Allan

> On Oct 27, 2022, at 10:23 AM, Bret Jordan <jordan.oasisopen@gmail.com> wrote:
>
> All,
>
> We have very few remaining work items that need to be addressed before we can ship the next version of the CACAO specification. We really need people to speak up and voice their opinions on the following:
>
> 1) MITRE/DHS has proposed a new property to track some of the features of a playbook. Several people seem to like this and support this. However, there is some concern on if this property should be "required" or if it should be "optional". Allan strongly views this should be optional. MITRE/DHS really want it to be required. But I have not heard from the rest of you.
>
> Please respond to this email with your views on this subject.
>
> 2) A while back Allan proposed the attack target types. I think we all generally agree that this is a good idea. However, when I have played around with it, it feels like there are some minor issues with the modeling. I have not yet been able to put my finger on it. To be clear I really like the idea of the Attack stuff that Allan proposed and really want it. But something just feels off with it. Has anyone else seen issues while playing around with it?
>
> Bret
>


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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