Re: [cti] MISP format <-> STIX 2.0 - Discussions

[Alexandre Dulaunoy <Alexandre.Dulaunoy@circl.lu>]

On 05/05/17 14:49, Jason Keirstead wrote:
> This is a very good read. These kinds of validations and challenges to our 
> modeling with real-world use cases are critical to make sure we are 
> getting things right...
> 
> - Being a MISP novice, can you go into more detail on the "MISP 
> IDS/Machine" field? What is this used to convey?

It's a core principle in MISP. The flag indicates whether an attribute
(our definition of an atomic data point, which could be an indicator,
a reference, or any other point of information) is to be used in  automation processes.
(such as feeding IDSes, automatic fraud detection systems, firewall policies, etc).

If the flag is not present, this is usually contextual information or
information not used any longer for automation.

For reference: [1]

> - From my reading around it, A MISP "event" to me seems like it would be 
> most properly modeled using an Incident object, which was something that 
> was pitched and is in the STIX 2.1 Working Concepts, but has not yet had 
> anyone take it over for refinement to get into STIX 2.1. Maybe MISP would 
> like to take that on?

We have historically used Incidents as you mention as our closest match in STIX terms
and have used it in our STIX 1.x mapping, however, MISP events are not necessarily incidents.
They can be reports, incidents, results of an analysis or even completely diverging
data packages such as financial fraud reports. This has always caused inaccuracies
and confusion in our mappings, something that has lead to several of our users
being alarmed and dissuaded from using our STIX connectors
(for financial sector institutions being involved in a security incident is a massive
potential liability towards your constituencies with severe consequences).

For reference: [2]

[1] https://github.com/MISP/misp-rfc/blob/master/misp-core-format/raw.md.txt#L592
[2] https://github.com/MISP/misp-rfc/blob/master/misp-core-format/raw.md.txt#L138

We hope this helps.

Cheers.

-- 
Alexandre Dulaunoy
CIRCL - Computer Incident Response Center Luxembourg
41, avenue de la gare L-1611 Luxembourg
info@circl.lu - www.circl.lu