Possibility to mark observables as False Positives

[mglsnchz]

Request Type

Feature Request / Discussion

Description

Right now, the IOC flag only indicates that we've classified an observable as True Positive. If someone else had already a look at an observable and classified it as False Positive, we never now. Furthermore, only IOC-flagged observables are exported into MISP instances and could be used to modify events/event attributes.

Idea to improve the current behaviour:

1. Be able to classify an observable as True Positive and also as False Positive:
   • Change the IOC flag so that possible values are: Unrated/False Positive/True Positive
   • Default value should be Unrated
   • Analysts now know if anyone else already classified an observable (all observables without any classification weren't analyzed/rated yet)
2. Furthermore export all observables which are classified into selected MISP instances:
   • The false Positive flag can then be used to modify event attributes in the connected MISP instances (e.g.: observable results in a bad indicator after some analysis and shouldn't be used for alarm generation anymore)
   • The corresponding event attributes of the MISP instance can then be modified automatically during case export or by using responders (e.g.: change IDS flag or sightings)

[mpotgieter]

I think your logic assumes that an observable is always an IOC, when in fact an observable is just something observed in a case or alert. The very nature of turning on the IOC switch on an observable makes it a "true positive". I would be concerned that this feature request would change the thinking of how an observable is seen and potentially affect work flows. Essentially if I have many observables which I do not want to mark as false or true positives (i.e. they are just information for the alert/case), then I may end up with many unrated observables portraying a metric that is not favourable.

[cgi1]

@mpotgieter @mglsnchz: I really like this discussion!

Coming from the view as an intensive MISP user and administrator, it would be great to integrate the concept of sigthings into The Hive. Let's do this on an example and search for the best solution:

1. SIEM generates an alert based on an indicator from some sort of IoC source (commercial / open-source)
2. The alert is getting transmitted into The Hive where some additional information will be attached; incident is getting investigated more closely.
3. In the end there will be a result: True- or False-Positive for this particular alert; which have been originally generated based on an IoC. The final result of the alert classification should then be transmitted as a sigthing to the original IoC into MISP.

So what would be the best solution to do so?

[mglsnchz]

I would be concerned that this feature request would change the thinking of how an observable is seen and potentially affect work flows. Essentially if I have many observables which I do not want to mark as false or true positives (i.e. they are just information for the alert/case), then I may end up with many unrated observables portraying a metric that is not favourable.

@mpotgieter: Thanks for your feedback. I don't think that the change would affect your way of handling observables.

• All observables, which are unrated, can still be seen as additional information and not as an IOC.
  • If someone likes to handle everything as IOC this is also possible
• Everything rated is either an true IOC OR was seen as an IOC during investigation, but an analysis revealed that it's instead a false positive.

[saadkadhi]

I agree with @mpotgieter.

IOCs are a subset of observables. IOCs for which the sighting toggle has been activated in TheHive means that they have been seen (positive sighting). I believe we still don't export sightings to MISP though.

If an observable has the IOC flag set and the sighting toggle active, it means it is a 'True Positive' (I am not fond of reusing a terminology used for incident qualification at the atomic, observable level). If an observable has the IOC flag and the sighting toggle is inactive, it means it is either a 'False Positive' or 'Unrated'. You can augment that through observable tags.

I think we should keep it simple not to impede usability & quick incident handling and leverage tags & proper team organization/processes for more complex considerations.For ex. you can instruct your analysts to tag 'unrated' any IOCs that have not been investigated/searched/etc.

[saadkadhi]

@cgi1 if an alert has been promoted into a case and the case has been closed as True Positive, that means the alert is a TP. We could export such case-level data when sending it to MISP.

[mpotgieter]

• All observables, which are unrated, can still be seen as additional information and not as an IOC.
  • If someone likes to handle everything as IOC this is also possible

This again changes the logic.. it defeats the purpose of the IOC switch. We now must assume an observable is not an IOC when it is unrated, but unrated could also be an IOC that is unrated.

I can suggest that we add the additional options of TP/FP and unrated when the IOC is switched on for an observable. I personally would not find much value in this feature at this point in time.