Skip to content

ti_misp: fixed expiration date isn't accurate enough for MISP attributes #15439

@chemamartinez

Description

@chemamartinez

The MISP attributes data stream supports expiration of indicators of compromise (IOC).

This mechanism allows users to control when a valid indicator/attribute will be considered expired/decayed thanks to a configuration option called IOC Expiration Duration. The expiration date for a particular attribute is calculated as the last seen/timestamp + IOC expiration duration, which is 90 days by default.

For the MISP integration this approach could be considered not aligned with the MISP criteria for dacaying attributes, each ingested attribute contains a decay_score section like this:

"decay_score": [ { "base_score": 80, "decayed": false, "decaying_model": { "id": "12345", "name": "Phishing model" }, "score": 30.5 } ], 

which gives us a clue of when an attribute is going to be decayed (the score decreases over time and is marked as decayed when reaches certain threshold).

Therefore, in this particular case we can compare when MISP marks attributes as decayed versus when they are decayed within Elastic, and most of cases they don't match (constantly decreasing of the score vs static timeframe).

Trying to adopt MISP criteria and calculate expiration date dynamically gives us some complexes challenges that makes it not a good option, so an alternative would be to be able to create a new mode of working for this data stream where:

  • We are able to set an interval where every valid attribute in destination indexes are flushed, let's say daily for example.
  • Followed by a reingestion for all the attributes from the API that makes decayed attributes being removed from mentioned indexes.

That would help us to keep valid attributes up-to-date according to MISP.

We need to take into account transforms limitations explained here.

Finally, some changes in the documentation would be good to add:

  1. Add documentation about this new operation mode.
  2. Add a clarification in the current docs, under the section Handling Orphaned IOCs, it suggests only orphaned attributes are affected by the IOC Expiration duration when at the end, every ingested attribute that is not already decayed is controlled by that setting.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions