Re: [cacao-comment] Request for Feedback

[Christopher Halbert <christopher.halbert@gmail.com>]

Hi Dr. Mavroeidis,

Thank you for all the updates. As I mentioned, I would love to contribute to the project (truthfully, whether it is paid or unpaid). I'm not sure when or where the junior positions will be posted, but I would like to apply when that time comes.Â

In the meantime, how can I apply to join the Technical Committee or attend forums to stay in the loop?Â

I look forward to meeting with you all. Kind regards,

Chris Halbert

On Wed, Jan 18, 2023, 7:07 AM Vasileios Mavroeidis <vasileim@ifi.uio.no> wrote:

Hi Christopher,Â

I know a few organizations working on or already have CACAO apps / UI for generating/modifying playbooks, but none is open-sourced.Â

Having said that, a European project has confirmed funding for three "junior developers" that will work with a few senior people/devs to create an open-source CACAO generator/visualizer/modifier (you name it). The project will start on April 17 and will end on August 5 with a full release. Bret ofc will be onboarded to provide advice.Â

We will be happy to receive feedback from you as well, and if we make it to jump into a call for the introductions, why not collaborate further during the development phase of the software.

Kind regards,

Dr. Vasileios Mavroeidis
Scientist and Associate Professor ofÂCybersecurity
University of Oslo

Web page:Âhttps://www.mn.uio.no/ifi/english/people/aca/vasileim/

On Jan 17, 2023, at 9:47 PM, Christopher Halbert <christopher.halbert@gmail.com> wrote:

Hi Bret,

It's quite alright! I know how the emails can get buried (hence my delayed response).

Right now, I'm using a derived version of the CACAO spec to document our incidents and responses in YAML format for readability sake. I think the CACAO spec will become widely adopted and eventually set the bar for those security/incident response oriented organizations. Before that happens, I imagine there will be a UI to support viewing and creating the playbook objects, whichÂis why I'm trying to closely follow the spec. Generating a uuid for a workflow, command, or playbook isn't challenging; I guess it's doing that in addition to creating, as you mentioned, what could end up being a graph relationship - it makes manual adoption a bit more difficult and harder to follow. Think of the workflow - someone copies the first uuid of a list of uiids, finds that elsewhere, then comes back and tries to find the next uiid in the list, etc - a user could easily miss one or accidentally go to the same one. Right now, I'm referencing playbooks as filenames in the same directory, which I'm guaranteed to always have a unique identifier for since a filename can't map to more than 1 file. I guess removing the requirement of the uuidÂwould allow organizations to manually adopt the specification internally without a UI in the interim. I understand that an underlying objective is to open source playbooks and make them shareable, which couldn't reliably happen without the uuidÂspec. I was just thinking it may help encourage adoption sooner if manual adoption is easier, which could also attract organizations to invest their time into building a frontend. (I know a lot of conditionals there, but you understand)Â

Anyhow, I hope that helps explain how we are using it and I'd love to hear what you'd suggest. Are any of the UIs supporting CACAO open source or available for contribution? I think this is a great initiative and would like to add some legs to keep the momentum in any way I can.Â

Thank you too for getting back to me, Bret! Kind regards,

Chris Halbert

On Tue, Jan 10, 2023 at 10:53 AM Bret Jordan <jordan.oasisopen@gmail.com> wrote:

Christopher,

Thank you for your comments and questions. Welcome to the CACAO community. I also apologize for the delay in getting back to you. While CACAO is called out as being for security, it can easily be used for just about any type of playbook. I would love to talk with you more about your specific needs and desires for a parent playbook. I am curious to know what would be needed.Â

The reason for having an identifier for the playbooks is to help them be track about and stored. Also, there is a great desire to be able to tie playbooks back to threat intelligence in a graph database. Most programming languages today have support for generating the IDs, so it should be pretty easy. But once again, I would love to hear your feedback.

There are several efforts under way to build out support for CACAO and build UIs for it. There is a whole initiativeÂin Europe to use CACAO as the officialÂsolution for all member states.

I would love to hear more about your use cases and what you would like to do.

Bret

On Tue, Dec 20, 2022 at 5:48 PM Christopher Halbert <christopher.halbert@gmail.com> wrote:

Hello!

This is my firstÂinquiry with the CACAO TC so I'd like to quickly introduce myself for context. I'm a Staff Engineer forÂa securityÂcompany and I'm working on standardizing my team's incident playbooks with regard to general site reliability, which led me to CACAO. Also, this is my first comment on an OASIS forum, so please bear with my verbosity :)

As I mentioned, I'm viewing an incident through the lens of the ITIL where "an incident is an unplanned interruption to a service, or reduction in the quality of service," opposed to an actual security incident, however the CACAO specification still offers value for my internal needs. With that, I was curious if there had been consideration given to abstracting out a general CACAO playbook specification (not security focused)? A more general schema may exclude "target" and the "workflow: attack" for instance. I know these aren't required but by creating a parent playbook spec, but this could expand application to a broad group, encouraging adoption and contribution long term.

Another item of interest for me is the Identifier specification. I understand the benefit and need for the Identifier, but it does add overhead for manual adoption since a simple template will necessitate a shell command to generate another uuid. This makes sense for a large shareable library spanning organizations, but it could add a hurdle for those considering adoption. With limited adoption, who will open source the GUI to support the data model?

This leads to my last question. Are there any efforts to develop a UI to visualize CACAO or manage CACAO data models? I understand this is likely outside the scope, but I imagine other members may have similar interests. My recent engineering track has been mostly backend/arch focused, but I would be willing to brush up and contribute if there's a group forming.

Thank you again for all of your support and contributions. Kind regards,

Chris Halbert