- We get the initial MISP event, we export it in
STIX2 format, and use the import script on this
file to compare the initial MISP event with the
one created with the STIX2 import
- Since the export to STIX2 and import from STIX2
are lossy, we do not expect the results to be
perfect, but the enumeration of the differences
confirm what we already know as lost in the
full process, so we can see what is not going as
expected
- The API key could be gathered from MISP, but
these small testing scripts were first intended
to be standalone, and are only for testing
purposes
- added the ability to select an orgc ID for CSV/freetext feeds
- all events created from this feed will carry the selected orgc_id
- Refactored the index fully
- using the factories
- better warnings against the dangerous new feed each pull setting
- event index search added
- several settings cleaned up / made more clear
- auto reload of default feed configuration disabled, fixes#2542, fixes#5789
- added a button / endpoint to handle that instead to allow for the deleted default feeds to stay deleted
- several new field types added (target event, caching)
- several updated with new features and functionalities
- tied into the new data path collector among other changes
to the sharing_group
Even if the event belongs to the user. This scenario can happen if a
remote sync is badly configured where the remote sync user have
site_admin right, thus allowing the user to see the event even though
he is not part of the SG
- when running a large MISP community, it is bound to happen that your instance will be used as the back-end for internal tooling
- often these tools are configured to fetch aggressively, often with heavy consequences on the server load
- some filter that serves mostly edge-case lookups can mistakenly lead to heavy server load for no good reason
We have identified attribute level positive filters on the event scope to be such a filter and made them optionally toggle-able
via the MISP.attribute_fitlers_block_only flag. Turning the setting on will remove all event level filters such as "type" from
being viable filter candidates unless used to block the inclusion of attribute types. Some examples:
"type": {"OR": ["ip-dst", "ip-src", "hostname", "domain"]} would normally return ANY event that has at least one of the listed
attribute types. This is the behaviour that can now be disabled.
"type": {"NOT": ["iban", "cc-number"]} would normally remove any attributes with the given types from the list of returned
events. This functionality is NOT affected by the toggle.
- fixed ID lookups to be more graceful (IN() instead of OR-d statements)
- removed default sorting which is the default anyway but introduces a massive overhead
Richard van den Berg
Alexandre Dulaunoy