[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [EXT] RE: [cacao] Agenda for next Tuesday's call
Karin,
Can you look at the written playbook I have in the use cases document and prepare an example of what this would look like in BPMN / a JSON version of BPMN?
Bret
From: Marr, Karin W. <Karin.Marr@jhuapl.edu>
Sent: Monday, October 14, 2019 2:58 PM To: Allan Thomson <athomson@lookingglasscyber.com>; Allen Hadden <ahadden@us.ibm.com> Cc: Bret Jordan <Bret_Jordan@symantec.com>; cacao@lists.oasis-open.org <cacao@lists.oasis-open.org>; Jason Keirstead <Jason.Keirstead@ca.ibm.com> Subject: [EXT] RE: [cacao] Agenda for next Tuesday's call All, I would like to add in some experimentation that JHU/APL has done with BPMN for Playbooks before we all dismiss the concept of using BPMN.
First â we determined that we only need a small subset of the BMPN symbols for the flow. Second, we worked with Demisto and Cybersponse tools to âtranslateâ the XML produced from BPMN to the SOAR Platform native language. For Cybersponse â that was JSON (they did the translation for us). For Demisto â we created the XML-YAML translation using Python. We found that â although there are numerous (40+) free BPMN tools available, we could use the python code to translate any of the BPMN XML outputs to YAML.
I have attached one of our BPMN (we called them workflows) playbooks and its XML output (these were demonstrated at one of our IACD ICs). To see the video of this go to: https://www.youtube.com/watch?v=sG1S3BIpqrM
Bottom-line â there needs to be some sort of tool that can be used to create the playbooks and output some machine readable code. We chose BPMN because itâs already a standard, most tools are free and many are pretty straight forward to use. Is it overkill? Maybe, BPMN is powerful but its far simpler than creating our own. The advantage to BPMN also includes having one tool that can be used to generate both the graphic representation for the developers/consumers to understand and machine readable code for SOAR Platforms to ingest. We have also taken a Cybersponse Playbook â converted it to BPMN XML, altered it in BPMN and then uploaded it to Demisto, successfully.
If you want more information and workflows (CACAO playbook) examples please see: https://www.iacdautomate.org/playbook-and-workflow-examples
Thanks, look forward to tomorrowâs call. Karin W. Marr â 240-228-7760 | 📱 240-381-4421
From: cacao@lists.oasis-open.org <cacao@lists.oasis-open.org>
On Behalf Of Allan Thomson
Allen â I âthinkâ we (or at least you and I do) agree that BPMN is probably overkill for what we need.
To re-iterate my perspective, I think a subset of what BPMN does in JSON is sufficient for âmostâ requirements. Iâm not sure I agree the JSON translation that was pointed to is the best approach from my perspective. Taking something that was designed for XML and much broader uses is not necessarily the most effective way to design something.
My point was that the group should discuss the pros/cons in the upcoming meeting on approaches (not just BPMN) so that we can have consensus on an approach that works for all orgs participating.
Regards
Allan
From:
Allen Hadden <ahadden@us.ibm.com>
Our product uses BPMN for playbooks today. I'd say that there's nothing that CACAO will want to do that cannot in some way be represented in BPMN. There is nothing (or at least very little) in BPMN that wouldn't be useful for CACAO. This shouldn't be surprising since BPMN is intended to express business processes and what we're talking about with playbooks are exactly that...business processes, but in the security domain.
The problem is that if you look at BPMN, a lot of what's there would just be considered "nice to have" from a CACAO perspective. Good example: swim lanes. Could you come up with a CACAO use case that could make use of swim lanes? Sure. Would they be required? Not really.
A lot of the advanced BPMN features are only useful when you start trying to express general organizational playbooks (e.g. CompanyX's Malware Process) instead of playbooks targeted at mitigating specific threats (e.g. Mitigate MalwareX).
Another problem is that full BPMN is so large that realistically the only way to develop a product with it is to integrate an existing BPMN product. Implementing your own would be a ton of work and adapting it to fit a less flexible model in an existing product would be tough. So on the one hand, it's great to be able to leverage an existing library. OTOH, is that a position we want to take as a spec?
One option worth of consideration is to take the JSON-translation that Jason K. linked and define the following:
1) a "whitelist" showing which elements are to be included (e.g. don't include "swim lanes" if we don't think they're important). 2) specific extensions to the model (BPMN supports extension elements and we'd very likely need some...for example, "service tasks" for OpenC2, Ansible, etc.) 3) object models on which the process will depend (e.g. it could be that a playbook works against a "threat", which would probably be a STIX model)
Probably there are other things we'd need besides those 3, but that should get the ball rolling if we decide to consider that path.
Allen
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]