[Question] Recommended practice mapping observables with MISP types

[jezkerwin]

What are the recommendations for mapping of obversables between MISP and TheHive? When events get forwarded from MISP to TheHive as an alert the mapping will show as 'other' so was wondering if I should be mapping the observable fields between MISP and TheHive.

[joseluratm]

Hi,

Me and my colleagues were wondering about this for a lot...

When you need to act, TheHive's datatypes, works good but when you have a lot of IoCs on lessons learned phase and export them to MISP this is a litte chaotic.

By default all ip or mail datatype will be mapped with ip-src and email-src and them you must check all iocs again.

A solution must be to map all datatypes with MISP categories and types?

Maybe TheHive Project developers could give us light on this.

Regards,

[saeeda12]

Hello, I am also looking for a solution to this, and opened an issue in the MISP GitHub page last week: https://github.com/MISP/MISP/issues/4597

[jezkerwin]

Yeah, it does seem like the simplest action is to map misp to hive observable.

[saadkadhi]

TheHive has been designed with speed and quick collaboration during incident response in mind. Having a list as complete as MISP categories & types will kill such purpose. We do not want analysts to drill down a huge list of categories & types to get their job done. Once your investigation is done or well advanced, you can export your case to MISP and tidy attribute categories and types there before publishing the associated event.

In TheHive, you want to be quick when facing fire. In MISP, you want rigorousness to augment your CTI/KB and share in a clean, contextualised way with your trusted peers and partners.

So we could probably export observable labels to MISP to help you tidy up data there. Thoughts? /cc @To-om

[jezkerwin]

Thanks @saadkadhi for your explanation. I certainly understand the point you're making, and agree that I shouldn't be wondering where do I fit my observables to map with MISP and that TheHive should be quick. Perhaps the documentation could reflect the point you made as I'm sure it would help others that have a similar question. (unless it already does and I've just missed it)

The reason for the question was that when events are created in MISP, they obviously get sent to TheHive as an alert, and that's where the observables are mismatched, it doesn't tend to be a lot of observables, but enough that made me wonder. things like ip.src user.dst ip.dst etc. just get mapped to 'other'

[saeeda12]

Thanks for the response @saadkadhi

Yes, exporting Hive observable tags to MISP would be immensely useful in filling this gap when attributes get mapped incorrectly. Hopefully this should be not too complex as the integration already supports exporting case-level tags to MISP (if the tag already exists in MISP) via the exportCaseTags parameter in the application.conf file.

[joseluratm]

Hi,

I think all us are agree with the fact that all data types must be quick but maybe when you finish to put out the fire and click "share", would be interesting to see a menu similar when you go on MISP to "Populate from -> Freetext Import" because later (i think) required a lot more work and at this point, IR analyst is the guy with more knowledge about this threat.

I think when you are importing (likea jezkerwin says) you lost this information but you neednt reshare back (maybe dont mark this observable as IOC resolve this problem). In my opinion, when you import and IoC you want to enrich this information for exporting then

have you think about refactor datatypes ??

thanks!!!

[saadkadhi]

@jezkerwin @saeeda12 @joseluratm you are all making valid points. Let me try to address them:

Documentation

That's certainly something we can work on.

Importing events from MISP

If we wanted to keep attrib categories & types on import as observables, we would end up with the list we want to avoid having in the first place, and exposing it not only to the analysts but also to responders and analyzers, which need to know the datatypes they apply to (think simplicity & maintenance over time here please). One way to address that, and which we believe is satisfactory, is to retain MISP categories and types as observable labels (or tags if you prefer).

That being said, importing ip.src or ip.dst as other is not helpful in any way and we'll try to have a saner mapping between MISP categories & types with the limited number of datatypes we have and see if there are additional quick wins for the next major version of the platform.

Exporting Observables to MISP

While I see real value in exporting observable labels (or tags) to MISP to facilitate the necessary mapping operation back to MISP categories and types, I do not see us redeveloping a drill down menu on export to do that on TheHive's side. Once the analysts export their cases back to MISP, they just need to connect to MISP (right away so not to forget) and do the remapping. a CTI team member can then do a last sanity check before publishing the event.

Taxonomies

We've been discussing the necessity to establish a namespace or taxonomy for commonly used observable labels. That way, they can be used in a consistent fashion across cases and avoid having a label called source ip in one case and src-ip in another. One way to address this is to support multiple, well-established taxonomies and map them back automatically to MISP on export which would ease up event content checks before publishing. We have put that on our roadmap for next year.