Following a discussion with @aaronkaplan in Vienna, this object is a
first version to describe an AI chat prompt. The template can describe
the model used, the actual quality of results and also what's the actor
context.
Reference #388
To be used to share risk assessment report from risk assessment platform
such as [MONARC](https://github.com/monarc-project/).
This extension is done in the scope of the [NISDUC project](https://www.nisduc.eu/).
TODO: Maybe add a field for machine-readable version of the report
- Even though they are not exactly part of the
socket fields, it could be interesting to have
them to have the information about them like
they are described within the packets that are
sent using the socket
- The `registry-key` object template includes
already the `data`, `data-type` & `name` fields
of a registry key value, but there is a
limitation in the case of multiple registry key
values
- In order to describe multiple registry key
values, instead of adding a simple `multiple`
field to the related and above mentioned fields,
it is better to use the `registry-key-value`
template so we know which data, data type and
name values are related to a given registry key
value
- It is then possible to have a reference between
the registry key object and the related values
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.