Found the issue and updated the playbook-id attribute. It is not required anymore. We should not dictate producers generating this property since it can be used to correlate playbooks. The use case is: If we have a cacao playbook attached then we could have the UUIDV4 extracted from the "attachment" and put at the MISP security-playbook object attribute "playbook-id". Correlation is enabled if another security playbook object follows the same process while attaching the same CACAO playbook. If the attached playbook is a png then there is no way to associate it again with another security playbook object that has the same png as an attachment as we cannot know that. That would be possible only if the attachment had a machine-readable identifier. Another use case is to generate a hash and attach it to a property, but let's leave that for the future and if it is never needed or appears as a use case. Long story short the pull request improves the semantics of the object and correlations of different security playbook objects :)
MISP object template designed following requests and especially this twitter thread:
https://twitter.com/castello_johnny/status/1540610057263628289
I added a list of sane default based on the ones I have seen being used:
"sane_default": [
"event query language (eql)",
"keyword query language (kql)",
"Query DSL",
"Query (Elastic Search)",
"Sigma",
"Lucene query",
"Google search query",
"Ariel Query Language (qradar)",
"Grep",
"Devo LINQ"
],
Thanks to Gianni Castaldi and others for ideas.
The object can be expanded and improved over the time and the needs
to share new queries.
- as discussed with @righel, if we allow multiple IPs we should also allow multiple ports
- we might revise this in the future if it causes issues, however, then we should also restrict the use of multiple IP addresses
The PR updates the security playbook object with improved semantics based on feedback we have received.
The updated template has "one-to-one" mapping with the available STIX 2.1 ad-hoc extension for the COA SDO available here: https://github.com/fovea-research/stix2.1-coa-playbook-extension
This research (updated version 3) was partially supported by the research projects CyberHunt (Grant No. 303585 - funded by the Research Council of Norway) and JCOP (Grant No. INEA/CEF/ICT/A2020/2373266 - funded by the European Health and Digital Executive Agency through the Connected Europe Facility program).
For instances that ingested it before the disable_correlation changes, they didn't take and ended up pushing a lot of correlating noise. This should resolve it for the future.