OASIS Cyber Threat Intelligence (CTI) TC

Hi All, We recently had an extensive discussion within the MISP core team for the MISP format conversion from/to STIX 2. We pinpointed some issues and possible remedies (short-cuts?) on the following page: https://github.com/MISP/MISP/wiki/NotesMISP-STIX2 As discussed with Trey, we would like to share our findings with the community and are hoping to see whatever our solutions fit the envisioned STIX 2 standard. Thank you very much. Cheers. -- Alexandre Dulaunoy CIRCL - Computer Incident Response Center Luxembourg 41, avenue de la gare L-1611 Luxembourg info@circl.lu - www.circl.lu

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? - 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? - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security Without data, all you are is just another person with an opinion - Unknown From:         Alexandre Dulaunoy <Alexandre.Dulaunoy@circl.lu> To:         OASIS CTI TC Discussion List <cti@lists.oasis-open.org> Date:         05/05/2017 07:29 AM Subject:         [cti] MISP format <-> STIX 2.0 - Discussions Sent by:         <cti@lists.oasis-open.org> Hi All, We recently had an extensive discussion within the MISP core team for the MISP format conversion from/to STIX 2. We pinpointed some issues and possible remedies (short-cuts?) on the following page: https://github.com/MISP/MISP/wiki/NotesMISP-STIX2 As discussed with Trey, we would like to share our findings with the community and are hoping to see whatever our solutions fit the envisioned STIX 2 standard. Thank you very much. Cheers. -- Alexandre Dulaunoy CIRCL - Computer Incident Response Center Luxembourg 41, avenue de la gare L-1611 Luxembourg info@circl.lu - www.circl.lu --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Yeah this is a great writeup.
 
One thing I would consider as you (and others) are doing this comprehensively is the use of custom properties. Specifically, if there are cases where a generic STIX tool (not coded support
for your specific capabilities) just has no hope of doing something intelligent with the data you should probably use custom properties.
 
As an example, in the taxonomy section you have a label called "osint:source-type="blog-post"". If a generic tool gets that property it’ll probably just display it to the user as it does
with other labels…which in this case, kinda makes sense. It’s not ideal because there’s markup in there but it’s at least readable.
 
OTOH you also suggested putting Machine IDs into labels, which would give a label like "misp:to_ids:true". Would that make sense for a general tool to display to the user? Would the user
(who doesn’t know MISP) know what it means? I think the answer is no, so that seems like a good use for custom properties. Just add a generic property to the STIX object called {“x_misp_to_ids”: true}
 
Here are some specific comments…
Contextual Categories:
I agree that kill chain phases is the right place for this. I also like the idea of the TC somehow publishing a set of known kill chain and phase names so we get better consistency. I don’t
think it makes sense as part of the STIX spec itself, but maybe as a non-standards track work product (or, to be honest, just on our docs site would be better than nothing).
 
Taxonomies:
As I said above I think it makes sense to use labels for this. I’m not sure about having generic machine tags as a standard part of STIX…one of the key features of STIX is to standardize
on things, and so we probably just want to consider adding fields specific to the commonly used taxonomies.
 
That actually already applies to one of your labels…you have “tlp:amber” in there, but in STIX that should really go in data markings. That does mean that you probably need to treat some
of your taxonomies different than others.
 
Machine IDs:
I also don’t really understand this. As I said above, though, the best place to put it is probably custom properties.
 
Versioning:
I agree about versioning. You should make sure to consider this on both import and export (i.e. if you get a STIX object from another tool that’s revoked, can you handle it correctly and,
if you create a STIX object that’s revoked, can you create it correctly).
 
Events:
Yeah I agree there’s not a great place for this now. CRITS had a similar type capability called “event” that, back in the STIX 1.x days, we aligned to a named package (which is now report)
because it was incident seemed excessive. If we add the event object in 2.1 that would work. If you want to do something for 2.0 I would consider either report (I don’t think a generic tool that got a report w/ your collection of data would be confused by
it, especially if you set a label to “event-report”) or custom object (aligned to your event proposal for 2.1) as a stopgap.
 
John

 
 

From:
<cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Friday, May 5, 2017 at 8:49 AM
To: "Alexandre.Dulaunoy@circl.lu" <Alexandre.Dulaunoy@circl.lu>
Cc: OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Subject: Re: [cti] MISP format <-> STIX 2.0 - Discussions


 

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?

- 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?



-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security

Without data, all you are is just another person with an opinion - Unknown




From:         Alexandre Dulaunoy <Alexandre.Dulaunoy@circl.lu>
To:         OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Date:         05/05/2017 07:29 AM
Subject:         [cti] MISP format <-> STIX 2.0 - Discussions
Sent by:         <cti@lists.oasis-open.org>






Hi All,

We recently had an extensive discussion within the MISP core team
for the MISP format conversion from/to STIX 2. We pinpointed
some issues and possible remedies (short-cuts?) on the following page:

https://github.com/MISP/MISP/wiki/NotesMISP-STIX2

As discussed with Trey, we would like to share our findings with
the community and are hoping to see whatever our solutions fit the
envisioned STIX 2 standard.

Thank you very much.

Cheers.

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

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

John,
 
To your very point and the examples Alexandre used, we’ve had to add a custom property that is a dictionary to hold exactly the kind of things that Alexandre is attempting to do for very
similar reasons.  “Tagging” is a very common and unfortunately often vendor specific thing, but a reality.
Like Alexandre did, we toyed with the idea of “encoding values” and putting them in labels, but it very unattractive and mixed the semantics defined for the use of labels on a given SDO. 
We also toyed with the idea of adding a custom property for each “tag”, but that quickly became unworkable.
 
It too bad we didn’t make labels a dictionary instead of a list of strings.
 
 
Paul Patrick
 
 

From:
<cti@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Friday, May 5, 2017 at 9:15 AM
To: OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Subject: Re: [cti] MISP format <-> STIX 2.0 - Discussions


 

Yeah this is a great writeup.
 
One thing I would consider as you (and others) are doing this comprehensively is the use of custom properties. Specifically, if there are cases where a generic
STIX tool (not coded support for your specific capabilities) just has no hope of doing something intelligent with the data you should probably use custom properties.
 
As an example, in the taxonomy section you have a label called "osint:source-type="blog-post"". If a generic tool gets that property it’ll probably just display
it to the user as it does with other labels…which in this case, kinda makes sense. It’s not ideal because there’s markup in there but it’s at least readable.
 
OTOH you also suggested putting Machine IDs into labels, which would give a label like "misp:to_ids:true". Would that make sense for a general tool to display to
the user? Would the user (who doesn’t know MISP) know what it means? I think the answer is no, so that seems like a good use for custom properties. Just add a generic property to the STIX object called {“x_misp_to_ids”: true}
 
Here are some specific comments…
Contextual Categories:
I agree that kill chain phases is the right place for this. I also like the idea of the TC somehow publishing a set of known kill chain and phase names so we get
better consistency. I don’t think it makes sense as part of the STIX spec itself, but maybe as a non-standards track work product (or, to be honest, just on our docs site would be better than nothing).
 
Taxonomies:
As I said above I think it makes sense to use labels for this. I’m not sure about having generic machine tags as a standard part of STIX…one of the key features
of STIX is to standardize on things, and so we probably just want to consider adding fields specific to the commonly used taxonomies.
 
That actually already applies to one of your labels…you have “tlp:amber” in there, but in STIX that should really go in data markings. That does mean that you probably
need to treat some of your taxonomies different than others.
 
Machine IDs:
I also don’t really understand this. As I said above, though, the best place to put it is probably custom properties.
 
Versioning:
I agree about versioning. You should make sure to consider this on both import and export (i.e. if you get a STIX object from another tool that’s revoked, can you
handle it correctly and, if you create a STIX object that’s revoked, can you create it correctly).
 
Events:
Yeah I agree there’s not a great place for this now. CRITS had a similar type capability called “event” that, back in the STIX 1.x days, we aligned to a named package
(which is now report) because it was incident seemed excessive. If we add the event object in 2.1 that would work. If you want to do something for 2.0 I would consider either report (I don’t think a generic tool that got a report w/ your collection of data
would be confused by it, especially if you set a label to “event-report”) or custom object (aligned to your event proposal for 2.1) as a stopgap.
 
John

 
 

From:
<cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Friday, May 5, 2017 at 8:49 AM
To: "Alexandre.Dulaunoy@circl.lu" <Alexandre.Dulaunoy@circl.lu>
Cc: OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Subject: Re: [cti] MISP format <-> STIX 2.0 - Discussions


 

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?

- 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?



-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security

Without data, all you are is just another person with an opinion - Unknown




From:         Alexandre Dulaunoy <Alexandre.Dulaunoy@circl.lu>
To:         OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Date:         05/05/2017 07:29 AM
Subject:         [cti] MISP format <-> STIX 2.0 - Discussions
Sent by:         <cti@lists.oasis-open.org>






Hi All,

We recently had an extensive discussion within the MISP core team
for the MISP format conversion from/to STIX 2. We pinpointed
some issues and possible remedies (short-cuts?) on the following page:

https://github.com/MISP/MISP/wiki/NotesMISP-STIX2

As discussed with Trey, we would like to share our findings with
the community and are hoping to see whatever our solutions fit the
envisioned STIX 2 standard.

Thank you very much.

Cheers.

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

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php








This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited.
If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

Ah, good feedback Paul…does anyone else have a similar namespaced tagging approach?
 
Maybe we should put a pin in this topic for either 2.1 or 2.2. I’m curious about what the cross-tool usages of the fields are…if it’s just displaying to users or searching on it, jamming
it into strings might not be so bad. If there’s automated processing based on specific tags though, obviously that doesn’t work so well. It would probably be useful to take some examples and run them through some sharing scenarios. Or maybe we’ll find out
everyone has the same set of “vendor-specific” tags and we literally can just standardize on them.
 
John
 

From:
Paul Patrick <Paul.Patrick@FireEye.com>
Date: Friday, May 5, 2017 at 9:26 AM
To: John Wunder <jwunder@mitre.org>, OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Subject: Re: [cti] MISP format <-> STIX 2.0 - Discussions


 

John,
 
To your very point and the examples Alexandre used, we’ve had to add a custom property that is a dictionary to hold exactly the kind of things that Alexandre is attempting to do for very
similar reasons.  “Tagging” is a very common and unfortunately often vendor specific thing, but a reality.
Like Alexandre did, we toyed with the idea of “encoding values” and putting them in labels, but it very unattractive and mixed the semantics defined for the use of labels on a given SDO. 
We also toyed with the idea of adding a custom property for each “tag”, but that quickly became unworkable.
 
It too bad we didn’t make labels a dictionary instead of a list of strings.
 
 
Paul Patrick
 
 

From:
<cti@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Friday, May 5, 2017 at 9:15 AM
To: OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Subject: Re: [cti] MISP format <-> STIX 2.0 - Discussions


 

Yeah this is a great writeup.
 
One thing I would consider as you (and others) are doing this comprehensively is the use of custom properties. Specifically, if there are cases where a generic
STIX tool (not coded support for your specific capabilities) just has no hope of doing something intelligent with the data you should probably use custom properties.
 
As an example, in the taxonomy section you have a label called "osint:source-type="blog-post"". If a generic tool gets that property it’ll probably just display
it to the user as it does with other labels…which in this case, kinda makes sense. It’s not ideal because there’s markup in there but it’s at least readable.
 
OTOH you also suggested putting Machine IDs into labels, which would give a label like "misp:to_ids:true". Would that make sense for a general tool to display to
the user? Would the user (who doesn’t know MISP) know what it means? I think the answer is no, so that seems like a good use for custom properties. Just add a generic property to the STIX object called {“x_misp_to_ids”: true}
 
Here are some specific comments…
Contextual Categories:
I agree that kill chain phases is the right place for this. I also like the idea of the TC somehow publishing a set of known kill chain and phase names so we get
better consistency. I don’t think it makes sense as part of the STIX spec itself, but maybe as a non-standards track work product (or, to be honest, just on our docs site would be better than nothing).
 
Taxonomies:
As I said above I think it makes sense to use labels for this. I’m not sure about having generic machine tags as a standard part of STIX…one of the key features
of STIX is to standardize on things, and so we probably just want to consider adding fields specific to the commonly used taxonomies.
 
That actually already applies to one of your labels…you have “tlp:amber” in there, but in STIX that should really go in data markings. That does mean that you probably
need to treat some of your taxonomies different than others.
 
Machine IDs:
I also don’t really understand this. As I said above, though, the best place to put it is probably custom properties.
 
Versioning:
I agree about versioning. You should make sure to consider this on both import and export (i.e. if you get a STIX object from another tool that’s revoked, can you
handle it correctly and, if you create a STIX object that’s revoked, can you create it correctly).
 
Events:
Yeah I agree there’s not a great place for this now. CRITS had a similar type capability called “event” that, back in the STIX 1.x days, we aligned to a named package
(which is now report) because it was incident seemed excessive. If we add the event object in 2.1 that would work. If you want to do something for 2.0 I would consider either report (I don’t think a generic tool that got a report w/ your collection of data
would be confused by it, especially if you set a label to “event-report”) or custom object (aligned to your event proposal for 2.1) as a stopgap.
 
John

 
 

From:
<cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Friday, May 5, 2017 at 8:49 AM
To: "Alexandre.Dulaunoy@circl.lu" <Alexandre.Dulaunoy@circl.lu>
Cc: OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Subject: Re: [cti] MISP format <-> STIX 2.0 - Discussions


 

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?

- 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?



-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security

Without data, all you are is just another person with an opinion - Unknown




From:         Alexandre Dulaunoy <Alexandre.Dulaunoy@circl.lu>
To:         OASIS CTI TC Discussion List <cti@lists.oasis-open.org>
Date:         05/05/2017 07:29 AM
Subject:         [cti] MISP format <-> STIX 2.0 - Discussions
Sent by:         <cti@lists.oasis-open.org>








Hi All,

We recently had an extensive discussion within the MISP core team
for the MISP format conversion from/to STIX 2. We pinpointed
some issues and possible remedies (short-cuts?) on the following page:

https://github.com/MISP/MISP/wiki/NotesMISP-STIX2

As discussed with Trey, we would like to share our findings with
the community and are hoping to see whatever our solutions fit the
envisioned STIX 2 standard.

Thank you very much.

Cheers.

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

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php








This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is
strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

On 05/05/17 15:44, Wunder, John A. wrote: > Ah, good feedback Paul…does anyone else have a similar namespaced tagging approach? > > Maybe we should put a pin in this topic for either 2.1 or 2.2. I’m curious about what the cross-tool usages of the fields are…if it’s just displaying to users or searching on it, jamming it into strings might not be so bad. If there’s automated processing based on specific tags though, obviously that doesn’t work so well. It would probably be useful to take some examples and run them through some sharing scenarios. Or maybe we’ll find out everyone has the same set of “vendor-specific” tags and we literally can just standardize on them. Our idea in general was two cover to use-cases in general, one as you mentioned is automation (though with the purpose of filtering based on known tags, something that we publish through open taxonomies, see RFC below[1]) but also to have a humanly readable format for the analysts. Basically the translation of the triple and double tags is super simplistic: "europol-incident:abusive-content="content-forbidden-by-law" In this case the representation would simply tell the user that the tag is from the Europol Incident vocabulary and that the tagged item is related to abusive content due to content forbidden by law. For double tags, such as "PAP:red" ref:[2] we would simply indicate to the user that we are using the PAP vocabulary, and the tagged item is marked red. What the user does with this (filtering, using it as contextual information) is up to the end-user. We have employed this for the past year or two for MISP and it quickly became one of the most crucial components of the information shared with communities becoming incredibly involved in creating and maintaining taxonomies. [1] https://github.com/MISP/misp-rfc/blob/master/misp-taxonomy-format/raw.md.txt [2] https://www.misp.software/taxonomies.html#_pap -- Alexandre Dulaunoy CIRCL - Computer Incident Response Center Luxembourg 41, avenue de la gare L-1611 Luxembourg info@circl.lu - www.circl.lu

Unfortunately, we’re running into issues with none standardized tagging in our current systems now.  Each vendor does have their own tagging formate for example: APT-1 apt1 Apt 1 apt-1 When a search is done on APT-1 not all the results are returned because half the data is tagged wth apt1.  I can probably generate many more uses cases.  The question that should be ask is, do we leave the standardizing of tagging to the working group or do we leave it with the vendors?  Are we prepared to take on that challenge? Best Regards,  Nicholas Hayden, CISSP, GICSP, CNDA, CEH, Sec+  Director of Engineering Anomali   anomali.com 808 Winslow St Redwood City, CA 94063 Phone: (650) 257-0867 Twitter: @anomali On May 5, 2017, at 9:44 AM, Wunder, John A. < jwunder@mitre.org > wrote: Ah, good feedback Paul…does anyone else have a similar namespaced tagging approach?   Maybe we should put a pin in this topic for either 2.1 or 2.2. I’m curious about what the cross-tool usages of the fields are…if it’s just displaying to users or searching on it, jamming it into strings might not be so bad. If there’s automated processing based on specific tags though, obviously that doesn’t work so well. It would probably be useful to take some examples and run them through some sharing scenarios. Or maybe we’ll find out everyone has the same set of “vendor-specific” tags and we literally can just standardize on them.   John   From:   Paul Patrick < Paul.Patrick@FireEye.com > Date:   Friday, May 5, 2017 at 9:26 AM To:   John Wunder < jwunder@mitre.org >, OASIS CTI TC Discussion List < cti@lists.oasis-open.org > Subject:   Re: [cti] MISP format <-> STIX 2.0 - Discussions   John,   To your very point and the examples Alexandre used, we’ve had to add a custom property that is a dictionary to hold exactly the kind of things that Alexandre is attempting to do for very similar reasons.  “Tagging” is a very common and unfortunately often vendor specific thing, but a reality. Like Alexandre did, we toyed with the idea of “encoding values” and putting them in labels, but it very unattractive and mixed the semantics defined for the use of labels on a given SDO.  We also toyed with the idea of adding a custom property for each “tag”, but that quickly became unworkable.   It too bad we didn’t make labels a dictionary instead of a list of strings.     Paul Patrick     From:   < cti@lists.oasis-open.org > on behalf of Wunder, John A. < jwunder@mitre.org > Date:   Friday, May 5, 2017 at 9:15 AM To:   OASIS CTI TC Discussion List < cti@lists.oasis-open.org > Subject:   Re: [cti] MISP format <-> STIX 2.0 - Discussions   Yeah this is a great writeup.   One thing I would consider as you (and others) are doing this comprehensively is the use of custom properties. Specifically, if there are cases where a generic STIX tool (not coded support for your specific capabilities) just has no hope of doing something intelligent with the data you should probably use custom properties.   As an example, in the taxonomy section you have a label called osint:source-type= blog-post . If a generic tool gets that property it’ll probably just display it to the user as it does with other labels…which in this case, kinda makes sense. It’s not ideal because there’s markup in there but it’s at least readable.   OTOH you also suggested putting Machine IDs into labels, which would give a label like misp:to_ids:true . Would that make sense for a general tool to display to the user? Would the user (who doesn’t know MISP) know what it means? I think the answer is no, so that seems like a good use for custom properties. Just add a generic property to the STIX object called {“x_misp_to_ids”: true}   Here are some specific comments… Contextual Categories: I agree that kill chain phases is the right place for this. I also like the idea of the TC somehow publishing a set of known kill chain and phase names so we get better consistency. I don’t think it makes sense as part of the STIX spec itself, but maybe as a non-standards track work product (or, to be honest, just on our docs site would be better than nothing).   Taxonomies: As I said above I think it makes sense to use labels for this. I’m not sure about having generic machine tags as a standard part of STIX…one of the key features of STIX is to standardize on things, and so we probably just want to consider adding fields specific to the commonly used taxonomies.   That actually already applies to one of your labels…you have “tlp:amber” in there, but in STIX that should really go in data markings. That does mean that you probably need to treat some of your taxonomies different than others.   Machine IDs: I also don’t really understand this. As I said above, though, the best place to put it is probably custom properties.   Versioning: I agree about versioning. You should make sure to consider this on both import and export (i.e. if you get a STIX object from another tool that’s revoked, can you handle it correctly and, if you create a STIX object that’s revoked, can you create it correctly).   Events: Yeah I agree there’s not a great place for this now. CRITS had a similar type capability called “event” that, back in the STIX 1.x days, we aligned to a named package (which is now report) because it was incident seemed excessive. If we add the event object in 2.1 that would work. If you want to do something for 2.0 I would consider either report (I don’t think a generic tool that got a report w/ your collection of data would be confused by it, especially if you set a label to “event-report”) or custom object (aligned to your event proposal for 2.1) as a stopgap.   John     From:   < cti@lists.oasis-open.org > on behalf of Jason Keirstead < Jason.Keirstead@ca.ibm.com > Date:   Friday, May 5, 2017 at 8:49 AM To:   Alexandre.Dulaunoy@circl.lu < Alexandre.Dulaunoy@circl.lu > Cc:   OASIS CTI TC Discussion List < cti@lists.oasis-open.org > Subject:   Re: [cti] MISP format <-> STIX 2.0 - Discussions   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? - 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? - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security Without data, all you are is just another person with an opinion - Unknown   From:         Alexandre Dulaunoy < Alexandre.Dulaunoy@circl.lu > To:         OASIS CTI TC Discussion List < cti@lists.oasis-open.org > Date:         05/05/2017 07:29 AM Subject:         [cti] MISP format <-> STIX 2.0 - Discussions Sent by:         < cti@lists.oasis-open.org > Hi All, We recently had an extensive discussion within the MISP core team for the MISP format conversion from/to STIX 2. We pinpointed some issues and possible remedies (short-cuts?) on the following page: https://github.com/MISP/MISP/wiki/NotesMISP-STIX2 As discussed with Trey, we would like to share our findings with the community and are hoping to see whatever our solutions fit the envisioned STIX 2 standard. Thank you very much. Cheers. --   Alexandre Dulaunoy CIRCL - Computer Incident Response Center Luxembourg 41, avenue de la gare L-1611 Luxembourg info@circl.lu   -   www.circl.lu --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that   generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

On 08/05/17 14:48, Nicholas Hayden wrote: > Unfortunately, we’re running into issues with none standardized tagging in our > current systems now. Each vendor does have their own tagging formate for example: > > APT-1 > apt1 > Apt 1 > apt-1 > > When a search is done on APT-1 not all the results are returned because half the > data is tagged wth apt1. I can probably generate many more uses cases. The > question that should be ask is, do we leave the standardizing of tagging to the > working group or do we leave it with the vendors? Are we prepared to take on > that challenge? It's indeed a huge challenge and that's what we tried do this for the past 2 years with MISP taxonomies[1] and galaxy[2]. The taxonomies are there to help users to find the right the tagging (the taxonomy project started due to organisations using free tagging and formatting on their own like tlp:amber tlp-amber or tlp_amber or tlp amber). We can see nowadays that when a MISP community enables a taxonomy then they tend to be consistent with the naming as it's easier to use a existing namespace than starting your own tagging. For the threat-actor (as an example) in a cluster galaxy, we use a synonym list to support the cases where users tend to name an element with a different name: { "meta": { "synonyms": [ "Comment Panda", "PLA Unit 61398", "APT 1", "Advanced Persistent Threat 1", "Byzantine Candor", "Group 3", "TG-8223", "Comment Group" ], "country": "CN", "refs": [ " https://en.wikipedia.org/wiki/PLA_Unit_61398" ;, " http://intelreport.mandiant.com/Mandiant_APT1_Report.pdf" ; ] }, "description": "PLA Unit 61398 (Chinese: 61398??, Pinyin: 61398 bùduì) is the Military Unit Cover Designator (MUCD)[1] of a People's Liberation Army advanced persistent threat unit that has been alleged to be a source of Chinese computer hacking attacks", "value": "Comment Crew" } During the face-2-face meeting in Brussels, we had a small discussion to use the existing MISP taxonomy as vocabularies, marking or label. But the final conclusion was to use only label as is with the expanded namespace. In our point of view, this is a partial solution and doesn't support well more advanced use cases. As some vendors are already using our taxonomies or galaxy in their product, we won't mind to reuse this and provide a way to map those into STIX properly[3] (still an open discussion). Just my 2 cents. [1] https://github.com/MISP/misp-taxonomies https://www.misp.software/taxonomies.html https://www.misp.software/taxonomies.pdf [2] https://github.com/MISP/misp-galaxy/ https://www.misp.software/galaxy.html https://www.misp.software/galaxy.pdf [3] https://github.com/MISP/MISP/wiki/NotesMISP-STIX2 -- Alexandre Dulaunoy CIRCL - Computer Incident Response Center Luxembourg 41, avenue de la gare L-1611 Luxembourg info@circl.lu - www.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

Alex,


Just to clarify, in versioning, there is no property called "version"


Bret 

Sent from my Commodore 64 


PGP
Fingerprint:  63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050


On May 5, 2017, at 4:29 AM, Alexandre Dulaunoy < Alexandre.Dulaunoy@circl.lu > wrote:



Hi All,

We recently had an extensive discussion within the MISP core team
for the MISP format conversion from/to STIX 2. We pinpointed
some issues and possible remedies (short-cuts?) on the following page:

https://clicktime.symantec.com/a/1/AYFKJy51ZkUQorOxJBqBbl0M_xQCq-gx75KcZRo2Wi8=?d=ylrbjzqBiNwqHD6-2e1eAItNlZcy2ZmvmEZP4UkiUK_a-vFqDRv9uCzf0Dg1PUEsMHN8W5lDD_pbrrola-WOcJ0hLP7I0EUhpxiI58eL62v2BCBuvolZ1He8Eb_TS2-vDdShPaGn0B38t6QJVIqrxUzFDhXbzMDLNMEkCFmkAEIx_9ol5M9Sm4kLzuv7N8GgUA7A9NWp84V9_MAEyiElWLhit5XExgRdniNaenqHp6jkGbI60p_EyCpMI1lxzi9z5wD7HyWj-nSq0yiDiTvy_2DAvU08W-LUjcBMYY0laDTqqFqlM61qox8ocHfaXjYYiqwm5jCSolgSR5kYPIDQnMSU150svNx8w1On4Ir0Bo2tVze5US44VA75X0HKMdl-nVKCOGB1cfPuQHhKUbJZgvsr2ku4rLc5BZQRK26pJCJJnWxPoEWLP64QK0D3&u=https%3A%2F%2Fgithub.com%2FMISP%2FMISP%2Fwiki%2FNotesMISP-STIX2

As discussed with Trey, we would like to share our findings with
the community and are hoping to see whatever our solutions fit the
envisioned STIX 2 standard.

Thank you very much.

Cheers.

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

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php