| Once again thank you for your feedback and suggestions. I have added these to the comment resolution log and we will be discussing these and how to adopt them in our December 7th meeting. If you have any additional feedback or suggestions, please submit them for that time. This public review period will close on the 24th of November, however, there will be at least one more public review period before this specification finally ships.
As always, thank you for taking time to review. If it is within scope and reason, we would encourage you to join our technical committee to help flesh out further enhancements. If that is not an immediate option, please feel free to continue sending comments and suggestions to our public comment list. cacao-comment@list.oasis-open.org
Thanks Bret
Thank you and that makes perfect sense. Thatâs an excellent approach. Once again Thank you so much for the insights and pls do let me know, if I can be of any further help. Best
Vaman Kini Automation Use Case Management was part of the thinking that would be included in the workflow steps. Thatâs why we felt that having variables that capture the case number (when a playbook is called for a particular case) and having the ability to connect the workflow to an active case was important. Which is why we built into the flow various aspects of passing state between different systems to track the automation aspects. So the structure is there. But what was the thinking is that the targets for a specific case management tool would be via the http/web based target defined in the system. I could imagine adding more targets in the future for specific case management tools directly but we felt the generic HTTP/Web API would suffice in the short term. But as you can see in v1.1 of the spec weâve been adding other tools like kestrel, sigmaâetc. and if you have suggestions on how to extend for a specific case management tool then we can add.
Thank you, for the quick response. An easy example come to mind , the remediation measure which involves blocking of an IP address in the FW. We need to make sure we donât block something like the corporate/24 or Microsoft email GW IP. Instead of every workflow checking a Whitelist database ( which are essentially API calls to Microsoft, Google . AWS etc) we could have one set of Playbooks which should be called before the mitigation is applied. - Safety _IP
- Safety _Domain
- Safety_HASH
- Safety_Host
Now that I think of it . these could be just playbooks which populate a whitelist and the mitigation playbook has a step to check the relevant list. That would lead to the thought that we need playbooks which keep things currentð Do you envisage any that the TC would do around the process of Automation Use case management ? Best Vaman Kini Thanks for your valuable feedback Vaman. On 1 - I agree that typically investigation includes enrichment. Our intention was that enrichment would either be a set of workflow steps within the investigation playbook or a separate playbook that can be called from the investigation playbook. In this later case, I can see why it would be useful to encorporate the enrichment playbook type into our list of choices. Weâll definitely discuss in the next TC meeting to decide on this. On 2 - I believe our intention was to incorporate this category as the mitigation playbook. Can you help provide a description of what you mean by Guardrail/Safety playbook? That might help us explain the difference between a mitigation vs safety playbook. On 3 - Good feedback. Will bring to the TC for discussion (and likely agreement).
I am sorry for delayed feedback. Sharing my thoughts on the content. - While some of the facts might be covered by 2.1.3 â Investigation playbook , I think most orgs would start their journey with enriching events . My suggestion would be to have a dedicated enrichment playbook which enriches the event.
- Another type of Playbook that I would suggest is âGuardrail/Safety â These need to be the ones that are hooked into the remediation playbook is invoked and will have components of actions that never should be taken. ( Shut down a core system , Kill a core process on the host etc) and should generate a feedback to the decision point in the OODA loop.
- In the Portions where User /identity is defined (mainly in sec 6) it might be beneficial to also include the role of that identity . Often, we might want to only use a read only role to pull data but a more powerful role ( where the credential is taken from a vault ) for a remediation action
Please let me know, if this is helpful and I will find more time to contribute. I am in the process of setting up an internal process of SOAR use case management and find this document to be very helpful. Senior Information Security Officer Office of Information Security Information and Technology Solutions
|