Case Management: auto-number the cases to easily identify them
Use case
Often in the ticketing system (like github for instance), every ticket (or cases for OpenCTI) has an easy identifier, that user cannot edit so that users can refer to it. The goal is to have the same in OpenCTI.
linked to: https://github.com/OpenCTI-Platform/opencti/issues/2763
Customer feedback:
- Use a specific word in the code for easy retrieval, e.g. “OCTI-IR-XXXX”. For example, “INCIDENT-XXXX” would be a bad choice, as the word “Incident” would match a lot of things (in a mailbox, for example).
- Do not increment a counter or any other number choice that “leaks” information. For example, incrementing a counter would give information on the number of incidents handled over a period of time.
This is an interesting one.
A couple of reasons for having automatic case numbering are to:
- Create a unique title that an analyst can easy discern on a table view when viewing, for example, automatically-created IR Cases that have been triggered by a repetitive SIEM alert (ie. "Which of these 120 'Incident alert from EDR' cases, which inherited their name from the incident that came from the same SIEM rule, is the one I was just working on?"
- Create a daily bulletin, where the case/container has a name "Bulletin yyyy-mm-dd" and reports for that day that meet an IR are automatically added to it using a playbook
Both of these are automation use cases, rather than manual creation, where an analyst can simply type a new number.
The other challenge here, is that the uniquely-named case must be dynamically addressable by automation later on. eg. If we create a case with the name "Bulletin YYYY-MM-DD", then a playbook that is adding reports to this, must know which case to add those bulletins to.
My current thought for a proposed solution, is that we would need to add playbook features to:
- Support dynamic variables (eg. $date(YYYY-MM-DD))
- Add a playbook action "Add to a new container (and create if it doesn't exist)" that can use those dynamic variables.
This would make it only an enterprise feature, though. But the pain is that cases being created by playbooks, which is an enterprise feature, do not have unique names.