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: [cacao] How best to do multiple actions


Having two abstract layers, one for the actions and one for logic would allow to reuse the actions (in a more appropriate manner/better engineering). I can imagine that I have a bucket that is filled with actions that I can re-use. 

This can also support the use of playbooks in deriving extra intelligence and insights. Just a thought, for example in terms of CTI,  we can map and visualise playbooks in respect to common actions related to IoCs easily and why not having a similarity index that can show overlap percentage among playbooks.

Ill try to engineer a schema for the second approach starting next week. If somebody wants to help please let me know.


Vasileios Mavroeidis â Security Researcher and Ph.D. Research Fellow 
Research Group of Information and Cyber Security (SECURITY)
University of Oslo

On 18 Sep 2019, at 19:24, Ghosh, Anup A. <anup.a.ghosh@accenture.com> wrote:

Hi Bret,

I think this is a useful discussion to get us thinking about these details. I like the second approach for the following reasons: it lists the atomic actions which can be considered building blocks to a play. The play then is able to add (temporal) logic to the building blocks to meet both the end objective of the play as well as capture the dependencies. Different plays will have different logic and dependencies which allows us to re-use the building blocks rather than starting from scratch each time.



-----Original Message-----
From: cacao@lists.oasis-open.org <cacao@lists.oasis-open.org> On Behalf Of Bret Jordan
Sent: Wednesday, September 18, 2019 10:15 AM
To: cacao@lists.oasis-open.org
Subject: [External] [cacao] How best to do multiple actions

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.


I want to kick off a discussion about how best to encapsulate multiple atomic actions in a security playbook.  From my perspective there are at least two different ways this could be doneâ.

1) The actions and the sequencing is kept together. In this model, we would define any temporal / conditional logic and any required response codes along with the action itself, or in-line with the JSON structure for that action. Something like:

Action ID: 1234
Remove Registry Key
Require Success
If Failure send alert and stop

Action ID: 5678
Delete File
Require Success
Require Success of Action ID 1234
If Failure send alert and stop

2) The actions and the sequencing / logic are separate from one another.  In this model you could have a small library of commands and then a processing instructions in another part of the JSON

Action ID: 1234
Remove Registry Key

Action ID: 5678
Delete File

Action ID: 9876
Email Change Control

Action Logic
First do 1234
Second do 5678 but only if 1234 is successful
Third do 9876 but only if 5678 is successful

This is not meant to say we are doing one of these two methods, but rather, this is meant to be a way to start the discussion.



This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.


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