OASIS Collaborative Automated Course of Action Operations (CACAO) for Cyber Secu

 View Only

  • 1.  Proposal for scheduling and repeating

    Posted 02-09-2025 17:42
    All,

    I have spent some time this weekend thinking about the various proposals we have seen and reflecting back on the discussions we have had in regards to enabling scheduling and repeating of steps / playbooks. 

    I would like to propose a different approach:

    1. We only enable this on the start step. This means it will effectively be at the playbook level and not at the individual step level. Nor is this going to effectively require a new object or wrapping the whole playbook in a while loop. I think this will solve a lot of the problems and weird corner cases.

    2. We add the following properties to the start step or at the playbook level.

    start_at (optional) - timestamp - the day and time this playbook should be started

    repeat_every (optional) - string enum - year, month, week, day, hour. If this is defined then the start_at MUST be defined.

    max_iterations (optional) - integer - The maximum number of times it should be run

    not_before (optional) - timestamp - Do not run this playbook before this day / time. So a playbook may be valid earlier and may not yet have expired, but your change management window may not be until Saturday night at 11:50 PM

    Properties we already have at the playbook level (section 3.1), if we put the others on the start step, then we may want to move these to the start step.

    valid_from (optional) - timestamp - the absolute day and time that this playbook may be run

    valid_until (optional) - timestamp - the absolute day and time that this playbook should no longer be run

    I think this will cover a lot of the use cases we talked about on the call, but with a much more simplified design.  Thoughts?


    Bret
     


  • 2.  RE: Proposal for scheduling and repeating

    Posted 02-10-2025 14:06
    Brett - While I agree we could simplify the proposal to only do repeatable playbooks I disagree with including the scheduling information inside the playbook that would run on the schedule. This makes playbooks less reusable and is much less flexible if you want to run the same playbook (e.g. checking status on various infrastructure systems) at different intervals or even on-demand (during an incident vs slower more regular checks once a day during non-incident times).

    I think its important the definition of the schedule is kept separate from the playbook for this reason.

    So this leaves us with "where" the definition of the schedule occurs.

    Currently there are 2 proposals and I think your proposal is really just a variant of those choices.

    1) Define a new object/step that defines the schedule of an action step (which could include launching a playbook or any other step if you wanted that flexibility), where this new schedule object introduces all the various parameters needed to define what schedule the contained action is executed on.

    - This option is effectively what both you and Lucas proposals are.

    2) Define new properties as part of the while loop step instead of a completely separate object. Still executes the contained action within the while but avoids a new object for the schedule itself.

    - This option is the one that I had proposed.

    At this point (cause we've been talking about this for weeks) I'm neutral on either option if we can get consensus on one of the options. However, I'm not for the option you proposed where the schedule is defined within the playbook itself.

    Allan

    On Feb 9, 2025, at 2:42 PM, Bret Jordan via OASIS <Mail@mail.groups.oasis-open.org> wrote:





    Original Message


  • 3.  RE: Proposal for scheduling and repeating

    Posted 02-10-2025 14:50
    I think Allan did hit on a key question we need to ask ourselves.  "Where" should the scheduling stuff be done.  Let me try to summarize just these options.

    0. In the playbook metadata (I am not a fan of this, and it seems Allan is not either, to be clear this is not what I was proposing)
    1. In an object (new object or a while step with optional properties) that exists BEFORE the start step
    2. As optional properties on the start step
    3. In an object (new object or a while step with optional properties) that exists AFTER the start step (at any place within the workflow) 
    4. As optional properties on all steps

    Personally, right now, without hearing other use cases and corner case problems, I am leaning towards option 2, where these properties are optional on the start step. I think over time we could add the ability to do scheduling of a branch or individual steps, but it feels like there are a lot of weird and hidden corner cases that we do not yet understand. 

    We will talk about this tomorrow and try and get consensus on this question first. Once we know that, it will influence the rest of the discussions. If you already have an opinion, please email it before tomorrow as that will speed up the discussions. The options are: 0,1,2,3,4, (and another if there is one I am missing)

    Bret



    On Mon, Feb 10, 2025 at 12:05 PM Allan Thomson via OASIS <Mail@mail.groups.oasis-open.org> wrote:
    Brett - While I agree we could simplify the proposal to only do repeatable playbooks I disagree with including the scheduling information inside... -posted to the "OASIS Collaborative Automated Course of Action Operations (CACAO) for Cyber Security" community

    OASIS Collaborative Automated Course of Action Operations (CACAO) for Cyber Secu

    Post New Message
    Re: Proposal for scheduling and repeating
    Reply to Group Reply to Sender via Email
    Feb 10, 2025 2:06 PM
    Allan Thomson
    Brett - While I agree we could simplify the proposal to only do repeatable playbooks I disagree with including the scheduling information inside the playbook that would run on the schedule. This makes playbooks less reusable and is much less flexible if you want to run the same playbook (e.g. checking status on various infrastructure systems) at different intervals or even on-demand (during an incident vs slower more regular checks once a day during non-incident times).

    I think its important the definition of the schedule is kept separate from the playbook for this reason.

    So this leaves us with "where" the definition of the schedule occurs.

    Currently there are 2 proposals and I think your proposal is really just a variant of those choices.

    1) Define a new object/step that defines the schedule of an action step (which could include launching a playbook or any other step if you wanted that flexibility), where this new schedule object introduces all the various parameters needed to define what schedule the contained action is executed on.

    - This option is effectively what both you and Lucas proposals are.

    2) Define new properties as part of the while loop step instead of a completely separate object. Still executes the contained action within the while but avoids a new object for the schedule itself.

    - This option is the one that I had proposed.

    At this point (cause we've been talking about this for weeks) I'm neutral on either option if we can get consensus on one of the options. However, I'm not for the option you proposed where the schedule is defined within the playbook itself.

    Allan

    On Feb 9, 2025, at 2:42 PM, Bret Jordan via OASIS <Mail@mail.groups.oasis-open.org> wrote:
      Reply to Group via Email   Reply to Sender via Email   View Thread   Recommend   Forward  

    Original Message



     
    You are subscribed to "OASIS Collaborative Automated Course of Action Operations (CACAO) for Cyber Secu" as bret.jordan.sdo@gmail.com. To change your subscriptions, go to My Subscriptions. To unsubscribe from this community discussion, go to Unsubscribe.



    Original Message:
    Sent: 2/10/2025 2:06:00 PM
    From: Allan Thomson
    Subject: RE: Proposal for scheduling and repeating

    Brett - While I agree we could simplify the proposal to only do repeatable playbooks I disagree with including the scheduling information inside the playbook that would run on the schedule. This makes playbooks less reusable and is much less flexible if you want to run the same playbook (e.g. checking status on various infrastructure systems) at different intervals or even on-demand (during an incident vs slower more regular checks once a day during non-incident times).

    I think its important the definition of the schedule is kept separate from the playbook for this reason.

    So this leaves us with "where" the definition of the schedule occurs.

    Currently there are 2 proposals and I think your proposal is really just a variant of those choices.

    1) Define a new object/step that defines the schedule of an action step (which could include launching a playbook or any other step if you wanted that flexibility), where this new schedule object introduces all the various parameters needed to define what schedule the contained action is executed on.

    - This option is effectively what both you and Lucas proposals are.

    2) Define new properties as part of the while loop step instead of a completely separate object. Still executes the contained action within the while but avoids a new object for the schedule itself.

    - This option is the one that I had proposed.

    At this point (cause we've been talking about this for weeks) I'm neutral on either option if we can get consensus on one of the options. However, I'm not for the option you proposed where the schedule is defined within the playbook itself.

    Allan

    On Feb 9, 2025, at 2:42 PM, Bret Jordan via OASIS <Mail@mail.groups.oasis-open.org> wrote:






Related Content