All,
Here is the proposed agenda for our next working call on the 31st.
I have been going through the document and cleaning up all of the comments and suggestions based on our conversations and the consensus we have had on our working calls. The details of all of those changes are in the #general channel in slack. At this point there are only a few remaining items that we need to discuss. On some of these points, I would like to introduce them here and then do an up/down vote on our next working call.
Topic 1
Section 4.4 Action Step: Remove in-line defining of targets.
There is a request to remove inline defined targets on actions steps. I am now coming around to the idea that this is right and that inline defined targets are an un-needed perceived simplification that actually only adds complexity and issues. Originally we put this here since we thought that targets would not normally be included in the playbook itself. However, since those early days, the TC has made a decision that targets need to be included with the playbooks. This makes our original need and design less desirable. If we do this, this would represent a minimal amount of editorial work.
Question: Should we remove the ability to inline define targets on things like the Action Step?
Topic 2
Section 6: Rename targets
There is a request to rename targets to something else. The comment is: "Referring to the entity that executes a command as "target" is confusing. Other options: executor, actuator, agent. Currently, CACAO does not define the object of a command, but it should. The term "target" seems a natural choice in this context. Other options: object, resource, entity." I do agree that we do not have clear semantics around this. The thing that receives the command to execute and the thing that does the executing are not really clear. So we should do something here.
Discuss: What to do here.
Topic 3
Section 9.2: Merge civic location and gps location
It has been proposed that we merge civic location and gps location. I personally think this is now a good idea. What would be needed in addition to this is a simple statement that states what to do if they do not match. But we would need to do that anyway as those are both defined on the same target today.
Question: Should we merge the civic location and gps location into a single data type?
Topic 4
Section 9.6: Features
Discuss: how to address these comments
Topic 5
Section 9:16: Variables
Discuss: changes to normative rules
Topic 6
Section 9.9: Identifiers
UUIDv5. I know the value of deterministic IDs, but I am having a hard time finding the value and use case for how we have defined them in CACAO. Saying let me generate a playbook ID based on the name of the playbook and let someone else figure out the playbook ID based on the name of the playbook does not seem to have any value. It does not provide a benefit in searching since really only one property contributes to this. Also, the chance for collisions is really really high, especially since we have said that the name property does not need to be unique. In STIX land it makes sense to say I have an IP address, what should its ID be based on UUIDv5 so that everyone on the planet does not create their own ID for 127.0.0.1. That makes total sense. But here I am really struggling to understand how or why one would actually want to do this in CACAO.
Question: Should we remove UUIDv5 support? If not, what changes do we need to make to make its use case more clear?
Topic 7
We need to talk about attack target types, as has been brought up a few times, they are still a bit clunky. As they are currently written in the document, I personally find them hard to understand and implement. I do see value in trying to keep them but they need to be cleaned up a bit. This seems to be the last major thing we need to address. I will try and have a proposal before our next meeting.
If there are any other agenda items, please let me know.
Bret