CTI STIX Subcommittee

Hi list,   I understand that at the F2F there was a proposal to remove namespacing from the STIX ID, so that it would become [construct-type]:[UUID]. This has me a little concerned, as the ID has more of an impact than many people realize. As such, I’ve typed up a wee* little** discussion email to outline my concerns.   1.       It reduces the chances that object libraries will work ------------------------------------------------------------------------- John Wunder and I had been talking about enabling organizations to share easy to remember 'library' IDs. It would be cool if everyone had the ability to actually refer to the single lockheed martin kill chain as the 'lmco.com-kill-chain' for its ID, or an attack-pattern by 'mitre.org-capec-217'.   The problem is that the [construct-type]:[UUID] ID format is that it precludes that usage. People will instead be forced to use a randomly generated UUID, and each implementation will need to remember what that is and translate the horrible UUID to a human readable thing. SNMP OIDs anyone? (yuck)   A different option would be to allow IDs of the type [construct-type]:[anytext], but that then has a huge problem that there will likely be collisions due to the fact many people think similarly, and will reuse object IDs. This could in turn be fixed by introducing a namespace of some type to constrain the collisions to a small domain controlled by one organization… which leads us back to the [producer-domain-name]:[construct-type]:[anytext] mentioned in the TWIGS proposal.   Being pragmatic about it there are a few options we could use to enable the object library idea to work: a.       With the suggested ID format [construct-type]:[UUID] In this option, we just let the implementation worry about it, and go around asking Mitre, Lockheed martin and others to produce a list of useful objects and we provide a list of their Object IDs centrally . We will need to maintain a list of commonly used library objects, similarly to the IANA common port numbers, or the IANA common list of MIM Types. Implementers then just use this list to provide the common library objects within their implementations to all their users.   This puts more onus on the implementers to provide the same names to the users in their UI, mapping the actual Object IDs to real human readable names, and it means the name of the library object may change between various implementations, which could be problematic for users. We can mitigate that last point by proving a ‘suggested name’ as part of the list of Object IDs.   b.       With the suggested ID format  [construct-type]:[UUID] and an alternate ID format of lib:[construct-type]:[anytext] It might be useful to allow a special type of ID to be used for library objects? This could get messy very quickly.   c.        With the ID format [producer_domain_name]:[construct-type]:[UUID] This is untenable for Organizations that wish to remain anonymous. Terrys Recommendation: I believe that option 1 can work if we provide a list of library objects, and we provide their recommended names in a centrally controlled JSON file provided by OASIS or a nominated third-party, in a similar way to what IANA does for TCP/UDP port numbers.   2.       Consumers need to know who to ask for more information --------------------------------------------------------------------------------- Sharing relationship objects enables a consumer to recognize that there is an indirect connection between two objects, and they are related, even if the consumer does not have access to the intermediate object itself. This feature allows government CERT types to share just indicators and relationships, and to keep the threat actor that joins them together a secret (apart from the Object ID). This in turn allows the consumers to know that if they see one indicator on their network, they really need look for the other indirectly related indicators associated with that threat actor.   This feature also works well for bandwidth conservation. Rather than push out a full selection of relationship objects and their matching target objects, implementers will be potentially able to only push out the relationship objects, and the consumers will be able to request more information when they want it or need it. In many cases consumers only want to know that the objects are related – they don’t care why.   To cope with these two scenarios, TWIGS provided the ability for the producers to only send out relationships, and for consumers to ask for more information about those objects if they wanted it. The producer could always say no, but the option was always there.   Having the producer’s domain name within the ID ensured that there is a way for the consumer to know who to ask for more information about the object being discussed. This is most important when a consumer receives only relationship objects (edges), and no data objects (nodes). In this scenario we need a way for the relationship object to always contain the domain name of someone who is ultimately able to provide the object to the consumer if the consumer asks for it (and only if the producer allows them to have it).   I am fine with the producer’s domain name information being separated out from the ID field, but it really needs to be available somewhere else right next to the object ID if we are going to provide consumers a way to ask for more information easily. This will mean we will need to include a producer_domain_name field in the relationship object for the source_ref and for the target_ref objects to ensure that this data is transmitted and is available to the consumers.   The idea for normal (there is a producer_domain_name set) operations, works like this: ·          The producer_domain_name field contains a string representing the domain name of the producer. ·          The consumer would perform a DNS lookup against the DNS Server that is authoratitive for the producers domain name, and requests a TAXII service record. ·          The returned TAXII Service record would in turn point to the location of the TAXII Server for that organization. ·          The consumers TAXII server would then connect directly to the producers TAXII server and request the object ID using TAXII Query. I am assuming that the groups who didn’t want producer domain name contained are the military/government intel types who wanted a way to remain anonymous. This is an important concern if we are actually going to get government -> private industry sharing to take place.  Well as I see it there are two options allowing requests of objects by ID while still allowing the producer to remain anonymous: a.       If the producers wish to remain anonymous and still get sightings sent directly to them: This is a modification of what I proposed in the ‘STIX is difficult’ document I produced for Soltra. It would require the producer_domain_name to ALWAYS be sent along with the ID, so that the producer is known. If a producer wishes to be anonymous, they would need to use a ‘proxy’ organization to ‘hide behind’. The proxy organization would replace the original producer’s domain name with their domain name, and would forward on the translated assertion, so that everyone else in the community would see the information coming from the proxy organization. If anyone replies with a sighting they can reply to the group, or directly to the proxy org. The Proxy org will then reverse the process, translating the proxied object ID back to the original object ID and will then send it on to the anonymous original producer. This has a massive plus in that the consumers always know who to contact to request more information about an object, so that if they have only received a relationship, they can ask for the objects that the relationship refers to by directly requesting it from the producer (as they know the domain name and can do a TAXII lookup). For clarity this would use a direct TAXII query to the producer’s TAXII server to get the Object. This has a massive downside that the producer must always use a proxy organization. Organizations have a hard enough time setting up a single TAXII server at present. b.       If the producers wish to remain anonymous and only see sightings sent to the whole community: In this scenario the producer_domain_name field is OPTIONAL, although when available is sent along with the ID.  If a producer wishes to be anonymous, they would simply need to omit the producer_domain_name field when they publish their assertion. The consumers have no idea who the producer is and are unable to ask them directly for more information. Any relationships asserted to the whole community will be able to be seen by the original producer if they are a community member.   Thinking about it we could still enable the consumers to ask the community/group for the ID, by creating a STIX Request (broadcast to the community) that asks for a particular Object ID. Allowing this feature will ensure that the original anonymous producer is able to view the request (along with everyone else in the community/group), and if they want to, will be able to either send the STIX Response directly to the requester (unicast/decloaks the producer) or broadcast out the STIX Response with the Object to the community (broadcast/producer remains anonymous). In either case the consumer still gets what they want (the information), yet the producer can remain anonymous if they want). Note - Allowing STIX Request/Response to do Object ID requests/replies is partially replicating the function provided by TAXII Query by Object ID, but has an important distinction – it is indirect and broadcast-based. It is analogous to a proxy-arp. It is not something that TAXII Query would be able to do as TAXII Query only works with single client to single server communication. We would need STIX requests/response functionality if we are going to be able to allow consumers to request an Object by ID indirectly using broadcasts out to the whole sharing community/group. If a producer does include a producer_domain_name field then the consumer is able to follow the process described in option 1, and is able to directly request the Object via a TAXII Query by Object ID. Option b will work irrespective of where the data is encapsulated within the object structure. It was mentioned to me that Gary Katz had suggested extracting the producer’s domain_name field into a separate ‘exports’ data structure within the message – independent of the object itself. This could work, but I would discourage it. In my opinion all data about an object should be kept with that object. It’s the concept of tight cohesion, loose coupling. It makes it far easier to ‘move’ the object around as a whole complete thing rather than having bits of the object strewn across the structure. I believe that the producer_domain_name should live right next to the ID.   Terrys Recommendation: I believe that option 2 represents the most flexible option for both anonymous and conspicuous producers.  It allows an indirect, broadcast based request for Object by ID/response containing Object to allow anonymous producers to still communicate, yet allows the standard process of direct unicast TAXII Queries to occur.   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com   -- * Not so wee ** Not so little    

Terry, [footnotes in brackets at the bottom] What about actual URLs? (Not URIs  [1].) Let's actually use  http: and make our Resources resolvable via the Web. (And maybe even let Google index some of them!) I love your idea about having meaningful IDs . This screams for Cool URLs  [2]. Like this one:  http://www.discovery.com/tv-shows/mythbusters/videos/juicing-a-tomato-with-explosives/  (I mean, who wouldn't want to see vegetables go kaboom?!)  The same hide-behind-a-proxy idea of yours would still work...with the added benefit that the proxy could be a real proxy server and could actually...um... proxy the Resource. Maybe we could leverage existing technology that has already solved this problem. [3] Also, you raised an interesting question:  Where to go for more context about an object? With URL-as-ID, then you could simply hack bits and see what else is around there.  (Think: "If I have that previous Cool URL, then what do I get when I hack off the juicing-a-tomato-with-explosives bit?") Why can't we apply hackable URLs in our context as well? [4] tl;dr - Are there any insurmountable technical obstacles to using  URLs for IDs? JSA [1]  https://www.w3.org/TR/uri-clarification/#contemporary  - URIs, URLs, and URNs: Clarifications and Recommendations 1.0, Section 2.1 "Contemporary View" [2]  https://www.w3.org/Provider/Style/URI.html  - Sir  Tim Berners-Lee's advice on the subject. [3]  http://httpd.apache.org/docs/2.2/mod/mod_proxy.html  - Apache...proxying content worldwide since 1995! [4] This was somewhat of a trick question. The experienced web architect will point out that the context question isn't really solved by hackable URLs. What we really need are Link Relations. Curious? Read  Fielding Chapter 5 . From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald <terry@soltra.com> Sent: Wednesday, January 20, 2016 6:47 PM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] Object ID format   Hi list,   I understand that at the F2F there was a proposal to remove namespacing from the STIX ID, so that it would become [construct-type]:[UUID]. This has me a little concerned, as the ID has more of an impact than many people realize. As such, I’ve typed up a wee* little** discussion email to outline my concerns.   1.       It reduces the chances that object libraries will work ------------------------------------------------------------------------- John Wunder and I had been talking about enabling organizations to share easy to remember 'library' IDs. It would be cool if everyone had the ability to actually refer to the single lockheed martin kill chain as the 'lmco.com-kill-chain' for its ID, or an attack-pattern by 'mitre.org-capec-217'.   The problem is that the [construct-type]:[UUID] ID format is that it precludes that usage. People will instead be forced to use a randomly generated UUID, and each implementation will need to remember what that is and translate the horrible UUID to a human readable thing. SNMP OIDs anyone? (yuck)   A different option would be to allow IDs of the type [construct-type]:[anytext], but that then has a huge problem that there will likely be collisions due to the fact many people think similarly, and will reuse object IDs. This could in turn be fixed by introducing a namespace of some type to constrain the collisions to a small domain controlled by one organization… which leads us back to the [producer-domain-name]:[construct-type]:[anytext] mentioned in the TWIGS proposal.   Being pragmatic about it there are a few options we could use to enable the object library idea to work: a.       With the suggested ID format [construct-type]:[UUID] In this option, we just let the implementation worry about it, and go around asking Mitre, Lockheed martin and others to produce a list of useful objects and we provide a list of their Object IDs centrally . We will need to maintain a list of commonly used library objects, similarly to the IANA common port numbers, or the IANA common list of MIM Types. Implementers then just use this list to provide the common library objects within their implementations to all their users.   This puts more onus on the implementers to provide the same names to the users in their UI, mapping the actual Object IDs to real human readable names, and it means the name of the library object may change between various implementations, which could be problematic for users. We can mitigate that last point by proving a ‘suggested name’ as part of the list of Object IDs.   b.       With the suggested ID format  [construct-type]:[UUID] and an alternate ID format of lib:[construct-type]:[anytext] It might be useful to allow a special type of ID to be used for library objects? This could get messy very quickly.   c.        With the ID format [producer_domain_name]:[construct-type]:[UUID] This is untenable for Organizations that wish to remain anonymous. Terrys Recommendation: I believe that option 1 can work if we provide a list of library objects, and we provide their recommended names in a centrally controlled JSON file provided by OASIS or a nominated third-party, in a similar way to what IANA does for TCP/UDP port numbers.   2.       Consumers need to know who to ask for more information --------------------------------------------------------------------------------- Sharing relationship objects enables a consumer to recognize that there is an indirect connection between two objects, and they are related, even if the consumer does not have access to the intermediate object itself. This feature allows government CERT types to share just indicators and relationships, and to keep the threat actor that joins them together a secret (apart from the Object ID). This in turn allows the consumers to know that if they see one indicator on their network, they really need look for the other indirectly related indicators associated with that threat actor.   This feature also works well for bandwidth conservation. Rather than push out a full selection of relationship objects and their matching target objects, implementers will be potentially able to only push out the relationship objects, and the consumers will be able to request more information when they want it or need it. In many cases consumers only want to know that the objects are related – they don’t care why.   To cope with these two scenarios, TWIGS provided the ability for the producers to only send out relationships, and for consumers to ask for more information about those objects if they wanted it. The producer could always say no, but the option was always there.   Having the producer’s domain name within the ID ensured that there is a way for the consumer to know who to ask for more information about the object being discussed. This is most important when a consumer receives only relationship objects (edges), and no data objects (nodes). In this scenario we need a way for the relationship object to always contain the domain name of someone who is ultimately able to provide the object to the consumer if the consumer asks for it (and only if the producer allows them to have it).   I am fine with the producer’s domain name information being separated out from the ID field, but it really needs to be available somewhere else right next to the object ID if we are going to provide consumers a way to ask for more information easily. This will mean we will need to include a producer_domain_name field in the relationship object for the source_ref and for the target_ref objects to ensure that this data is transmitted and is available to the consumers.   The idea for normal (there is a producer_domain_name set) operations, works like this: ·          The producer_domain_name field contains a string representing the domain name of the producer. ·          The consumer would perform a DNS lookup against the DNS Server that is authoratitive for the producers domain name, and requests a TAXII service record. ·          The returned TAXII Service record would in turn point to the location of the TAXII Server for that organization. ·          The consumers TAXII server would then connect directly to the producers TAXII server and request the object ID using TAXII Query. I am assuming that the groups who didn’t want producer domain name contained are the military/government intel types who wanted a way to remain anonymous. This is an important concern if we are actually going to get government -> private industry sharing to take place.  Well as I see it there are two options allowing requests of objects by ID while still allowing the producer to remain anonymous: a.       If the producers wish to remain anonymous and still get sightings sent directly to them: This is a modification of what I proposed in the ‘STIX is difficult’ document I produced for Soltra. It would require the producer_domain_name to ALWAYS be sent along with the ID, so that the producer is known. If a producer wishes to be anonymous, they would need to use a ‘proxy’ organization to ‘hide behind’. The proxy organization would replace the original producer’s domain name with their domain name, and would forward on the translated assertion, so that everyone else in the community would see the information coming from the proxy organization. If anyone replies with a sighting they can reply to the group, or directly to the proxy org. The Proxy org will then reverse the process, translating the proxied object ID back to the original object ID and will then send it on to the anonymous original producer. This has a massive plus in that the consumers always know who to contact to request more information about an object, so that if they have only received a relationship, they can ask for the objects that the relationship refers to by directly requesting it from the producer (as they know the domain name and can do a TAXII lookup). For clarity this would use a direct TAXII query to the producer’s TAXII server to get the Object. This has a massive downside that the producer must always use a proxy organization. Organizations have a hard enough time setting up a single TAXII server at present. b.       If the producers wish to remain anonymous and only see sightings sent to the whole community: In this scenario the producer_domain_name field is OPTIONAL, although when available is sent along with the ID.  If a producer wishes to be anonymous, they would simply need to omit the producer_domain_name field when they publish their assertion. The consumers have no idea who the producer is and are unable to ask them directly for more information. Any relationships asserted to the whole community will be able to be seen by the original producer if they are a community member.   Thinking about it we could still enable the consumers to ask the community/group for the ID, by creating a STIX Request (broadcast to the community) that asks for a particular Object ID. Allowing this feature will ensure that the original anonymous producer is able to view the request (along with everyone else in the community/group), and if they want to, will be able to either send the STIX Response directly to the requester (unicast/decloaks the producer) or broadcast out the STIX Response with the Object to the community (broadcast/producer remains anonymous). In either case the consumer still gets what they want (the information), yet the producer can remain anonymous if they want). Note - Allowing STIX Request/Response to do Object ID requests/replies is partially replicating the function provided by TAXII Query by Object ID, but has an important distinction – it is indirect and broadcast-based. It is analogous to a proxy-arp. It is not something that TAXII Query would be able to do as TAXII Query only works with single client to single server communication. We would need STIX requests/response functionality if we are going to be able to allow consumers to request an Object by ID indirectly using broadcasts out to the whole sharing community/group. If a producer does include a producer_domain_name field then the consumer is able to follow the process described in option 1, and is able to directly request the Object via a TAXII Query by Object ID. Option b will work irrespective of where the data is encapsulated within the object structure. It was mentioned to me that Gary Katz had suggested extracting the producer’s domain_name field into a separate ‘exports’ data structure within the message – independent of the object itself. This could work, but I would discourage it. In my opinion all data about an object should be kept with that object. It’s the concept of tight cohesion, loose coupling. It makes it far easier to ‘move’ the object around as a whole complete thing rather than having bits of the object strewn across the structure. I believe that the producer_domain_name should live right next to the ID.   Terrys Recommendation: I believe that option 2 represents the most flexible option for both anonymous and conspicuous producers.  It allows an indirect, broadcast based request for Object by ID/response containing Object to allow anonymous producers to still communicate, yet allows the standard process of direct unicast TAXII Queries to occur.   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com   -- * Not so wee ** Not so little    

Hi John,   The wish of some producers to be anonymous is the reason there can’t be a mandatory producer’s domain name (or URL). It has to be optional. Hence section 2.   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA   An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com     From: John Anderson Sent: Thursday, 21 January 2016 1:02 PM To: Terry MacDonald <terry@soltra.com>; cti-stix@lists.oasis-open.org Subject: Re: Object ID format   Terry, [footnotes in brackets at the bottom] What about actual URLs? (Not URIs [1].) Let's actually use  http: and make our Resources resolvable via the Web. (And maybe even let Google index some of them!)   I love your idea about having meaningful IDs . This screams for Cool URLs  [2]. Like this one:  http://www.discovery.com/tv-shows/mythbusters/videos/juicing-a-tomato-with-explosives/  (I mean, who wouldn't want to see vegetables go kaboom?!)    The same hide-behind-a-proxy idea of yours would still work...with the added benefit that the proxy could be a real proxy server and could actually...um... proxy the Resource. Maybe we could leverage existing technology that has already solved this problem. [3]   Also, you raised an interesting question:  Where to go for more context about an object? With URL-as-ID, then you could simply hack bits and see what else is around there.  (Think: "If I have that previous Cool URL, then what do I get when I hack off the juicing-a-tomato-with-explosives bit?") Why can't we apply hackable URLs in our context as well? [4]   tl;dr - Are there any insurmountable technical obstacles to using URLs for IDs? JSA   [1]  https://www.w3.org/TR/uri-clarification/#contemporary  - URIs, URLs, and URNs: Clarifications and Recommendations 1.0, Section 2.1 "Contemporary View" [2]  https://www.w3.org/Provider/Style/URI.html  - Sir  Tim Berners-Lee's advice on the subject. [3]  http://httpd.apache.org/docs/2.2/mod/mod_proxy.html  - Apache...proxying content worldwide since 1995! [4] This was somewhat of a trick question. The experienced web architect will point out that the context question isn't really solved by hackable URLs. What we really need are Link Relations. Curious? Read  Fielding Chapter 5 . From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of Terry MacDonald < terry@soltra.com > Sent: Wednesday, January 20, 2016 6:47 PM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] Object ID format   Hi list,   I understand that at the F2F there was a proposal to remove namespacing from the STIX ID, so that it would become [construct-type]:[UUID]. This has me a little concerned, as the ID has more of an impact than many people realize. As such, I’ve typed up a wee* little** discussion email to outline my concerns.   1.       It reduces the chances that object libraries will work ------------------------------------------------------------------------- John Wunder and I had been talking about enabling organizations to share easy to remember 'library' IDs. It would be cool if everyone had the ability to actually refer to the single lockheed martin kill chain as the 'lmco.com-kill-chain' for its ID, or an attack-pattern by 'mitre.org-capec-217'.   The problem is that the [construct-type]:[UUID] ID format is that it precludes that usage. People will instead be forced to use a randomly generated UUID, and each implementation will need to remember what that is and translate the horrible UUID to a human readable thing. SNMP OIDs anyone? (yuck)   A different option would be to allow IDs of the type [construct-type]:[anytext], but that then has a huge problem that there will likely be collisions due to the fact many people think similarly, and will reuse object IDs. This could in turn be fixed by introducing a namespace of some type to constrain the collisions to a small domain controlled by one organization… which leads us back to the [producer-domain-name]:[construct-type]:[anytext] mentioned in the TWIGS proposal.   Being pragmatic about it there are a few options we could use to enable the object library idea to work: a.       With the suggested ID format [construct-type]:[UUID] In this option, we just let the implementation worry about it, and go around asking Mitre, Lockheed martin and others to produce a list of useful objects and we provide a list of their Object IDs centrally . We will need to maintain a list of commonly used library objects, similarly to the IANA common port numbers, or the IANA common list of MIM Types. Implementers then just use this list to provide the common library objects within their implementations to all their users.   This puts more onus on the implementers to provide the same names to the users in their UI, mapping the actual Object IDs to real human readable names, and it means the name of the library object may change between various implementations, which could be problematic for users. We can mitigate that last point by proving a ‘suggested name’ as part of the list of Object IDs.   b.       With the suggested ID format  [construct-type]:[UUID] and an alternate ID format of lib:[construct-type]:[anytext] It might be useful to allow a special type of ID to be used for library objects? This could get messy very quickly.   c.        With the ID format [producer_domain_name]:[construct-type]:[UUID] This is untenable for Organizations that wish to remain anonymous. Terrys Recommendation: I believe that option 1 can work if we provide a list of library objects, and we provide their recommended names in a centrally controlled JSON file provided by OASIS or a nominated third-party, in a similar way to what IANA does for TCP/UDP port numbers.   2.       Consumers need to know who to ask for more information --------------------------------------------------------------------------------- Sharing relationship objects enables a consumer to recognize that there is an indirect connection between two objects, and they are related, even if the consumer does not have access to the intermediate object itself. This feature allows government CERT types to share just indicators and relationships, and to keep the threat actor that joins them together a secret (apart from the Object ID). This in turn allows the consumers to know that if they see one indicator on their network, they really need look for the other indirectly related indicators associated with that threat actor.   This feature also works well for bandwidth conservation. Rather than push out a full selection of relationship objects and their matching target objects, implementers will be potentially able to only push out the relationship objects, and the consumers will be able to request more information when they want it or need it. In many cases consumers only want to know that the objects are related – they don’t care why.   To cope with these two scenarios, TWIGS provided the ability for the producers to only send out relationships, and for consumers to ask for more information about those objects if they wanted it. The producer could always say no, but the option was always there.   Having the producer’s domain name within the ID ensured that there is a way for the consumer to know who to ask for more information about the object being discussed. This is most important when a consumer receives only relationship objects (edges), and no data objects (nodes). In this scenario we need a way for the relationship object to always contain the domain name of someone who is ultimately able to provide the object to the consumer if the consumer asks for it (and only if the producer allows them to have it).   I am fine with the producer’s domain name information being separated out from the ID field, but it really needs to be available somewhere else right next to the object ID if we are going to provide consumers a way to ask for more information easily. This will mean we will need to include a producer_domain_name field in the relationship object for the source_ref and for the target_ref objects to ensure that this data is transmitted and is available to the consumers.   The idea for normal (there is a producer_domain_name set) operations, works like this: ·          The producer_domain_name field contains a string representing the domain name of the producer. ·          The consumer would perform a DNS lookup against the DNS Server that is authoratitive for the producers domain name, and requests a TAXII service record. ·          The returned TAXII Service record would in turn point to the location of the TAXII Server for that organization. ·          The consumers TAXII server would then connect directly to the producers TAXII server and request the object ID using TAXII Query. I am assuming that the groups who didn’t want producer domain name contained are the military/government intel types who wanted a way to remain anonymous. This is an important concern if we are actually going to get government -> private industry sharing to take place.  Well as I see it there are two options allowing requests of objects by ID while still allowing the producer to remain anonymous: a.       If the producers wish to remain anonymous and still get sightings sent directly to them: This is a modification of what I proposed in the ‘STIX is difficult’ document I produced for Soltra. It would require the producer_domain_name to ALWAYS be sent along with the ID, so that the producer is known. If a producer wishes to be anonymous, they would need to use a ‘proxy’ organization to ‘hide behind’. The proxy organization would replace the original producer’s domain name with their domain name, and would forward on the translated assertion, so that everyone else in the community would see the information coming from the proxy organization. If anyone replies with a sighting they can reply to the group, or directly to the proxy org. The Proxy org will then reverse the process, translating the proxied object ID back to the original object ID and will then send it on to the anonymous original producer. This has a massive plus in that the consumers always know who to contact to request more information about an object, so that if they have only received a relationship, they can ask for the objects that the relationship refers to by directly requesting it from the producer (as they know the domain name and can do a TAXII lookup). For clarity this would use a direct TAXII query to the producer’s TAXII server to get the Object. This has a massive downside that the producer must always use a proxy organization. Organizations have a hard enough time setting up a single TAXII server at present. b.       If the producers wish to remain anonymous and only see sightings sent to the whole community: In this scenario the producer_domain_name field is OPTIONAL, although when available is sent along with the ID.  If a producer wishes to be anonymous, they would simply need to omit the producer_domain_name field when they publish their assertion. The consumers have no idea who the producer is and are unable to ask them directly for more information. Any relationships asserted to the whole community will be able to be seen by the original producer if they are a community member.   Thinking about it we could still enable the consumers to ask the community/group for the ID, by creating a STIX Request (broadcast to the community) that asks for a particular Object ID. Allowing this feature will ensure that the original anonymous producer is able to view the request (along with everyone else in the community/group), and if they want to, will be able to either send the STIX Response directly to the requester (unicast/decloaks the producer) or broadcast out the STIX Response with the Object to the community (broadcast/producer remains anonymous). In either case the consumer still gets what they want (the information), yet the producer can remain anonymous if they want). Note - Allowing STIX Request/Response to do Object ID requests/replies is partially replicating the function provided by TAXII Query by Object ID, but has an important distinction – it is indirect and broadcast-based. It is analogous to a proxy-arp. It is not something that TAXII Query would be able to do as TAXII Query only works with single client to single server communication. We would need STIX requests/response functionality if we are going to be able to allow consumers to request an Object by ID indirectly using broadcasts out to the whole sharing community/group. If a producer does include a producer_domain_name field then the consumer is able to follow the process described in option 1, and is able to directly request the Object via a TAXII Query by Object ID. Option b will work irrespective of where the data is encapsulated within the object structure. It was mentioned to me that Gary Katz had suggested extracting the producer’s domain_name field into a separate ‘exports’ data structure within the message – independent of the object itself. This could work, but I would discourage it. In my opinion all data about an object should be kept with that object. It’s the concept of tight cohesion, loose coupling. It makes it far easier to ‘move’ the object around as a whole complete thing rather than having bits of the object strewn across the structure. I believe that the producer_domain_name should live right next to the ID.   Terrys Recommendation: I believe that option 2 represents the most flexible option for both anonymous and conspicuous producers.  It allows an indirect, broadcast based request for Object by ID/response containing Object to allow anonymous producers to still communicate, yet allows the standard process of direct unicast TAXII Queries to occur.   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com   -- * Not so wee ** Not so little    

I share your concerns so thanks for the highlights  I wonder what confidence level I would give to anonymous information  I would prefer producer name as mandatory with option for a documented "anonymous" value Regarding the proxy (or broker) idea, I would have to review the TAXII documentation/architecture  On Thursday, 21 January 2016, Terry MacDonald < terry@soltra.com > wrote: Hi John,   The wish of some producers to be anonymous is the reason there can’t be a mandatory producer’s domain name (or URL). It has to be optional. Hence section 2.   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA   An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com     From: John Anderson Sent: Thursday, 21 January 2016 1:02 PM To: Terry MacDonald < terry@soltra.com >; cti-stix@lists.oasis-open.org Subject: Re: Object ID format   Terry, [footnotes in brackets at the bottom] What about actual URLs? (Not URIs [1].) Let's actually use  http: and make our Resources resolvable via the Web. (And maybe even let Google index some of them!)   I love your idea about having meaningful IDs . This screams for Cool URLs  [2]. Like this one:  http://www.discovery.com/tv-shows/mythbusters/videos/juicing-a-tomato-with-explosives/  (I mean, who wouldn't want to see vegetables go kaboom?!)    The same hide-behind-a-proxy idea of yours would still work...with the added benefit that the proxy could be a real proxy server and could actually...um... proxy the Resource. Maybe we could leverage existing technology that has already solved this problem. [3]   Also, you raised an interesting question:  Where to go for more context about an object? With URL-as-ID, then you could simply hack bits and see what else is around there.  (Think: "If I have that previous Cool URL, then what do I get when I hack off the juicing-a-tomato-with-explosives bit?") Why can't we apply hackable URLs in our context as well? [4]   tl;dr - Are there any insurmountable technical obstacles to using URLs for IDs? JSA   [1]  https://www.w3.org/TR/uri-clarification/#contemporary  - URIs, URLs, and URNs: Clarifications and Recommendations 1.0, Section 2.1 "Contemporary View" [2]  https://www.w3.org/Provider/Style/URI.html  - Sir  Tim Berners-Lee's advice on the subject. [3]  http://httpd.apache.org/docs/2.2/mod/mod_proxy.html  - Apache...proxying content worldwide since 1995! [4] This was somewhat of a trick question. The experienced web architect will point out that the context question isn't really solved by hackable URLs. What we really need are Link Relations. Curious? Read  Fielding Chapter 5 . From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of Terry MacDonald < terry@soltra.com > Sent: Wednesday, January 20, 2016 6:47 PM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] Object ID format   Hi list,   I understand that at the F2F there was a proposal to remove namespacing from the STIX ID, so that it would become [construct-type]:[UUID]. This has me a little concerned, as the ID has more of an impact than many people realize. As such, I’ve typed up a wee* little** discussion email to outline my concerns.   1.       It reduces the chances that object libraries will work ------------------------------------------------------------------------- John Wunder and I had been talking about enabling organizations to share easy to remember 'library' IDs. It would be cool if everyone had the ability to actually refer to the single lockheed martin kill chain as the 'lmco.com-kill-chain' for its ID, or an attack-pattern by 'mitre.org-capec-217'.   The problem is that the [construct-type]:[UUID] ID format is that it precludes that usage. People will instead be forced to use a randomly generated UUID, and each implementation will need to remember what that is and translate the horrible UUID to a human readable thing. SNMP OIDs anyone? (yuck)   A different option would be to allow IDs of the type [construct-type]:[anytext], but that then has a huge problem that there will likely be collisions due to the fact many people think similarly, and will reuse object IDs. This could in turn be fixed by introducing a namespace of some type to constrain the collisions to a small domain controlled by one organization… which leads us back to the [producer-domain-name]:[construct-type]:[anytext] mentioned in the TWIGS proposal.   Being pragmatic about it there are a few options we could use to enable the object library idea to work: a.       With the suggested ID format [construct-type]:[UUID] In this option, we just let the implementation worry about it, and go around asking Mitre, Lockheed martin and others to produce a list of useful objects and we provide a list of their Object IDs centrally . We will need to maintain a list of commonly used library objects, similarly to the IANA common port numbers, or the IANA common list of MIM Types. Implementers then just use this list to provide the common library objects within their implementations to all their users.   This puts more onus on the implementers to provide the same names to the users in their UI, mapping the actual Object IDs to real human readable names, and it means the name of the library object may change between various implementations, which could be problematic for users. We can mitigate that last point by proving a ‘suggested name’ as part of the list of Object IDs.   b.       With the suggested ID format  [construct-type]:[UUID] and an alternate ID format of lib:[construct-type]:[anytext] It might be useful to allow a special type of ID to be used for library objects? This could get messy very quickly.   c.        With the ID format [producer_domain_name]:[construct-type]:[UUID] This is untenable for Organizations that wish to remain anonymous. Terrys Recommendation: I believe that option 1 can work if we provide a list of library objects, and we provide their recommended names in a centrally controlled JSON file provided by OASIS or a nominated third-party, in a similar way to what IANA does for TCP/UDP port numbers.   2.       Consumers need to know who to ask for more information --------------------------------------------------------------------------------- Sharing relationship objects enables a consumer to recognize that there is an indirect connection between two objects, and they are related, even if the consumer does not have access to the intermediate object itself. This feature allows government CERT types to share just indicators and relationships, and to keep the threat actor that joins them together a secret (apart from the Object ID). This in turn allows the consumers to know that if they see one indicator on their network, they really need look for the other indirectly related indicators associated with that threat actor.   This feature also works well for bandwidth conservation. Rather than push out a full selection of relationship objects and their matching target objects, implementers will be potentially able to only push out the relationship objects, and the consumers will be able to request more information when they want it or need it. In many cases consumers only want to know that the objects are related – they don’t care why.   To cope with these two scenarios, TWIGS provided the ability for the producers to only send out relationships, and for consumers to ask for more information about those objects if they wanted it. The producer could always say no, but the option was always there.   Having the producer’s domain name within the ID ensured that there is a way for the consumer to know who to ask for more information about the object being discussed. This is most important when a consumer receives only relationship objects (edges), and no data objects (nodes). In this scenario we need a way for the relationship object to always contain the domain name of someone who is ultimately able to provide the object to the consumer if the consumer asks for it (and only if the producer allows them to have it).   I am fine with the producer’s domain name information being separated out from the ID field, but it really needs to be available somewhere else right next to the object ID if we are going to provide consumers a way to ask for more information easily. This will mean we will need to include a producer_domain_name field in the relationship object for the source_ref and for the target_ref objects to ensure that this data is transmitted and is available to the consumers.   The idea for normal (there is a producer_domain_name set) operations, works like this: ·          The producer_domain_name field contains a string representing the domain name of the producer. ·          The consumer would perform a DNS lookup against the DNS Server that is authoratitive for the producers domain name, and requests a TAXII service record. ·          The returned TAXII Service record would in turn point to the location of the TAXII Server for that organization. ·          The consumers TAXII server would then connect directly to the producers TAXII server and request the object ID using TAXII Query. I am assuming that the groups who didn’t want producer domain name contained are the military/government intel types who wanted a way to remain anonymous. This is an important concern if we are actually going to get government -> private industry sharing to take place.  Well as I see it there are two options allowing requests of objects by ID while still allowing the producer to remain anonymous: a.       If the producers wish to remain anonymous and still get sightings sent directly to them: This is a modification of what I proposed in the ‘STIX is difficult’ document I produced for Soltra. It would require the producer_domain_name to ALWAYS be sent along with the ID, so that the producer is known. If a producer wishes to be anonymous, they would need to use a ‘proxy’ organization to ‘hide behind’. The proxy organization would replace the original producer’s domain name with their domain name, and would forward on the translated assertion, so that everyone else in the community would see the information coming from the proxy organization. If anyone replies with a sighting they can reply to the group, or directly to the proxy org. The Proxy org will then reverse the process, translating the proxied object ID back to the original object ID and will then send it on to the anonymous original producer. This has a massive plus in that the consumers always know who to contact to request more information about an object, so that if they have only received a relationship, they can ask for the objects that the relationship refers to by directly requesting it from the producer (as they know the domain name and can do a TAXII lookup). For clarity this would use a direct TAXII query to the producer’s TAXII server to get the Object. This has a massive downside that the producer must always use a proxy organization. Organizations have a hard enough time setting up a single TAXII server at present. b.       If the producers wish to remain anonymous and only see sightings sent to the whole community: In this scenario the producer_domain_name field is OPTIONAL, although when available is sent along with the ID.  If a producer wishes to be anonymous, they would simply need to omit the producer_domain_name field when they publish their assertion. The consumers have no idea who the producer is and are unable to ask them directly for more information. Any relationships asserted to the whole community will be able to be seen by the original producer if they are a community member.   Thinking about it we could still enable the consumers to ask the community/group for the ID, by creating a STIX Request (broadcast to the community) that asks for a particular Object ID. Allowing this feature will ensure that the original anonymous producer is able to view the request (along with everyone else in the community/group), and if they want to, will be able to either send the STIX Response directly to the requester (unicast/decloaks the producer) or broadcast out the STIX Response with the Object to the community (broadcast/producer remains anonymous). In either case the consumer still gets what they want (the information), yet the producer can remain anonymous if they want). Note - Allowing STIX Request/Response to do Object ID requests/replies is partially replicating the function provided by TAXII Query by Object ID, but has an important distinction – it is indirect and broadcast-based. It is analogous to a proxy-arp. It is not something that TAXII Query would be able to do as TAXII Query only works with single client to single server communication. We would need STIX requests/response functionality if we are going to be able to allow consumers to request an Object by ID indirectly using broadcasts out to the whole sharing community/group. If a producer does include a producer_domain_name field then the consumer is able to follow the process described in option 1, and is able to directly request the Object via a TAXII Query by Object ID. Option b will work irrespective of where the data is encapsulated within the object structure. It was mentioned to me that Gary Katz had suggested extracting the producer’s domain_name field into a separate ‘exports’ data structure within the message – independent of the object itself. This could work, but I would discourage it. In my opinion all data about an object should be kept with that object. It’s the concept of tight cohesion, loose coupling. It makes it far easier to ‘move’ the object around as a whole complete thing rather than having bits of the object strewn across the structure. I believe that the producer_domain_name should live right next to the ID.   Terrys Recommendation: I believe that option 2 represents the most flexible option for both anonymous and conspicuous producers.  It allows an indirect, broadcast based request for Object by ID/response containing Object to allow anonymous producers to still communicate, yet allows the standard process of direct unicast TAXII Queries to occur.   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com   -- * Not so wee ** Not so little    

Jerome, Actually, the existing TAXII architecture makes proxying harder. I was looking forward toward a future when TAXII is just a slim varnish over plain-old-HTTP. That said, rewriting domain names in URL-as-ID fields in XML content shouldn't be difficult at all. We just need to stick to absolute URLs. JSA From: Jerome Athias <athiasjerome@gmail.com> Sent: Wednesday, January 20, 2016 10:22 PM To: Terry MacDonald Cc: John Anderson; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Object ID format   I share your concerns so thanks for the highlights  I wonder what confidence level I would give to anonymous information  I would prefer producer name as mandatory with option for a documented "anonymous" value Regarding the proxy (or broker) idea, I would have to review the TAXII documentation/architecture  On Thursday, 21 January 2016, Terry MacDonald < terry@soltra.com > wrote: Hi John,   The wish of some producers to be anonymous is the reason there can’t be a mandatory producer’s domain name (or URL). It has to be optional. Hence section 2.   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA   An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com     From: John Anderson Sent: Thursday, 21 January 2016 1:02 PM To: Terry MacDonald < terry@soltra.com >; cti-stix@lists.oasis-open.org Subject: Re: Object ID format   Terry, [footnotes in brackets at the bottom] What about actual URLs? (Not URIs [1].) Let's actually use  http: and make our Resources resolvable via the Web. (And maybe even let Google index some of them!)   I love your idea about having meaningful IDs . This screams for Cool URLs  [2]. Like this one:  http://www.discovery.com/tv-shows/mythbusters/videos/juicing-a-tomato-with-explosives/  (I mean, who wouldn't want to see vegetables go kaboom?!)    The same hide-behind-a-proxy idea of yours would still work...with the added benefit that the proxy could be a real proxy server and could actually...um... proxy the Resource. Maybe we could leverage existing technology that has already solved this problem. [3]   Also, you raised an interesting question:  Where to go for more context about an object? With URL-as-ID, then you could simply hack bits and see what else is around there.  (Think: "If I have that previous Cool URL, then what do I get when I hack off the juicing-a-tomato-with-explosives bit?") Why can't we apply hackable URLs in our context as well? [4]   tl;dr - Are there any insurmountable technical obstacles to using URLs for IDs? JSA   [1]  https://www.w3.org/TR/uri-clarification/#contemporary  - URIs, URLs, and URNs: Clarifications and Recommendations 1.0, Section 2.1 "Contemporary View" [2]  https://www.w3.org/Provider/Style/URI.html  - Sir  Tim Berners-Lee's advice on the subject. [3]  http://httpd.apache.org/docs/2.2/mod/mod_proxy.html  - Apache...proxying content worldwide since 1995! [4] This was somewhat of a trick question. The experienced web architect will point out that the context question isn't really solved by hackable URLs. What we really need are Link Relations. Curious? Read  Fielding Chapter 5 . From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of Terry MacDonald < terry@soltra.com > Sent: Wednesday, January 20, 2016 6:47 PM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] Object ID format   Hi list,   I understand that at the F2F there was a proposal to remove namespacing from the STIX ID, so that it would become [construct-type]:[UUID]. This has me a little concerned, as the ID has more of an impact than many people realize. As such, I’ve typed up a wee* little** discussion email to outline my concerns.   1.       It reduces the chances that object libraries will work ------------------------------------------------------------------------- John Wunder and I had been talking about enabling organizations to share easy to remember 'library' IDs. It would be cool if everyone had the ability to actually refer to the single lockheed martin kill chain as the 'lmco.com-kill-chain' for its ID, or an attack-pattern by 'mitre.org-capec-217'.   The problem is that the [construct-type]:[UUID] ID format is that it precludes that usage. People will instead be forced to use a randomly generated UUID, and each implementation will need to remember what that is and translate the horrible UUID to a human readable thing. SNMP OIDs anyone? (yuck)   A different option would be to allow IDs of the type [construct-type]:[anytext], but that then has a huge problem that there will likely be collisions due to the fact many people think similarly, and will reuse object IDs. This could in turn be fixed by introducing a namespace of some type to constrain the collisions to a small domain controlled by one organization… which leads us back to the [producer-domain-name]:[construct-type]:[anytext] mentioned in the TWIGS proposal.   Being pragmatic about it there are a few options we could use to enable the object library idea to work: a.       With the suggested ID format [construct-type]:[UUID] In this option, we just let the implementation worry about it, and go around asking Mitre, Lockheed martin and others to produce a list of useful objects and we provide a list of their Object IDs centrally . We will need to maintain a list of commonly used library objects, similarly to the IANA common port numbers, or the IANA common list of MIM Types. Implementers then just use this list to provide the common library objects within their implementations to all their users.   This puts more onus on the implementers to provide the same names to the users in their UI, mapping the actual Object IDs to real human readable names, and it means the name of the library object may change between various implementations, which could be problematic for users. We can mitigate that last point by proving a ‘suggested name’ as part of the list of Object IDs.   b.       With the suggested ID format  [construct-type]:[UUID] and an alternate ID format of lib:[construct-type]:[anytext] It might be useful to allow a special type of ID to be used for library objects? This could get messy very quickly.   c.        With the ID format [producer_domain_name]:[construct-type]:[UUID] This is untenable for Organizations that wish to remain anonymous. Terrys Recommendation: I believe that option 1 can work if we provide a list of library objects, and we provide their recommended names in a centrally controlled JSON file provided by OASIS or a nominated third-party, in a similar way to what IANA does for TCP/UDP port numbers.   2.       Consumers need to know who to ask for more information --------------------------------------------------------------------------------- Sharing relationship objects enables a consumer to recognize that there is an indirect connection between two objects, and they are related, even if the consumer does not have access to the intermediate object itself. This feature allows government CERT types to share just indicators and relationships, and to keep the threat actor that joins them together a secret (apart from the Object ID). This in turn allows the consumers to know that if they see one indicator on their network, they really need look for the other indirectly related indicators associated with that threat actor.   This feature also works well for bandwidth conservation. Rather than push out a full selection of relationship objects and their matching target objects, implementers will be potentially able to only push out the relationship objects, and the consumers will be able to request more information when they want it or need it. In many cases consumers only want to know that the objects are related – they don’t care why.   To cope with these two scenarios, TWIGS provided the ability for the producers to only send out relationships, and for consumers to ask for more information about those objects if they wanted it. The producer could always say no, but the option was always there.   Having the producer’s domain name within the ID ensured that there is a way for the consumer to know who to ask for more information about the object being discussed. This is most important when a consumer receives only relationship objects (edges), and no data objects (nodes). In this scenario we need a way for the relationship object to always contain the domain name of someone who is ultimately able to provide the object to the consumer if the consumer asks for it (and only if the producer allows them to have it).   I am fine with the producer’s domain name information being separated out from the ID field, but it really needs to be available somewhere else right next to the object ID if we are going to provide consumers a way to ask for more information easily. This will mean we will need to include a producer_domain_name field in the relationship object for the source_ref and for the target_ref objects to ensure that this data is transmitted and is available to the consumers.   The idea for normal (there is a producer_domain_name set) operations, works like this: ·          The producer_domain_name field contains a string representing the domain name of the producer. ·          The consumer would perform a DNS lookup against the DNS Server that is authoratitive for the producers domain name, and requests a TAXII service record. ·          The returned TAXII Service record would in turn point to the location of the TAXII Server for that organization. ·          The consumers TAXII server would then connect directly to the producers TAXII server and request the object ID using TAXII Query. I am assuming that the groups who didn’t want producer domain name contained are the military/government intel types who wanted a way to remain anonymous. This is an important concern if we are actually going to get government -> private industry sharing to take place.  Well as I see it there are two options allowing requests of objects by ID while still allowing the producer to remain anonymous: a.       If the producers wish to remain anonymous and still get sightings sent directly to them: This is a modification of what I proposed in the ‘STIX is difficult’ document I produced for Soltra. It would require the producer_domain_name to ALWAYS be sent along with the ID, so that the producer is known. If a producer wishes to be anonymous, they would need to use a ‘proxy’ organization to ‘hide behind’. The proxy organization would replace the original producer’s domain name with their domain name, and would forward on the translated assertion, so that everyone else in the community would see the information coming from the proxy organization. If anyone replies with a sighting they can reply to the group, or directly to the proxy org. The Proxy org will then reverse the process, translating the proxied object ID back to the original object ID and will then send it on to the anonymous original producer. This has a massive plus in that the consumers always know who to contact to request more information about an object, so that if they have only received a relationship, they can ask for the objects that the relationship refers to by directly requesting it from the producer (as they know the domain name and can do a TAXII lookup). For clarity this would use a direct TAXII query to the producer’s TAXII server to get the Object. This has a massive downside that the producer must always use a proxy organization. Organizations have a hard enough time setting up a single TAXII server at present. b.       If the producers wish to remain anonymous and only see sightings sent to the whole community: In this scenario the producer_domain_name field is OPTIONAL, although when available is sent along with the ID.  If a producer wishes to be anonymous, they would simply need to omit the producer_domain_name field when they publish their assertion. The consumers have no idea who the producer is and are unable to ask them directly for more information. Any relationships asserted to the whole community will be able to be seen by the original producer if they are a community member.   Thinking about it we could still enable the consumers to ask the community/group for the ID, by creating a STIX Request (broadcast to the community) that asks for a particular Object ID. Allowing this feature will ensure that the original anonymous producer is able to view the request (along with everyone else in the community/group), and if they want to, will be able to either send the STIX Response directly to the requester (unicast/decloaks the producer) or broadcast out the STIX Response with the Object to the community (broadcast/producer remains anonymous). In either case the consumer still gets what they want (the information), yet the producer can remain anonymous if they want). Note - Allowing STIX Request/Response to do Object ID requests/replies is partially replicating the function provided by TAXII Query by Object ID, but has an important distinction – it is indirect and broadcast-based. It is analogous to a proxy-arp. It is not something that TAXII Query would be able to do as TAXII Query only works with single client to single server communication. We would need STIX requests/response functionality if we are going to be able to allow consumers to request an Object by ID indirectly using broadcasts out to the whole sharing community/group. If a producer does include a producer_domain_name field then the consumer is able to follow the process described in option 1, and is able to directly request the Object via a TAXII Query by Object ID. Option b will work irrespective of where the data is encapsulated within the object structure. It was mentioned to me that Gary Katz had suggested extracting the producer’s domain_name field into a separate ‘exports’ data structure within the message – independent of the object itself. This could work, but I would discourage it. In my opinion all data about an object should be kept with that object. It’s the concept of tight cohesion, loose coupling. It makes it far easier to ‘move’ the object around as a whole complete thing rather than having bits of the object strewn across the structure. I believe that the producer_domain_name should live right next to the ID.   Terrys Recommendation: I believe that option 2 represents the most flexible option for both anonymous and conspicuous producers.  It allows an indirect, broadcast based request for Object by ID/response containing Object to allow anonymous producers to still communicate, yet allows the standard process of direct unicast TAXII Queries to occur.   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com   -- * Not so wee ** Not so little    

Terry, Thanks for the quick reply. I'd like to focus on this statement: " The wish of some producers to be anonymous is the reason there can’t be a mandatory producer’s domain name (or URL). It has to be optional." Respectfully, I don't buy that. It's equivalent saying there's no way to post content on the Web anonymously.  S omeone has to interact with the anonymous poster. (You don't just wake up with a STIX Package on your doorstep.) The trick is to restrict who knows about the original poster. Scenario 1: Use a Trusted Proxy The Secret Squirrel Society (SSS) could publish content that only a Trusted Proxy can get to. The Trusted Proxy simply rewrites the URLs. (This is fairly straight-forward Apache configuration.) Secret URL: https://1.1.1.1/my/anonymous/posting/   (only seen by the trusted proxy; could use an IP address, even!) Proxied URL: https://anonymous.trusted.proxy/my/anonymous/posting/   (seen by everyone else) Scenario 2: Post Anonymously on another Server If a producer cannot publish content to a trusted proxy, then the producer can post anonymously on a Trusted Bulletin Board. Think: pastebin.com for CTI. (Example anonymous post I just made:  http://pastebin.com/KTZpV4Bf . Can you tell from there who posted it?) Aside: Here is an opportunity for implementors: How to allow anonymous postings that can be authoritatively updated/versioned/rescinded by the anonymous author. This is non-trivial, but not too hard. tl;dr - Anonymous Producers don't negate the URL-as-ID idea. (Unless I missed something...in which case, please help me understand.) JSA From: Terry MacDonald Sent: Wednesday, January 20, 2016 9:35 PM To: John Anderson; cti-stix@lists.oasis-open.org Subject: RE: Object ID format   Hi John,   The wish of some producers to be anonymous is the reason there can’t be a mandatory producer’s domain name (or URL). It has to be optional. Hence section 2.   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA   An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com     From: John Anderson Sent: Thursday, 21 January 2016 1:02 PM To: Terry MacDonald <terry@soltra.com>; cti-stix@lists.oasis-open.org Subject: Re: Object ID format   Terry, [footnotes in brackets at the bottom] What about actual URLs? (Not URIs [1].) Let's actually use  http: and make our Resources resolvable via the Web. (And maybe even let Google index some of them!)   I love your idea about having meaningful IDs . This screams for Cool URLs  [2]. Like this one:  http://www.discovery.com/tv-shows/mythbusters/videos/juicing-a-tomato-with-explosives/  (I mean, who wouldn't want to see vegetables go kaboom?!)    The same hide-behind-a-proxy idea of yours would still work...with the added benefit that the proxy could be a real proxy server and could actually...um... proxy the Resource. Maybe we could leverage existing technology that has already solved this problem. [3]   Also, you raised an interesting question:  Where to go for more context about an object? With URL-as-ID, then you could simply hack bits and see what else is around there.  (Think: "If I have that previous Cool URL, then what do I get when I hack off the juicing-a-tomato-with-explosives bit?") Why can't we apply hackable URLs in our context as well? [4]   tl;dr - Are there any insurmountable technical obstacles to using URLs for IDs? JSA   [1]  https://www.w3.org/TR/uri-clarification/#contemporary  - URIs, URLs, and URNs: Clarifications and Recommendations 1.0, Section 2.1 "Contemporary View" [2]  https://www.w3.org/Provider/Style/URI.html  - Sir  Tim Berners-Lee's advice on the subject. [3]  http://httpd.apache.org/docs/2.2/mod/mod_proxy.html  - Apache...proxying content worldwide since 1995! [4] This was somewhat of a trick question. The experienced web architect will point out that the context question isn't really solved by hackable URLs. What we really need are Link Relations. Curious? Read  Fielding Chapter 5 . From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of Terry MacDonald < terry@soltra.com > Sent: Wednesday, January 20, 2016 6:47 PM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] Object ID format   Hi list,   I understand that at the F2F there was a proposal to remove namespacing from the STIX ID, so that it would become [construct-type]:[UUID]. This has me a little concerned, as the ID has more of an impact than many people realize. As such, I’ve typed up a wee* little** discussion email to outline my concerns.   1.       It reduces the chances that object libraries will work ------------------------------------------------------------------------- John Wunder and I had been talking about enabling organizations to share easy to remember 'library' IDs. It would be cool if everyone had the ability to actually refer to the single lockheed martin kill chain as the 'lmco.com-kill-chain' for its ID, or an attack-pattern by 'mitre.org-capec-217'.   The problem is that the [construct-type]:[UUID] ID format is that it precludes that usage. People will instead be forced to use a randomly generated UUID, and each implementation will need to remember what that is and translate the horrible UUID to a human readable thing. SNMP OIDs anyone? (yuck)   A different option would be to allow IDs of the type [construct-type]:[anytext], but that then has a huge problem that there will likely be collisions due to the fact many people think similarly, and will reuse object IDs. This could in turn be fixed by introducing a namespace of some type to constrain the collisions to a small domain controlled by one organization… which leads us back to the [producer-domain-name]:[construct-type]:[anytext] mentioned in the TWIGS proposal.   Being pragmatic about it there are a few options we could use to enable the object library idea to work: a.       With the suggested ID format [construct-type]:[UUID] In this option, we just let the implementation worry about it, and go around asking Mitre, Lockheed martin and others to produce a list of useful objects and we provide a list of their Object IDs centrally . We will need to maintain a list of commonly used library objects, similarly to the IANA common port numbers, or the IANA common list of MIM Types. Implementers then just use this list to provide the common library objects within their implementations to all their users.   This puts more onus on the implementers to provide the same names to the users in their UI, mapping the actual Object IDs to real human readable names, and it means the name of the library object may change between various implementations, which could be problematic for users. We can mitigate that last point by proving a ‘suggested name’ as part of the list of Object IDs.   b.       With the suggested ID format  [construct-type]:[UUID] and an alternate ID format of lib:[construct-type]:[anytext] It might be useful to allow a special type of ID to be used for library objects? This could get messy very quickly.   c.        With the ID format [producer_domain_name]:[construct-type]:[UUID] This is untenable for Organizations that wish to remain anonymous. Terrys Recommendation: I believe that option 1 can work if we provide a list of library objects, and we provide their recommended names in a centrally controlled JSON file provided by OASIS or a nominated third-party, in a similar way to what IANA does for TCP/UDP port numbers.   2.       Consumers need to know who to ask for more information --------------------------------------------------------------------------------- Sharing relationship objects enables a consumer to recognize that there is an indirect connection between two objects, and they are related, even if the consumer does not have access to the intermediate object itself. This feature allows government CERT types to share just indicators and relationships, and to keep the threat actor that joins them together a secret (apart from the Object ID). This in turn allows the consumers to know that if they see one indicator on their network, they really need look for the other indirectly related indicators associated with that threat actor.   This feature also works well for bandwidth conservation. Rather than push out a full selection of relationship objects and their matching target objects, implementers will be potentially able to only push out the relationship objects, and the consumers will be able to request more information when they want it or need it. In many cases consumers only want to know that the objects are related – they don’t care why.   To cope with these two scenarios, TWIGS provided the ability for the producers to only send out relationships, and for consumers to ask for more information about those objects if they wanted it. The producer could always say no, but the option was always there.   Having the producer’s domain name within the ID ensured that there is a way for the consumer to know who to ask for more information about the object being discussed. This is most important when a consumer receives only relationship objects (edges), and no data objects (nodes). In this scenario we need a way for the relationship object to always contain the domain name of someone who is ultimately able to provide the object to the consumer if the consumer asks for it (and only if the producer allows them to have it).   I am fine with the producer’s domain name information being separated out from the ID field, but it really needs to be available somewhere else right next to the object ID if we are going to provide consumers a way to ask for more information easily. This will mean we will need to include a producer_domain_name field in the relationship object for the source_ref and for the target_ref objects to ensure that this data is transmitted and is available to the consumers.   The idea for normal (there is a producer_domain_name set) operations, works like this: ·          The producer_domain_name field contains a string representing the domain name of the producer. ·          The consumer would perform a DNS lookup against the DNS Server that is authoratitive for the producers domain name, and requests a TAXII service record. ·          The returned TAXII Service record would in turn point to the location of the TAXII Server for that organization. ·          The consumers TAXII server would then connect directly to the producers TAXII server and request the object ID using TAXII Query. I am assuming that the groups who didn’t want producer domain name contained are the military/government intel types who wanted a way to remain anonymous. This is an important concern if we are actually going to get government -> private industry sharing to take place.  Well as I see it there are two options allowing requests of objects by ID while still allowing the producer to remain anonymous: a.       If the producers wish to remain anonymous and still get sightings sent directly to them: This is a modification of what I proposed in the ‘STIX is difficult’ document I produced for Soltra. It would require the producer_domain_name to ALWAYS be sent along with the ID, so that the producer is known. If a producer wishes to be anonymous, they would need to use a ‘proxy’ organization to ‘hide behind’. The proxy organization would replace the original producer’s domain name with their domain name, and would forward on the translated assertion, so that everyone else in the community would see the information coming from the proxy organization. If anyone replies with a sighting they can reply to the group, or directly to the proxy org. The Proxy org will then reverse the process, translating the proxied object ID back to the original object ID and will then send it on to the anonymous original producer. This has a massive plus in that the consumers always know who to contact to request more information about an object, so that if they have only received a relationship, they can ask for the objects that the relationship refers to by directly requesting it from the producer (as they know the domain name and can do a TAXII lookup). For clarity this would use a direct TAXII query to the producer’s TAXII server to get the Object. This has a massive downside that the producer must always use a proxy organization. Organizations have a hard enough time setting up a single TAXII server at present. b.       If the producers wish to remain anonymous and only see sightings sent to the whole community: In this scenario the producer_domain_name field is OPTIONAL, although when available is sent along with the ID.  If a producer wishes to be anonymous, they would simply need to omit the producer_domain_name field when they publish their assertion. The consumers have no idea who the producer is and are unable to ask them directly for more information. Any relationships asserted to the whole community will be able to be seen by the original producer if they are a community member.   Thinking about it we could still enable the consumers to ask the community/group for the ID, by creating a STIX Request (broadcast to the community) that asks for a particular Object ID. Allowing this feature will ensure that the original anonymous producer is able to view the request (along with everyone else in the community/group), and if they want to, will be able to either send the STIX Response directly to the requester (unicast/decloaks the producer) or broadcast out the STIX Response with the Object to the community (broadcast/producer remains anonymous). In either case the consumer still gets what they want (the information), yet the producer can remain anonymous if they want). Note - Allowing STIX Request/Response to do Object ID requests/replies is partially replicating the function provided by TAXII Query by Object ID, but has an important distinction – it is indirect and broadcast-based. It is analogous to a proxy-arp. It is not something that TAXII Query would be able to do as TAXII Query only works with single client to single server communication. We would need STIX requests/response functionality if we are going to be able to allow consumers to request an Object by ID indirectly using broadcasts out to the whole sharing community/group. If a producer does include a producer_domain_name field then the consumer is able to follow the process described in option 1, and is able to directly request the Object via a TAXII Query by Object ID. Option b will work irrespective of where the data is encapsulated within the object structure. It was mentioned to me that Gary Katz had suggested extracting the producer’s domain_name field into a separate ‘exports’ data structure within the message – independent of the object itself. This could work, but I would discourage it. In my opinion all data about an object should be kept with that object. It’s the concept of tight cohesion, loose coupling. It makes it far easier to ‘move’ the object around as a whole complete thing rather than having bits of the object strewn across the structure. I believe that the producer_domain_name should live right next to the ID.   Terrys Recommendation: I believe that option 2 represents the most flexible option for both anonymous and conspicuous producers.  It allows an indirect, broadcast based request for Object by ID/response containing Object to allow anonymous producers to still communicate, yet allows the standard process of direct unicast TAXII Queries to occur.   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com   -- * Not so wee ** Not so little    

Domain name in the ID is a bad idea, for all of the reasons we talked about at the F2F.  I think we can solve the anonymous CTI through other means than a TAXII Proxy that we do not have today.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Jan 20, 2016, at 20:35, John Anderson < janderson@soltra.com > wrote: Terry, Thanks for the quick reply. I'd like to focus on this statement:  The wish of some producers to be anonymous is the reason there can’t be a mandatory producer’s domain name (or URL). It has to be optional. Respectfully, I don't buy that. It's equivalent saying there's no way to post content on the Web anonymously.  S omeone   has to interact with the anonymous poster. (You don't just wake up with a STIX Package on your doorstep.) The trick is to   restrict who knows   about the original poster. Scenario 1: Use a Trusted Proxy The Secret Squirrel Society (SSS) could publish content that only a Trusted Proxy can get to. The Trusted Proxy simply rewrites the URLs. (This is fairly straight-forward Apache configuration.) Secret URL:   https://1.1.1.1/my/anonymous/posting/   (only seen by the trusted proxy; could use an IP address, even!) Proxied URL:   https://anonymous.trusted.proxy/my/anonymous/posting/   (seen by everyone else) Scenario 2: Post Anonymously on another Server If a producer cannot publish content to a trusted proxy, then the producer can post anonymously on a Trusted Bulletin Board. Think:  pastebin.com   for CTI. (Example anonymous post I just made:  http://pastebin.com/KTZpV4Bf . Can you tell from there who posted it?) Aside: Here is an opportunity for implementors: How to allow anonymous postings that can be authoritatively updated/versioned/rescinded by the anonymous author. This is non-trivial, but not too hard. tl;dr - Anonymous Producers don't negate the URL-as-ID idea.   (Unless I missed something...in which case, please help me understand.) JSA From:   Terry MacDonald Sent:   Wednesday, January 20, 2016 9:35 PM To:   John Anderson;   cti-stix@lists.oasis-open.org Subject:   RE: Object ID format   Hi John,   The wish of some producers to be anonymous is the reason there can’t be a mandatory producer’s domain name (or URL). It has to be optional. Hence section 2.   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA   An FS-ISAC and DTCC Company +61 (407) 203 206   terry@soltra.com     From:   John Anderson   Sent:   Thursday, 21 January 2016 1:02 PM To:   Terry MacDonald < terry@soltra.com >;   cti-stix@lists.oasis-open.org Subject:   Re: Object ID format   Terry, [footnotes in brackets at the bottom] What about actual URLs?   (Not URIs [1].) Let's actually use  http:   and make our Resources resolvable via the Web. (And maybe even let Google index some of them!)   I love your idea about having   meaningful IDs . This screams for   Cool URLs  [2]. Like this one:  http://www.discovery.com/tv-shows/mythbusters/videos/juicing-a-tomato-with-explosives/  (I mean, who wouldn't want to see vegetables go kaboom?!)    The same   hide-behind-a-proxy   idea of yours would still work...with the added benefit that the proxy could be a real proxy server and could actually...um... proxy   the Resource. Maybe we could leverage existing technology that has   already solved   this problem. [3]   Also, you raised an interesting question:  Where to go for more context   about an object? With URL-as-ID, then you could simply hack bits and see what else is around there.  (Think:  If I have that previous Cool URL, then what do I get when I hack off the   juicing-a-tomato-with-explosives   bit? ) Why can't we apply   hackable URLs   in our context as well? [4]   tl;dr - Are there any insurmountable technical obstacles to using URLs for IDs? JSA   [1]  https://www.w3.org/TR/uri-clarification/#contemporary  -   URIs, URLs, and URNs: Clarifications and Recommendations 1.0, Section 2.1 Contemporary View [2]  https://www.w3.org/Provider/Style/URI.html  -   Sir  Tim Berners-Lee's advice on the subject. [3]  http://httpd.apache.org/docs/2.2/mod/mod_proxy.html  - Apache...proxying content worldwide since 1995! [4] This was somewhat of a trick question. The experienced web architect will point out that the context question isn't really solved by hackable URLs. What we really need are Link Relations. Curious? Read  Fielding Chapter 5 .   <image001.png> From:   cti-stix@lists.oasis-open.org   < cti-stix@lists.oasis-open.org > on behalf of Terry MacDonald < terry@soltra.com > Sent:   Wednesday, January 20, 2016 6:47 PM To:   cti-stix@lists.oasis-open.org Subject:   [cti-stix] Object ID format   Hi list,   I understand that at the F2F there was a proposal to remove namespacing from the STIX ID, so that it would become [construct-type]:[UUID]. This has me a little concerned, as the ID has more of an impact than many people realize. As such, I’ve typed up a wee* little** discussion email to outline my concerns.   1.         It reduces the chances that object libraries will work ------------------------------------------------------------------------- John Wunder and I had been talking about enabling organizations to share easy to remember 'library' IDs. It would be cool if everyone had the ability to actually refer to the single lockheed martin kill chain as the ' lmco.com -kill-chain' for its ID, or an attack-pattern by ' mitre.org -capec-217'.   The problem is that the [construct-type]:[UUID] ID format is that it precludes that usage. People will instead be forced to use a randomly generated UUID, and each implementation will need to remember what that is and translate the horrible UUID to a human readable thing. SNMP OIDs anyone? (yuck)   A different option would be to allow IDs of the type [construct-type]:[anytext], but that then has a huge problem that there will likely be collisions due to the fact many people think similarly, and will reuse object IDs. This could in turn be fixed by introducing a namespace of some type to constrain the collisions to a small domain controlled by one organization… which leads us back to the [producer-domain-name]:[construct-type]:[anytext] mentioned in the TWIGS proposal.   Being pragmatic about it there are a few options we could use to enable the object library idea to work: a.         With the suggested ID format [construct-type]:[UUID] In this option, we just let the implementation worry about it, and go around asking Mitre, Lockheed martin and others to produce a list of useful objects and we provide a list of their Object IDs centrally . We will need to maintain a list of commonly used library objects, similarly to the IANA common port numbers, or the IANA common list of MIM Types. Implementers then just use this list to provide the common library objects within their implementations to all their users.   This puts more onus on the implementers to provide the same names to the users in their UI, mapping the actual Object IDs to real human readable names, and it means the name of the library object may change between various implementations, which could be problematic for users. We can mitigate that last point by proving a ‘suggested name’ as part of the list of Object IDs.   b.         With the suggested ID format  [construct-type]:[UUID] and an alternate ID format of lib:[construct-type]:[anytext] It might be useful to allow a special type of ID to be used for library objects? This could get messy very quickly.   c.          With the ID format [producer_domain_name]:[construct-type]:[UUID] This is untenable for Organizations that wish to remain anonymous. Terrys Recommendation:   I believe that option 1 can work if we provide a list of library objects, and we provide their recommended names in a centrally controlled JSON file provided by OASIS or a nominated third-party, in a similar way to what IANA does for TCP/UDP port numbers.   2.         Consumers need to know who to ask for more information --------------------------------------------------------------------------------- Sharing relationship objects enables a consumer to recognize that there is an indirect connection between two objects, and they are related, even if the consumer does not have access to the intermediate object itself.   This feature allows government CERT types to share just indicators and relationships, and to keep the threat actor that joins them together a secret (apart from the Object ID). This in turn allows the consumers to know that if they see one indicator on their network, they really need look for the other indirectly related indicators associated with that threat actor.   This feature also works well for bandwidth conservation. Rather than push out a full selection of relationship objects and their matching target objects, implementers will be potentially able to only push out the relationship objects, and the consumers will be able to request more information when they want it or need it. In many cases consumers only want to know that the objects are related – they don’t care why.   To cope with these two scenarios, TWIGS provided the ability for the producers to only send out relationships, and for consumers to ask for more information about those objects if they wanted it. The producer could always say no, but the option was always there.   Having the producer’s domain name within the ID ensured that there is a way for the consumer to know who to ask for more information about the object being discussed. This is most important when a consumer receives only relationship objects (edges), and no data objects (nodes). In this scenario we need a way for the relationship object to always contain the domain name of someone who is ultimately able to provide the object to the consumer if the consumer asks for it (and only if the producer allows them to have it).   I am fine with the producer’s domain name information being separated out from the ID field, but it really needs to be available somewhere else   right next to the object ID   if we are going to provide consumers a way to ask for more information easily. This will mean we will need to include a producer_domain_name field in the relationship object for the source_ref and for the target_ref objects to ensure that this data is transmitted and is available to the consumers.   The idea for normal (there is a producer_domain_name set) operations, works like this: ·            The producer_domain_name field contains a string representing the domain name of the producer. ·            The consumer would perform a DNS lookup against the DNS Server that is authoratitive for the producers domain name, and requests a TAXII service record. ·            The returned TAXII Service record would in turn point to the location of the TAXII Server for that organization. ·            The consumers TAXII server would then connect directly to the producers TAXII server and request the object ID using TAXII Query. I am assuming that the groups who didn’t want producer domain name contained are the military/government intel types who wanted a way to remain anonymous. This is an important concern if we are actually going to get government -> private industry sharing to take place.  Well as I see it there are two options allowing requests of objects by ID while still allowing the producer to remain anonymous: a.         If the producers wish to remain anonymous and still get sightings sent directly to them: This is a modification of what I proposed in the ‘STIX is difficult’ document I produced for Soltra. It would require the producer_domain_name to ALWAYS be sent along with the ID, so that the producer is known. If a producer wishes to be anonymous, they would need to use a ‘proxy’ organization to ‘hide behind’. The proxy organization would replace the original producer’s domain name with their domain name, and would forward on the translated assertion, so that everyone else in the community would see the information coming from the proxy organization. If anyone replies with a sighting they can reply to the group, or directly to the proxy org. The Proxy org will then reverse the process, translating the proxied object ID back to the original object ID and will then send it on to the anonymous original producer. This has a massive plus in that the consumers always know who to contact to request more information about an object, so that if they have only received a relationship, they can ask for the objects that the relationship refers to by directly requesting it from the producer (as they know the domain name and can do a TAXII lookup). For clarity this would use a direct TAXII query to the producer’s TAXII server to get the Object. This has a massive downside that the producer must always use a proxy organization. Organizations have a hard enough time setting up a single TAXII server at present. b.         If the producers wish to remain anonymous and only see sightings sent to the whole community: In this scenario the producer_domain_name field is OPTIONAL, although when available is sent along with the ID.  If a producer wishes to be anonymous, they would simply need to omit the producer_domain_name field when they publish their assertion. The consumers have no idea who the producer is and are unable to ask them directly for more information. Any relationships asserted to the whole community will be able to be seen by the original producer if they are a community member.   Thinking about it we could still enable the consumers to ask the community/group for the ID, by creating a STIX Request (broadcast to the community) that asks for a particular Object ID. Allowing this feature will ensure that the original anonymous producer is able to view the request (along with everyone else in the community/group), and if they want to, will be able to either send the STIX Response directly to the requester (unicast/decloaks the producer) or broadcast out the STIX Response with the Object to the community (broadcast/producer remains anonymous). In either case the consumer still gets what they want (the information), yet the producer can remain anonymous if they want). Note - Allowing STIX Request/Response to do Object ID requests/replies is partially replicating the function provided by TAXII Query by Object ID, but has an important distinction – it is indirect and broadcast-based. It is analogous to a proxy-arp. It is not something that TAXII Query would be able to do as TAXII Query only works with single client to single server communication. We would need STIX requests/response functionality if we are going to be able to allow consumers to request an Object by ID   indirectly   using broadcasts out to the whole sharing community/group. If a producer does include a producer_domain_name field then the consumer is able to follow the process described in option 1, and is able to directly request the Object via a TAXII Query by Object ID. Option b will work irrespective of where the data is encapsulated within the object structure. It was mentioned to me that Gary Katz had suggested extracting the producer’s domain_name field into a separate ‘exports’ data structure within the message – independent of the object itself. This could work, but I would discourage it. In my opinion all data about an object should be kept with that object. It’s the concept of tight cohesion, loose coupling. It makes it far easier to ‘move’ the object around as a whole complete thing rather than having bits of the object strewn across the structure. I believe that the producer_domain_name should live right next to the ID.   Terrys Recommendation:   I believe that option 2 represents the most flexible option for both anonymous and conspicuous producers.  It allows an indirect, broadcast based request for Object by ID/response containing Object to allow anonymous producers to still communicate, yet allows the standard process of direct unicast TAXII Queries to occur.   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA An FS-ISAC and DTCC Company +61 (407) 203 206   terry@soltra.com   -- * Not so wee ** Not so little Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

On 21.01.2016 04:58:35, Jordan, Bret wrote: > I think we can solve the anonymous CTI through other means than a > TAXII Proxy that we do not have today. > Fwiw, a unicast/multicast capability [0] is integral to the TAXII Query strawman [1] I submitted to the TAXII SC. [0]: http://taxiiproject.github.io/taxii2/notional-query-api/#query-scoping [1]: http://taxiiproject.github.io/taxii2/notional-query-api/ -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com -- "For all resources, whatever it is, you need more." --RFC 1925 Attachment: signature.asc Description: PGP signature

I don’t recall any hard reasons identified why it “is a bad idea”. I think the discussion revolved around the “anonymous” use case and around whether the value it provided was “worth” having it there. Part of that value is potentially offset by having
Source available. Other parts of that value are not. Terry identifies some of those in his email.
Discussions with others after the f2f have helped me understand a couple of other values that it brings to a point where my perspective/opinion has shifted toward including it. To me the value of having it now outweighs not having it there.


sean









From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of "Jordan, Bret" < bret.jordan@bluecoat.com >
Date: Wednesday, January 20, 2016 at 11:58 PM
To: John Anderson < janderson@soltra.com >
Cc: Terry MacDonald < terry@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Object ID format





Domain name in the ID is a bad idea, for all of the reasons we talked about at the F2F.  I think we can solve the anonymous CTI through other means than a TAXII Proxy that we do not have today.  











Thanks,


Bret











Bret Jordan CISSP

Director of Security Architecture and Standards Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 











On Jan 20, 2016, at 20:35, John Anderson < janderson@soltra.com > wrote:




Terry,

Thanks for the quick reply. I'd like to focus on this statement: " The wish of some producers to be anonymous is the reason there can’t be a mandatory producer’s
domain name (or URL). It has to be optional."




Respectfully, I don't buy that. It's equivalent saying there's no way to post content on the Web anonymously. 




S omeone   has to interact with the anonymous poster.
(You don't just wake up with a STIX Package on your doorstep.) The trick is to   restrict who knows   about the original poster.




Scenario 1: Use a Trusted Proxy




The Secret Squirrel Society (SSS) could publish content that only a Trusted Proxy can get to. The Trusted Proxy simply rewrites the URLs. (This is fairly
straight-forward Apache configuration.)




Secret URL:   https://1.1.1.1/my/anonymous/posting/  
(only seen by the trusted proxy; could use an IP address, even!)

Proxied URL:   https://anonymous.trusted.proxy/my/anonymous/posting/  
(seen by everyone else)







Scenario 2: Post Anonymously on another Server






If a producer cannot publish content to a trusted proxy, then the producer can post anonymously on a Trusted Bulletin Board. Think:  pastebin.com   for
CTI. (Example anonymous post I just made:  http://pastebin.com/KTZpV4Bf . Can you tell from there who posted it?)




Aside: Here is an opportunity for implementors: How to allow anonymous postings that can be authoritatively updated/versioned/rescinded by the anonymous author. This is non-trivial, but not too hard.

tl;dr - Anonymous Producers don't negate the URL-as-ID idea.   (Unless I missed
something...in which case, please help me understand.)
JSA




From:   Terry MacDonald
Sent:   Wednesday, January 20, 2016 9:35 PM
To:   John Anderson;   cti-stix@lists.oasis-open.org
Subject:   RE: Object ID format
 




Hi John,

 

The wish of some producers to be anonymous is the reason there can’t be a mandatory producer’s domain name (or URL). It has to be optional. Hence section 2.

 

Cheers

 


Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA   An FS-ISAC and DTCC Company

+61 (407) 203 206   terry@soltra.com

 


 



From:   John Anderson  
Sent:   Thursday, 21 January 2016 1:02 PM
To:   Terry MacDonald < terry@soltra.com >;   cti-stix@lists.oasis-open.org
Subject:   Re: Object ID format



 


Terry, [footnotes in brackets at the bottom]

What about actual URLs?   (Not URIs [1].) Let's actually use  http:   and
make our Resources resolvable via the Web. (And maybe even let Google index some of them!)

 

I love your idea about having   meaningful IDs . This screams for   Cool
URLs  [2]. Like this one:  http://www.discovery.com/tv-shows/mythbusters/videos/juicing-a-tomato-with-explosives/  (I
mean, who wouldn't want to see vegetables go kaboom?!) 

 

The same   hide-behind-a-proxy   idea of yours would still work...with the added benefit
that the proxy could be a real proxy server and could actually...um... proxy   the Resource. Maybe we could leverage existing technology that has   already
solved   this problem. [3]

 

Also, you raised an interesting question:  Where to go for more context   about an object? With URL-as-ID, then you could simply
hack bits and see what else is around there.  (Think: "If I have that previous Cool URL, then what do I get when I hack off the   juicing-a-tomato-with-explosives   bit?")
Why can't we apply   hackable URLs   in our context as well? [4]

 

tl;dr - Are there any insurmountable technical obstacles to using URLs for IDs?

JSA

 

[1]  https://www.w3.org/TR/uri-clarification/#contemporary  -   URIs,
URLs, and URNs: Clarifications and Recommendations 1.0, Section 2.1 "Contemporary View"

[2]  https://www.w3.org/Provider/Style/URI.html  -   Sir  Tim
Berners-Lee's advice on the subject.

[3]  http://httpd.apache.org/docs/2.2/mod/mod_proxy.html  - Apache...proxying
content worldwide since 1995!

[4] This was somewhat of a trick question. The experienced web architect will point out that the context question isn't really solved by hackable URLs. What we really need are Link Relations. Curious?
Read  Fielding Chapter 5 .   <image001.png>












From:   cti-stix@lists.oasis-open.org   < cti-stix@lists.oasis-open.org >
on behalf of Terry MacDonald < terry@soltra.com >
Sent:   Wednesday, January 20, 2016 6:47 PM
To:   cti-stix@lists.oasis-open.org
Subject:   [cti-stix] Object ID format


 





Hi list,

 

I understand that at the F2F there was a proposal to remove namespacing from the STIX ID, so that it would become [construct-type]:[UUID]. This has me a little concerned, as the ID has
more of an impact than many people realize. As such, I’ve typed up a wee* little** discussion email to outline my concerns.

 

1.         It
reduces the chances that object libraries will work
-------------------------------------------------------------------------

John Wunder and I had been talking about enabling organizations to share easy to remember 'library' IDs. It would be cool if everyone had the ability to actually refer to the single lockheed
martin kill chain as the ' lmco.com -kill-chain' for its ID, or an attack-pattern by ' mitre.org -capec-217'.

 

The problem is that the [construct-type]:[UUID] ID format is that it precludes that usage. People will instead be forced to use a randomly generated UUID, and each implementation will
need to remember what that is and translate the horrible UUID to a human readable thing. SNMP OIDs anyone? (yuck)

 

A different option would be to allow IDs of the type [construct-type]:[anytext], but that then has a huge problem that there will likely be collisions due to the fact many people think
similarly, and will reuse object IDs. This could in turn be fixed by introducing a namespace of some type to constrain the collisions to a small domain controlled by one organization… which leads us back to the [producer-domain-name]:[construct-type]:[anytext]
mentioned in the TWIGS proposal.

 

Being pragmatic about it there are a few options we could use to enable the object library idea to work:

a.         With
the suggested ID format [construct-type]:[UUID]

In this option, we just let the implementation worry about it, and go around asking Mitre, Lockheed martin and others to produce a list of useful objects and we provide a list of their
Object IDs centrally . We will need to maintain a list of commonly used library objects, similarly to the IANA common port numbers, or the IANA common list of MIM Types. Implementers then just use this list to provide the common library objects within their
implementations to all their users.

 

This puts more onus on the implementers to provide the same names to the users in their UI, mapping the actual Object IDs to real human readable names, and it means the name of the library
object may change between various implementations, which could be problematic for users. We can mitigate that last point by proving a ‘suggested name’ as part of the list of Object IDs.

 

b.         With
the suggested ID format  [construct-type]:[UUID] and an alternate ID format of lib:[construct-type]:[anytext]

It might be useful to allow a special type of ID to be used for library objects? This could get messy very quickly.

 

c.          With
the ID format [producer_domain_name]:[construct-type]:[UUID]

This is untenable for Organizations that wish to remain anonymous.

Terrys Recommendation:   I believe that option
1 can work if we provide a list of library objects, and we provide their recommended names in a centrally controlled JSON file provided by OASIS or a nominated third-party, in a similar way to what IANA does for TCP/UDP port numbers.

 

2.         Consumers
need to know who to ask for more information
---------------------------------------------------------------------------------

Sharing relationship objects enables a consumer to recognize that there is an indirect connection between two objects, and they are related, even if the consumer does not
have access to the intermediate object itself.   This feature allows government CERT types to share just indicators and relationships,
and to keep the threat actor that joins them together a secret (apart from the Object ID). This in turn allows the consumers to know that if they see one indicator on their network, they really need look for the other indirectly related indicators associated
with that threat actor.

 

This feature also works well for bandwidth conservation. Rather than push out a full selection of relationship objects and their matching target objects, implementers will be potentially
able to only push out the relationship objects, and the consumers will be able to request more information when they want it or need it. In many cases consumers only want to know that the objects are related – they don’t care why.

 

To cope with these two scenarios, TWIGS provided the ability for the producers to only send out relationships, and for consumers to ask for more information about those objects if they
wanted it. The producer could always say no, but the option was always there.

 

Having the producer’s domain name within the ID ensured that there is a way for the consumer to know who to ask for more information about the object being discussed. This is most important
when a consumer receives only relationship objects (edges), and no data objects (nodes). In this scenario we need a way for the relationship object to always contain the domain name of someone who is ultimately able to provide the object to the consumer if
the consumer asks for it (and only if the producer allows them to have it).

 

I am fine with the producer’s domain name information being separated out from the ID field, but it really needs to be available somewhere else   right
next to the object ID   if we are going to provide consumers a way to ask for more information easily. This will mean we will need to include a producer_domain_name field in the relationship object for the source_ref
and for the target_ref objects to ensure that this data is transmitted and is available to the consumers.

 

The idea for normal (there is a producer_domain_name set) operations, works like this:

·            The producer_domain_name field contains
a string representing the domain name of the producer.

·            The consumer would perform a DNS lookup
against the DNS Server that is authoratitive for the producers domain name, and requests a TAXII service record.

·            The returned TAXII Service record would
in turn point to the location of the TAXII Server for that organization.

·            The consumers TAXII server would then
connect directly to the producers TAXII server and request the object ID using TAXII Query.

I am assuming that the groups who didn’t want producer domain name contained are the military/government intel types who wanted a way to remain anonymous. This is an important concern
if we are actually going to get government -> private industry sharing to take place.  Well as I see it there are two options allowing requests of objects by ID while still allowing the producer to remain anonymous:

a.         If
the producers wish to remain anonymous and still get sightings sent directly to them:

This is a modification of what I proposed in the ‘STIX is difficult’ document I produced for Soltra. It would require the producer_domain_name to ALWAYS be sent along with the ID, so
that the producer is known. If a producer wishes to be anonymous, they would need to use a ‘proxy’ organization to ‘hide behind’. The proxy organization would replace the original producer’s domain name with their domain name, and would forward on the translated
assertion, so that everyone else in the community would see the information coming from the proxy organization. If anyone replies with a sighting they can reply to the group, or directly to the proxy org. The Proxy org will then reverse the process, translating
the proxied object ID back to the original object ID and will then send it on to the anonymous original producer.

This has a massive plus in that the consumers always know who to contact to request more information about an object, so that if they have only received a relationship, they can ask for
the objects that the relationship refers to by directly requesting it from the producer (as they know the domain name and can do a TAXII lookup). For clarity this would use a direct TAXII query to the producer’s TAXII server to get the Object.

This has a massive downside that the producer must always use a proxy organization. Organizations have a hard enough time setting up a single TAXII server at present.

b.         If
the producers wish to remain anonymous and only see sightings sent to the whole community:

In this scenario the producer_domain_name field is OPTIONAL, although when available is sent along with the ID.  If a producer wishes to be anonymous, they would simply need to omit the
producer_domain_name field when they publish their assertion. The consumers have no idea who the producer is and are unable to ask them directly for more information. Any relationships asserted to the whole community will be able to be seen by the original
producer if they are a community member.

 

Thinking about it we could still enable the consumers to ask the community/group for the ID, by creating a STIX Request (broadcast to the community) that asks for a particular Object
ID. Allowing this feature will ensure that the original anonymous producer is able to view the request (along with everyone else in the community/group), and if they want to, will be able to either send the STIX Response directly to the requester (unicast/decloaks
the producer) or broadcast out the STIX Response with the Object to the community (broadcast/producer remains anonymous). In either case the consumer still gets what they want (the information), yet the producer can remain anonymous if they want).

Note - Allowing STIX Request/Response to do Object ID requests/replies is partially replicating the function provided by TAXII Query by Object ID, but has an important distinction – it
is indirect and broadcast-based. It is analogous to a proxy-arp. It is not something that TAXII Query would be able to do as TAXII Query only works with single client to single server communication. We would need STIX requests/response functionality if we
are going to be able to allow consumers to request an Object by ID   indirectly   using broadcasts out to the whole sharing community/group.

If a producer does include a producer_domain_name field then the consumer is able to follow the process described in option 1, and is able to directly request the Object via a TAXII Query
by Object ID.

Option b will work irrespective of where the data is encapsulated within the object structure. It was mentioned to me that Gary Katz had suggested extracting the producer’s domain_name
field into a separate ‘exports’ data structure within the message – independent of the object itself. This could work, but I would discourage it. In my opinion all data about an object should be kept with that object. It’s the concept of tight cohesion, loose
coupling. It makes it far easier to ‘move’ the object around as a whole complete thing rather than having bits of the object strewn across the structure. I believe that the producer_domain_name should live right next to the ID.

 

Terrys Recommendation:   I believe that option
2 represents the most flexible option for both anonymous and conspicuous producers.  It allows an indirect, broadcast based request for Object by ID/response containing Object to allow anonymous producers to still communicate, yet allows the standard process
of direct unicast TAXII Queries to occur.

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA An FS-ISAC and DTCC Company

+61 (407) 203 206   terry@soltra.com

 

--

* Not so wee

** Not so little

And we can not have one group do it one way, and another group do it some other way.  This is why at the face 2 face we talked through this idea and talked about removing the domain name from the ID.  What we found from the discussion is that at the end of the day, the domain name in the ID did not really provide any value.  What is important is that the Information Source object be there..  This will enable people those groups that want open communication to be found.  It will also allow those groups that do not want attribution or want to hide, to hide. The solution we came to at the F2F, as far as I remember, was to just enforce the the InformationSource object.  Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Jan 20, 2016, at 19:35, Terry MacDonald < terry@soltra.com > wrote: Hi John,   The wish of some producers to be anonymous is the reason there can’t be a mandatory producer’s domain name (or URL). It has to be optional. Hence section 2.   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA   An FS-ISAC and DTCC Company +61 (407) 203 206   terry@soltra.com     From:   John Anderson   Sent:   Thursday, 21 January 2016 1:02 PM To:   Terry MacDonald < terry@soltra.com >;   cti-stix@lists.oasis-open.org Subject:   Re: Object ID format   Terry, [footnotes in brackets at the bottom] What about actual URLs?   (Not URIs [1].) Let's actually use  http:   and make our Resources resolvable via the Web. (And maybe even let Google index some of them!)   I love your idea about having   meaningful IDs . This screams for   Cool URLs  [2]. Like this one:  http://www.discovery.com/tv-shows/mythbusters/videos/juicing-a-tomato-with-explosives/  (I mean, who wouldn't want to see vegetables go kaboom?!)    The same   hide-behind-a-proxy   idea of yours would still work...with the added benefit that the proxy could be a real proxy server and could actually...um... proxy   the Resource. Maybe we could leverage existing technology that has   already solved   this problem. [3]   Also, you raised an interesting question:  Where to go for more context   about an object? With URL-as-ID, then you could simply hack bits and see what else is around there.  (Think:  If I have that previous Cool URL, then what do I get when I hack off the   juicing-a-tomato-with-explosives   bit? ) Why can't we apply   hackable URLs   in our context as well? [4]   tl;dr - Are there any insurmountable technical obstacles to using URLs for IDs? JSA   [1]  https://www.w3.org/TR/uri-clarification/#contemporary  -   URIs, URLs, and URNs: Clarifications and Recommendations 1.0, Section 2.1 Contemporary View [2]  https://www.w3.org/Provider/Style/URI.html  -   Sir  Tim Berners-Lee's advice on the subject. [3]  http://httpd.apache.org/docs/2.2/mod/mod_proxy.html  - Apache...proxying content worldwide since 1995! [4] This was somewhat of a trick question. The experienced web architect will point out that the context question isn't really solved by hackable URLs. What we really need are Link Relations. Curious? Read  Fielding Chapter 5 .   <image001.png> From:   cti-stix@lists.oasis-open.org   < cti-stix@lists.oasis-open.org > on behalf of Terry MacDonald < terry@soltra.com > Sent:   Wednesday, January 20, 2016 6:47 PM To:   cti-stix@lists.oasis-open.org Subject:   [cti-stix] Object ID format   Hi list,   I understand that at the F2F there was a proposal to remove namespacing from the STIX ID, so that it would become [construct-type]:[UUID]. This has me a little concerned, as the ID has more of an impact than many people realize. As such, I’ve typed up a wee* little** discussion email to outline my concerns.   1.         It reduces the chances that object libraries will work ------------------------------------------------------------------------- John Wunder and I had been talking about enabling organizations to share easy to remember 'library' IDs. It would be cool if everyone had the ability to actually refer to the single lockheed martin kill chain as the ' lmco.com -kill-chain' for its ID, or an attack-pattern by ' mitre.org -capec-217'.   The problem is that the [construct-type]:[UUID] ID format is that it precludes that usage. People will instead be forced to use a randomly generated UUID, and each implementation will need to remember what that is and translate the horrible UUID to a human readable thing. SNMP OIDs anyone? (yuck)   A different option would be to allow IDs of the type [construct-type]:[anytext], but that then has a huge problem that there will likely be collisions due to the fact many people think similarly, and will reuse object IDs. This could in turn be fixed by introducing a namespace of some type to constrain the collisions to a small domain controlled by one organization… which leads us back to the [producer-domain-name]:[construct-type]:[anytext] mentioned in the TWIGS proposal.   Being pragmatic about it there are a few options we could use to enable the object library idea to work: a.         With the suggested ID format [construct-type]:[UUID] In this option, we just let the implementation worry about it, and go around asking Mitre, Lockheed martin and others to produce a list of useful objects and we provide a list of their Object IDs centrally . We will need to maintain a list of commonly used library objects, similarly to the IANA common port numbers, or the IANA common list of MIM Types. Implementers then just use this list to provide the common library objects within their implementations to all their users.   This puts more onus on the implementers to provide the same names to the users in their UI, mapping the actual Object IDs to real human readable names, and it means the name of the library object may change between various implementations, which could be problematic for users. We can mitigate that last point by proving a ‘suggested name’ as part of the list of Object IDs.   b.         With the suggested ID format  [construct-type]:[UUID] and an alternate ID format of lib:[construct-type]:[anytext] It might be useful to allow a special type of ID to be used for library objects? This could get messy very quickly.   c.          With the ID format [producer_domain_name]:[construct-type]:[UUID] This is untenable for Organizations that wish to remain anonymous. Terrys Recommendation:   I believe that option 1 can work if we provide a list of library objects, and we provide their recommended names in a centrally controlled JSON file provided by OASIS or a nominated third-party, in a similar way to what IANA does for TCP/UDP port numbers.   2.         Consumers need to know who to ask for more information --------------------------------------------------------------------------------- Sharing relationship objects enables a consumer to recognize that there is an indirect connection between two objects, and they are related, even if the consumer does not have access to the intermediate object itself.   This feature allows government CERT types to share just indicators and relationships, and to keep the threat actor that joins them together a secret (apart from the Object ID). This in turn allows the consumers to know that if they see one indicator on their network, they really need look for the other indirectly related indicators associated with that threat actor.   This feature also works well for bandwidth conservation. Rather than push out a full selection of relationship objects and their matching target objects, implementers will be potentially able to only push out the relationship objects, and the consumers will be able to request more information when they want it or need it. In many cases consumers only want to know that the objects are related – they don’t care why.   To cope with these two scenarios, TWIGS provided the ability for the producers to only send out relationships, and for consumers to ask for more information about those objects if they wanted it. The producer could always say no, but the option was always there.   Having the producer’s domain name within the ID ensured that there is a way for the consumer to know who to ask for more information about the object being discussed. This is most important when a consumer receives only relationship objects (edges), and no data objects (nodes). In this scenario we need a way for the relationship object to always contain the domain name of someone who is ultimately able to provide the object to the consumer if the consumer asks for it (and only if the producer allows them to have it).   I am fine with the producer’s domain name information being separated out from the ID field, but it really needs to be available somewhere else   right next to the object ID   if we are going to provide consumers a way to ask for more information easily. This will mean we will need to include a producer_domain_name field in the relationship object for the source_ref and for the target_ref objects to ensure that this data is transmitted and is available to the consumers.   The idea for normal (there is a producer_domain_name set) operations, works like this: ·            The producer_domain_name field contains a string representing the domain name of the producer. ·            The consumer would perform a DNS lookup against the DNS Server that is authoratitive for the producers domain name, and requests a TAXII service record. ·            The returned TAXII Service record would in turn point to the location of the TAXII Server for that organization. ·            The consumers TAXII server would then connect directly to the producers TAXII server and request the object ID using TAXII Query. I am assuming that the groups who didn’t want producer domain name contained are the military/government intel types who wanted a way to remain anonymous. This is an important concern if we are actually going to get government -> private industry sharing to take place.  Well as I see it there are two options allowing requests of objects by ID while still allowing the producer to remain anonymous: a.         If the producers wish to remain anonymous and still get sightings sent directly to them: This is a modification of what I proposed in the ‘STIX is difficult’ document I produced for Soltra. It would require the producer_domain_name to ALWAYS be sent along with the ID, so that the producer is known. If a producer wishes to be anonymous, they would need to use a ‘proxy’ organization to ‘hide behind’. The proxy organization would replace the original producer’s domain name with their domain name, and would forward on the translated assertion, so that everyone else in the community would see the information coming from the proxy organization. If anyone replies with a sighting they can reply to the group, or directly to the proxy org. The Proxy org will then reverse the process, translating the proxied object ID back to the original object ID and will then send it on to the anonymous original producer. This has a massive plus in that the consumers always know who to contact to request more information about an object, so that if they have only received a relationship, they can ask for the objects that the relationship refers to by directly requesting it from the producer (as they know the domain name and can do a TAXII lookup). For clarity this would use a direct TAXII query to the producer’s TAXII server to get the Object. This has a massive downside that the producer must always use a proxy organization. Organizations have a hard enough time setting up a single TAXII server at present. b.         If the producers wish to remain anonymous and only see sightings sent to the whole community: In this scenario the producer_domain_name field is OPTIONAL, although when available is sent along with the ID.  If a producer wishes to be anonymous, they would simply need to omit the producer_domain_name field when they publish their assertion. The consumers have no idea who the producer is and are unable to ask them directly for more information. Any relationships asserted to the whole community will be able to be seen by the original producer if they are a community member.   Thinking about it we could still enable the consumers to ask the community/group for the ID, by creating a STIX Request (broadcast to the community) that asks for a particular Object ID. Allowing this feature will ensure that the original anonymous producer is able to view the request (along with everyone else in the community/group), and if they want to, will be able to either send the STIX Response directly to the requester (unicast/decloaks the producer) or broadcast out the STIX Response with the Object to the community (broadcast/producer remains anonymous). In either case the consumer still gets what they want (the information), yet the producer can remain anonymous if they want). Note - Allowing STIX Request/Response to do Object ID requests/replies is partially replicating the function provided by TAXII Query by Object ID, but has an important distinction – it is indirect and broadcast-based. It is analogous to a proxy-arp. It is not something that TAXII Query would be able to do as TAXII Query only works with single client to single server communication. We would need STIX requests/response functionality if we are going to be able to allow consumers to request an Object by ID   indirectly   using broadcasts out to the whole sharing community/group. If a producer does include a producer_domain_name field then the consumer is able to follow the process described in option 1, and is able to directly request the Object via a TAXII Query by Object ID. Option b will work irrespective of where the data is encapsulated within the object structure. It was mentioned to me that Gary Katz had suggested extracting the producer’s domain_name field into a separate ‘exports’ data structure within the message – independent of the object itself. This could work, but I would discourage it. In my opinion all data about an object should be kept with that object. It’s the concept of tight cohesion, loose coupling. It makes it far easier to ‘move’ the object around as a whole complete thing rather than having bits of the object strewn across the structure. I believe that the producer_domain_name should live right next to the ID.   Terrys Recommendation:   I believe that option 2 represents the most flexible option for both anonymous and conspicuous producers.  It allows an indirect, broadcast based request for Object by ID/response containing Object to allow anonymous producers to still communicate, yet allows the standard process of direct unicast TAXII Queries to occur.   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA An FS-ISAC and DTCC Company +61 (407) 203 206   terry@soltra.com   -- * Not so wee ** Not so little Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

 
Hi!,
 
I definitely support the use of the InformationSource object.  It has the capability of providing great context which is sometimes lacking in STIX documents.
 
Regards,
 
Dean
 


From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Jordan, Bret
Sent: Thursday, 21 January 2016 3:56 PM
To: Terry MacDonald
Cc: John Anderson; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format


 
And we can not have one group do it one way, and another group do it some other way.  This is why at the face 2 face we talked through this idea and talked about removing the domain name from the ID.  What we found from the discussion is
that at the end of the day, the domain name in the ID did not really provide any value.  What is important is that the Information Source object be there..  This will enable people those groups that want open communication to be found.  It will also allow
those groups that do not want attribution or want to hide, to hide.

 


The solution we came to at the F2F, as far as I remember, was to just enforce the the InformationSource object. 







 


Thanks,


 


Bret



 


 


 



Bret Jordan CISSP

Director of Security Architecture and Standards Office of the CTO


Blue Coat Systems



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


"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 









 



On Jan 20, 2016, at 19:35, Terry MacDonald < terry@soltra.com > wrote:

 


Hi John,


 


The wish of some producers to be anonymous is the reason there can’t be a mandatory producer’s domain name (or URL). It has to be optional. Hence section 2.


 


Cheers


 



Terry MacDonald


Senior STIX Subject Matter Expert


SOLTRA   An FS-ISAC and DTCC Company


+61 (407) 203 206   terry@soltra.com


 



 




From:   John
Anderson  
Sent:   Thursday, 21 January 2016 1:02 PM
To:   Terry MacDonald < terry@soltra.com >;   cti-stix@lists.oasis-open.org
Subject:   Re: Object ID format




 



Terry, [footnotes in brackets at the bottom]


What about actual URLs?   (Not
URIs [1].) Let's actually use  http:   and make our Resources resolvable via the Web. (And maybe even let Google index some of them!)


 


I love your idea about having   meaningful IDs . This screams for   Cool
URLs  [2]. Like this one:  http://www.discovery.com/tv-shows/mythbusters/videos/juicing-a-tomato-with-explosives/  (I
mean, who wouldn't want to see vegetables go kaboom?!) 


 


The same   hide-behind-a-proxy   idea of yours would still work...with
the added benefit that the proxy could be a real proxy server and could actually...um... proxy   the Resource. Maybe we could leverage existing technology that has   already
solved   this problem. [3]


 


Also, you raised an interesting question:  Where to go for more context   about an object? With URL-as-ID, then you
could simply hack bits and see what else is around there.  (Think: "If I have that previous Cool URL, then what do I get when I hack off the   juicing-a-tomato-with-explosives   bit?")
Why can't we apply   hackable URLs   in our context as well? [4]


 


tl;dr - Are there any insurmountable technical obstacles to using URLs for IDs?


JSA


 


[1]  https://www.w3.org/TR/uri-clarification/#contemporary  -   URIs,
URLs, and URNs: Clarifications and Recommendations 1.0, Section 2.1 "Contemporary View"


[2]  https://www.w3.org/Provider/Style/URI.html  -   Sir  Tim
Berners-Lee's advice on the subject.


[3]  http://httpd.apache.org/docs/2.2/mod/mod_proxy.html  -
Apache...proxying content worldwide since 1995!


[4] This was somewhat of a trick question. The experienced web architect will point out that the context question isn't really solved by hackable URLs. What we really
need are Link Relations. Curious? Read  Fielding Chapter 5 .   <image001.png>














From:   cti-stix@lists.oasis-open.org   < cti-stix@lists.oasis-open.org >
on behalf of Terry MacDonald < terry@soltra.com >
Sent:   Wednesday, January 20, 2016 6:47 PM
To:   cti-stix@lists.oasis-open.org
Subject:   [cti-stix] Object ID format



 






Hi list,


 


I understand that at the F2F there was a proposal to remove namespacing from the STIX ID, so that it would become [construct-type]:[UUID]. This has
me a little concerned, as the ID has more of an impact than many people realize. As such, I’ve typed up a wee* little** discussion email to outline my concerns.


 


1.         It
reduces the chances that object libraries will work
-------------------------------------------------------------------------


John Wunder and I had been talking about enabling organizations to share easy to remember 'library' IDs. It would be cool if everyone had the ability
to actually refer to the single lockheed martin kill chain as the ' lmco.com -kill-chain' for its ID, or an attack-pattern by ' mitre.org -capec-217'.


 


The problem is that the [construct-type]:[UUID] ID format is that it precludes that usage. People will instead be forced to use a randomly generated
UUID, and each implementation will need to remember what that is and translate the horrible UUID to a human readable thing. SNMP OIDs anyone? (yuck)


 


A different option would be to allow IDs of the type [construct-type]:[anytext], but that then has a huge problem that there will likely be collisions
due to the fact many people think similarly, and will reuse object IDs. This could in turn be fixed by introducing a namespace of some type to constrain the collisions to a small domain controlled by one organization… which leads us back to the [producer-domain-name]:[construct-type]:[anytext]
mentioned in the TWIGS proposal.


 


Being pragmatic about it there are a few options we could use to enable the object library idea to work:


a.         With
the suggested ID format [construct-type]:[UUID]


In this option, we just let the implementation worry about it, and go around asking Mitre, Lockheed martin and others to produce a list of useful
objects and we provide a list of their Object IDs centrally . We will need to maintain a list of commonly used library objects, similarly to the IANA common port numbers, or the IANA common list of MIM Types. Implementers then just use this list to provide
the common library objects within their implementations to all their users.


 


This puts more onus on the implementers to provide the same names to the users in their UI, mapping the actual Object IDs to real human readable
names, and it means the name of the library object may change between various implementations, which could be problematic for users. We can mitigate that last point by proving a ‘suggested name’ as part of the list of Object IDs.


 


b.         With
the suggested ID format  [construct-type]:[UUID] and an alternate ID format of lib:[construct-type]:[anytext]


It might be useful to allow a special type of ID to be used for library objects? This could get messy very quickly.


 


c.          With
the ID format [producer_domain_name]:[construct-type]:[UUID]


This is untenable for Organizations that wish to remain anonymous.


Terrys Recommendation:   I
believe that option 1 can work if we provide a list of library objects, and we provide their recommended names in a centrally controlled JSON file provided by OASIS or a nominated third-party, in a similar way to what IANA does for TCP/UDP port numbers.


 


2.         Consumers
need to know who to ask for more information
---------------------------------------------------------------------------------


Sharing relationship objects enables a consumer to recognize that there is an indirect connection between two objects, and they are related, even
if the consumer does not have access to the intermediate object itself.   This
feature allows government CERT types to share just indicators and relationships, and to keep the threat actor that joins them together a secret (apart from the Object ID). This in turn allows the consumers to know that if they see one indicator on their network,
they really need look for the other indirectly related indicators associated with that threat actor.


 


This feature also works well for bandwidth conservation. Rather than push out a full selection of relationship objects and their matching target
objects, implementers will be potentially able to only push out the relationship objects, and the consumers will be able to request more information when they want it or need it. In many cases consumers only want to know that the objects are related – they
don’t care why.


 


To cope with these two scenarios, TWIGS provided the ability for the producers to only send out relationships, and for consumers to ask for more
information about those objects if they wanted it. The producer could always say no, but the option was always there.


 


Having the producer’s domain name within the ID ensured that there is a way for the consumer to know who to ask for more information about the object
being discussed. This is most important when a consumer receives only relationship objects (edges), and no data objects (nodes). In this scenario we need a way for the relationship object to always contain the domain name of someone who is ultimately able
to provide the object to the consumer if the consumer asks for it (and only if the producer allows them to have it).


 


I am fine with the producer’s domain name information being separated out from the ID field, but it really needs to be available somewhere else   right
next to the object ID   if we are going to provide consumers a way to ask for more information easily. This will mean we will need to include a producer_domain_name field in the relationship object for the source_ref
and for the target_ref objects to ensure that this data is transmitted and is available to the consumers.


 


The idea for normal (there is a producer_domain_name set) operations, works like this:


·            The
producer_domain_name field contains a string representing the domain name of the producer.


·            The
consumer would perform a DNS lookup against the DNS Server that is authoratitive for the producers domain name, and requests a TAXII service record.


·            The
returned TAXII Service record would in turn point to the location of the TAXII Server for that organization.


·            The
consumers TAXII server would then connect directly to the producers TAXII server and request the object ID using TAXII Query.


I am assuming that the groups who didn’t want producer domain name contained are the military/government intel types who wanted a way to remain anonymous.
This is an important concern if we are actually going to get government -> private industry sharing to take place.  Well as I see it there are two options allowing requests of objects by ID while still allowing the producer to remain anonymous:


a.         If
the producers wish to remain anonymous and still get sightings sent directly to them:


This is a modification of what I proposed in the ‘STIX is difficult’ document I produced for Soltra. It would require the producer_domain_name to
ALWAYS be sent along with the ID, so that the producer is known. If a producer wishes to be anonymous, they would need to use a ‘proxy’ organization to ‘hide behind’. The proxy organization would replace the original producer’s domain name with their domain
name, and would forward on the translated assertion, so that everyone else in the community would see the information coming from the proxy organization. If anyone replies with a sighting they can reply to the group, or directly to the proxy org. The Proxy
org will then reverse the process, translating the proxied object ID back to the original object ID and will then send it on to the anonymous original producer.


This has a massive plus in that the consumers always know who to contact to request more information about an object, so that if they have only received
a relationship, they can ask for the objects that the relationship refers to by directly requesting it from the producer (as they know the domain name and can do a TAXII lookup). For clarity this would use a direct TAXII query to the producer’s TAXII server
to get the Object.


This has a massive downside that the producer must always use a proxy organization. Organizations have a hard enough time setting up a single TAXII
server at present.


b.         If
the producers wish to remain anonymous and only see sightings sent to the whole community:


In this scenario the producer_domain_name field is OPTIONAL, although when available is sent along with the ID.  If a producer wishes to be anonymous,
they would simply need to omit the producer_domain_name field when they publish their assertion. The consumers have no idea who the producer is and are unable to ask them directly for more information. Any relationships asserted to the whole community will
be able to be seen by the original producer if they are a community member.


 


Thinking about it we could still enable the consumers to ask the community/group for the ID, by creating a STIX Request (broadcast to the community)
that asks for a particular Object ID. Allowing this feature will ensure that the original anonymous producer is able to view the request (along with everyone else in the community/group), and if they want to, will be able to either send the STIX Response directly
to the requester (unicast/decloaks the producer) or broadcast out the STIX Response with the Object to the community (broadcast/producer remains anonymous). In either case the consumer still gets what they want (the information), yet the producer can remain
anonymous if they want).


Note - Allowing STIX Request/Response to do Object ID requests/replies is partially replicating the function provided by TAXII Query by Object ID,
but has an important distinction – it is indirect and broadcast-based. It is analogous to a proxy-arp. It is not something that TAXII Query would be able to do as TAXII Query only works with single client to single server communication. We would need STIX
requests/response functionality if we are going to be able to allow consumers to request an Object by ID   indirectly   using broadcasts out to the whole sharing community/group.


If a producer does include a producer_domain_name field then the consumer is able to follow the process described in option 1, and is able to directly
request the Object via a TAXII Query by Object ID.


Option b will work irrespective of where the data is encapsulated within the object structure. It was mentioned to me that Gary Katz had suggested
extracting the producer’s domain_name field into a separate ‘exports’ data structure within the message – independent of the object itself. This could work, but I would discourage it. In my opinion all data about an object should be kept with that object.
It’s the concept of tight cohesion, loose coupling. It makes it far easier to ‘move’ the object around as a whole complete thing rather than having bits of the object strewn across the structure. I believe that the producer_domain_name should live right next
to the ID.


 


Terrys Recommendation:   I
believe that option 2 represents the most flexible option for both anonymous and conspicuous producers.  It allows an indirect, broadcast based request for Object by ID/response containing Object to allow anonymous producers to still communicate, yet allows
the standard process of direct unicast TAXII Queries to occur.


 


Cheers


 


Terry MacDonald


Senior STIX Subject Matter Expert


SOLTRA An FS-ISAC and DTCC Company


+61 (407) 203 206   terry@soltra.com


 


--


* Not so wee


** Not so little








 


This e-mail and any attachments to it (the Communication ) is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together ANZ ). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication.

Agree as well - that was the concensus at the F2F - ID should be for ID purposes, information source for producer purposes. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Thompson, Dean" ---01/21/2016 01:06:58 AM---Hi!, I definitely support the use of the InformationSource object. It has the capability of providi From: "Thompson, Dean" <Dean.Thompson@anz.com> To: "'Jordan, Bret'" <bret.jordan@bluecoat.com>, "'Terry MacDonald'" <terry@soltra.com> Cc: "'John Anderson'" <janderson@soltra.com>, "'cti-stix@lists.oasis-open.org'" <cti-stix@lists.oasis-open.org> Date: 01/21/2016 01:06 AM Subject: RE: [cti-stix] Object ID format Sent by: <cti-stix@lists.oasis-open.org> Hi!, I definitely support the use of the InformationSource object. It has the capability of providing great context which is sometimes lacking in STIX documents. Regards, Dean From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Jordan, Bret Sent: Thursday, 21 January 2016 3:56 PM To: Terry MacDonald Cc: John Anderson; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Object ID format And we can not have one group do it one way, and another group do it some other way. This is why at the face 2 face we talked through this idea and talked about removing the domain name from the ID. What we found from the discussion is that at the end of the day, the domain name in the ID did not really provide any value. What is important is that the Information Source object be there.. This will enable people those groups that want open communication to be found. It will also allow those groups that do not want attribution or want to hide, to hide. The solution we came to at the F2F, as far as I remember, was to just enforce the the InformationSource object. Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." On Jan 20, 2016, at 19:35, Terry MacDonald < terry@soltra.com > wrote: Hi John, The wish of some producers to be anonymous is the reason there can’t be a mandatory producer’s domain name (or URL). It has to be optional. Hence section 2. Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication.

The one caveat I would add here is that we need to make sure we can provide an information source for things we want to relate but don’t own. I think this is the scenario Terry is worried about.


Example:


Terry publishes Indicator ABC and relates it to Malware XYZ
Jason publishes Malware 123
I realize that Indicator ABC is actually also detecting Malware 123, a variant of XYZ. I want to share this, but I also don’t want to have to re-share Malware 123 or Indicator ABC. So I just share a relationship object:


ID: relationship:UUID-1
From: indicator:ABC [produced by Terry, but you don’t know this from the ID]
To: malware:123 [produced by Jason, but you don’t know this from the ID]
Information Source: Me
Value: Indicated Malware


It would be nice if we had some way of indicating that you can go get more information on indicator:ABC from Terry and on malware:123 from Jason. Terry’s suggestion was to add an optional information source to the from and to values:



ID: relationship:UUID-1
From: indicator:ABC [produced by Terry, but you don’t know this from the ID]
From_Source: Terry
To: malware:123 [produced by Jason, but you don’t know this from the ID]
To_Source: Jason
Information Source: Me
Value: Indicated Malware



That would let you look up the other ends, and that data would follow the relationship object into your repository. That makes it very easy to look it up down the road if an analyst clicks a “more info” button.


OTOH, one thing Gary Katz suggested at the F2F was an “exports” definition on messages that would do the same thing:


Message: Announcement
Relationships:

ID: relationship:UUID-1
From: indicator:ABC [produced by Terry, but you don’t know this from the ID]
To: malware:123 [produced by Jason, but you don’t know this from the ID]
Information Source: Me
Value: Indicated Malware

Exports:
indicator:ABC => Terry
malware:123 => Jason
relationship:UUID-1 => John W.


That approach keeps the extra fields out of the relationship, but the downside is that they don’t follow the relationship into your database so you’d have to track them separately. OTOH, we could map them not just to an information source but to an actual
TAXII server, while still keeping the actual STIX/CybOX content agnostic of TAXII. It’s a toss-up to me…last night when we talked Terry had me convinced that the first approach (with the producer IDs in the relationship) was better while after writing it out
today maybe I’m thinking the opposite. I’m curious what you all think of these two approaches.


There are also reasons that Gary outlined for why proxy anonymization doesn’t solve the problem, specifically related to de-duplication. I think I can explain that if anyone is curious but I don’t want to crowd the thread.


John





From: < cti-stix@lists.oasis-open.org > on behalf of Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Date: Thursday, January 21, 2016 at 7:25 AM
To: "Thompson, Dean" < Dean.Thompson@anz.com >
Cc: "'Jordan, Bret'" < bret.jordan@bluecoat.com >, 'Terry MacDonald' < terry@soltra.com >, 'John Anderson' < janderson@soltra.com >,
" 'cti-stix@lists.oasis-open.org '" < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Object ID format





Agree as well - that was the concensus at the F2F - ID should be for ID purposes, information source for producer purposes.



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

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


"Thompson,
Dean" ---01/21/2016 01:06:58 AM---Hi!, I definitely support the use of the InformationSource object. It has the capability of providi

From: "Thompson, Dean" < Dean.Thompson@anz.com >
To: "'Jordan, Bret'" < bret.jordan@bluecoat.com >, "'Terry MacDonald'" < terry@soltra.com >
Cc: "'John Anderson'" < janderson@soltra.com >, " 'cti-stix@lists.oasis-open.org '" < cti-stix@lists.oasis-open.org >
Date: 01/21/2016 01:06 AM
Subject: RE: [cti-stix] Object ID format
Sent by: < cti-stix@lists.oasis-open.org >






Hi!,

I definitely support the use of the InformationSource object. It has the capability of providing great context which is sometimes lacking in STIX documents.

Regards,

Dean

From:
cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Jordan, Bret
Sent: Thursday, 21 January 2016 3:56 PM
To: Terry MacDonald
Cc: John Anderson;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format

And we can not have one group do it one way, and another group do it some other way. This is why at the face 2 face we talked through this idea and talked about removing the domain name from the ID. What we found from the
discussion is that at the end of the day, the domain name in the ID did not really provide any value. What is important is that the Information Source object be there.. This will enable people those groups that want open communication to be found. It will
also allow those groups that do not want attribution or want to hide, to hide.

The solution we came to at the F2F, as far as I remember, was to just enforce the the InformationSource object.


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."




On Jan 20, 2016, at 19:35, Terry MacDonald < terry@soltra.com > wrote:

Hi John,

The wish of some producers to be anonymous is the reason there can’t be a mandatory producer’s domain name (or URL). It has to be optional. Hence section 2.

Cheers

Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA An FS-ISAC and DTCC Company
+61 (407) 203 206 terry@soltra.com







This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify
the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated
to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication,
computer virus, data corruption, interference or delay arising from or in respect of the Communication.

I like the "Exports" approach better than the relationship tag approach, but am not strong on it and could go either way. The reason I like exports is because I only have to export the mapping once; if we have to do it in relationship then in a very big STIX report we could be saying the same thing over and over and over. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Wunder, John A." ---01/21/2016 09:48:45 AM---The one caveat I would add here is that we need to make sure we can provide an information source fo From: "Wunder, John A." <jwunder@mitre.org> To: "'cti-stix@lists.oasis-open.org'" <cti-stix@lists.oasis-open.org> Date: 01/21/2016 09:48 AM Subject: Re: [cti-stix] Object ID format Sent by: <cti-stix@lists.oasis-open.org> The one caveat I would add here is that we need to make sure we can provide an information source for things we want to relate but don’t own. I think this is the scenario Terry is worried about. Example: Terry publishes Indicator ABC and relates it to Malware XYZ Jason publishes Malware 123 I realize that Indicator ABC is actually also detecting Malware 123, a variant of XYZ. I want to share this, but I also don’t want to have to re-share Malware 123 or Indicator ABC. So I just share a relationship object: ID: relationship:UUID-1 From: indicator:ABC [produced by Terry, but you don’t know this from the ID] To: malware:123 [produced by Jason, but you don’t know this from the ID] Information Source: Me Value: Indicated Malware It would be nice if we had some way of indicating that you can go get more information on indicator:ABC from Terry and on malware:123 from Jason. Terry’s suggestion was to add an optional information source to the from and to values: ID: relationship:UUID-1 From: indicator:ABC [produced by Terry, but you don’t know this from the ID] From_Source: Terry To: malware:123 [produced by Jason, but you don’t know this from the ID] To_Source: Jason Information Source: Me Value: Indicated Malware That would let you look up the other ends, and that data would follow the relationship object into your repository. That makes it very easy to look it up down the road if an analyst clicks a “more info” button. OTOH, one thing Gary Katz suggested at the F2F was an “exports” definition on messages that would do the same thing: Message: Announcement Relationships: ID: relationship:UUID-1 From: indicator:ABC [produced by Terry, but you don’t know this from the ID] To: malware:123 [produced by Jason, but you don’t know this from the ID] Information Source: Me Value: Indicated Malware Exports: indicator:ABC => Terry malware:123 => Jason relationship:UUID-1 => John W. That approach keeps the extra fields out of the relationship, but the downside is that they don’t follow the relationship into your database so you’d have to track them separately. OTOH, we could map them not just to an information source but to an actual TAXII server, while still keeping the actual STIX/CybOX content agnostic of TAXII. It’s a toss-up to me…last night when we talked Terry had me convinced that the first approach (with the producer IDs in the relationship) was better while after writing it out today maybe I’m thinking the opposite. I’m curious what you all think of these two approaches. There are also reasons that Gary outlined for why proxy anonymization doesn’t solve the problem, specifically related to de-duplication. I think I can explain that if anyone is curious but I don’t want to crowd the thread. John
[attachment "graycol.gif" deleted by Jason Keirstead/CanEast/IBM]

Adding  source into the sub-fields of a relationship or managing an “exports’ index both seem like much more complicated solutions to a problem that can be addressed by keeping the ID Authority domain name in the IDs. And having the domain name there provides
added benefit beyond just the “source” use case.


Gary mentioned the deduplication issue but I believe the discussion around it made it clear that it is not a property of proxy anonymization but of the data itself. The approach of pulling domain name out of Ids does nothing to solve the issue. If anything
it makes the issue broader across all content rather than just anonymized content.


sean









From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Thursday, January 21, 2016 at 8:48 AM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Object ID format






The one caveat I would add here is that we need to make sure we can provide an information source for things we want to relate but don’t own. I think this is the scenario Terry is worried about.


Example:


Terry publishes Indicator ABC and relates it to Malware XYZ
Jason publishes Malware 123
I realize that Indicator ABC is actually also detecting Malware 123, a variant of XYZ. I want to share this, but I also don’t want to have to re-share Malware 123 or Indicator ABC. So I just share a relationship object:


ID: relationship:UUID-1
From: indicator:ABC [produced by Terry, but you don’t know this from the ID]
To: malware:123 [produced by Jason, but you don’t know this from the ID]
Information Source: Me
Value: Indicated Malware


It would be nice if we had some way of indicating that you can go get more information on indicator:ABC from Terry and on malware:123 from Jason. Terry’s suggestion was to add an optional information source to the from and to values:



ID: relationship:UUID-1
From: indicator:ABC [produced by Terry, but you don’t know this from the ID]
From_Source: Terry
To: malware:123 [produced by Jason, but you don’t know this from the ID]
To_Source: Jason
Information Source: Me
Value: Indicated Malware



That would let you look up the other ends, and that data would follow the relationship object into your repository. That makes it very easy to look it up down the road if an analyst clicks a “more info” button.


OTOH, one thing Gary Katz suggested at the F2F was an “exports” definition on messages that would do the same thing:


Message: Announcement
Relationships:

ID: relationship:UUID-1
From: indicator:ABC [produced by Terry, but you don’t know this from the ID]
To: malware:123 [produced by Jason, but you don’t know this from the ID]
Information Source: Me
Value: Indicated Malware

Exports:
indicator:ABC => Terry
malware:123 => Jason
relationship:UUID-1 => John W.


That approach keeps the extra fields out of the relationship, but the downside is that they don’t follow the relationship into your database so you’d have to track them separately. OTOH, we could map them not just to an information source but to an actual
TAXII server, while still keeping the actual STIX/CybOX content agnostic of TAXII. It’s a toss-up to me…last night when we talked Terry had me convinced that the first approach (with the producer IDs in the relationship) was better while after writing it out
today maybe I’m thinking the opposite. I’m curious what you all think of these two approaches.


There are also reasons that Gary outlined for why proxy anonymization doesn’t solve the problem, specifically related to de-duplication. I think I can explain that if anyone is curious but I don’t want to crowd the thread.


John





From: < cti-stix@lists.oasis-open.org > on behalf of Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Date: Thursday, January 21, 2016 at 7:25 AM
To: "Thompson, Dean" < Dean.Thompson@anz.com >
Cc: "'Jordan, Bret'" < bret.jordan@bluecoat.com >, 'Terry MacDonald' < terry@soltra.com >, 'John Anderson' < janderson@soltra.com >,
" 'cti-stix@lists.oasis-open.org '" < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Object ID format





Agree as well - that was the concensus at the F2F - ID should be for ID purposes, information source for producer purposes.



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

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


"Thompson,
Dean" ---01/21/2016 01:06:58 AM---Hi!, I definitely support the use of the InformationSource object. It has the capability of providi

From: "Thompson, Dean" < Dean.Thompson@anz.com >
To: "'Jordan, Bret'" < bret.jordan@bluecoat.com >, "'Terry MacDonald'" < terry@soltra.com >
Cc: "'John Anderson'" < janderson@soltra.com >, " 'cti-stix@lists.oasis-open.org '" < cti-stix@lists.oasis-open.org >
Date: 01/21/2016 01:06 AM
Subject: RE: [cti-stix] Object ID format
Sent by: < cti-stix@lists.oasis-open.org >






Hi!,

I definitely support the use of the InformationSource object. It has the capability of providing great context which is sometimes lacking in STIX documents.

Regards,

Dean

From:
cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Jordan, Bret
Sent: Thursday, 21 January 2016 3:56 PM
To: Terry MacDonald
Cc: John Anderson;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format

And we can not have one group do it one way, and another group do it some other way. This is why at the face 2 face we talked through this idea and talked about removing the domain name from the ID. What we found from the
discussion is that at the end of the day, the domain name in the ID did not really provide any value. What is important is that the Information Source object be there.. This will enable people those groups that want open communication to be found. It will
also allow those groups that do not want attribution or want to hide, to hide.

The solution we came to at the F2F, as far as I remember, was to just enforce the the InformationSource object.


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."




On Jan 20, 2016, at 19:35, Terry MacDonald < terry@soltra.com > wrote:

Hi John,

The wish of some producers to be anonymous is the reason there can’t be a mandatory producer’s domain name (or URL). It has to be optional. Hence section 2.

Cheers

Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA An FS-ISAC and DTCC Company
+61 (407) 203 206 terry@soltra.com







This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify
the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated
to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication,
computer virus, data corruption, interference or delay arising from or in respect of the Communication.

On 21.01.2016 02:01:35, John Anderson wrote: > > What about actual URLs? (Not URIs [1].) Let's actually use http: and > make our Resources resolvable via the Web. (And maybe even let > Google index some of them!) > Hey, John - Threat intel is less than worthless if your adversary knows what you know. Wholesale webification of CTI is no panacea. -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com -- "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." --RFC 1925 Attachment: signature.asc Description: PGP signature

Trey, I agree with this thought: "Threat intel is less than worthless if your adversary knows what you know." I'm not suggesting we put all our Resources in the clear with no Authorization/Authentication. That would indeed be stupid. However, end-to-end encryption and Auth/Auth is a solved problem for web apps. Even Federated Identity, if we want to use it. (SAML 2.0, OpenID, etc.) We can absolutely share objects via the web without the Bad Guys finding out. So, about "Wholesale webification of CTI is no panacea."...yes and no. Sure, the Web is no panacea. BUT...It would be unbelievably freeing to have a URL for every Object. Then, if you want to know more, just browse to it! (Assuming the publisher's server is accessible to you.) JSA

John, After talking with some folks after the f2f I think I am now on this same page with you. At least I have good company. :-) sean On 1/21/16, 9:51 AM, "cti-stix@lists.oasis-open.org on behalf of John Anderson" <cti-stix@lists.oasis-open.org on behalf of janderson@soltra.com> wrote: >Trey, > >I agree with this thought: "Threat intel is less than worthless if your adversary knows what you know." I'm not suggesting we put all our Resources in the clear with no Authorization/Authentication. That would indeed be stupid. > >However, end-to-end encryption and Auth/Auth is a solved problem for web apps. Even Federated Identity, if we want to use it. (SAML 2.0, OpenID, etc.) We can absolutely share objects via the web without the Bad Guys finding out. > >So, about "Wholesale webification of CTI is no panacea."...yes and no. Sure, the Web is no panacea. BUT...It would be unbelievably freeing to have a URL for every Object. Then, if you want to know more, just browse to it! (Assuming the publisher's server is accessible to you.) > >JSA >--------------------------------------------------------------------- >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 >

On 21.01.2016 15:51:01, John Anderson wrote: > > I agree with this thought: "Threat intel is less than worthless if > your adversary knows what you know." I'm not suggesting we put all > our Resources in the clear with no Authorization/Authentication. > That would indeed be stupid. > Hey, John - Apologies, obviously I misread you. Your line about "And maybe even let Google index some of them!" threw me off. > > So, about "Wholesale webification of CTI is no panacea."...yes and > no. Sure, the Web is no panacea. BUT...It would be unbelievably > freeing to have a URL for every Object. Then, if you want to know > more, just browse to it! (Assuming the publisher's server is > accessible to you.) > I'm totally fine with URLs as object IDs, provided they use UUIDs and the object<->URL mapping is immutable. Cf. the write-up I did on precisely this point as part of the TAXII Query prototype, along with the knock-on implications for object versioning [1]. I'm *not* sold on the idea that we can do away with TAXII entirely by being exceedingly clever with HTTP headers and Apache configs. Perhaps I'm again misinterpreting your position (and if so, please correct me, John!) [0]: https://taxiiproject.github.io/taxii2/notional-query-api/#immutability-of-objects-under-a-url-based-object-id-scheme [1]: https://taxiiproject.github.io/taxii2/notional-query-api/#implications-for-object-versioning -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com -- "In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away." --RFC 1925 Attachment: signature.asc Description: PGP signature

Trey, Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly "shifting the ground under our feet" by changing Resources. URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object. So, I'd like to think immutability and versioning are orthogonal to Identity. What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's proposal demonstrates.) JSA

Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cloud?  For all of the banks on this list, do you plan on sticking STIX documents on your web server?  And making it so that the public can just surf to them? I firmly believe that the vast majority, in the 99+% of STIX objects will NEVER be open to general web surfing..   So we are building a solution to a problem that does not exist.  Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Jan 22, 2016, at 07:43, John Anderson < janderson@soltra.com > wrote: Trey, Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly shifting the ground under our feet by changing Resources. URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object. So, I'd like to think immutability and versioning are orthogonal to Identity. What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's proposal demonstrates.) JSA --------------------------------------------------------------------- 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 Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

And to go back further.... I still am of the opinion that we can't codify this without TAXII. So we have a URL in an ID.. now what? If anyone wants to make use of that, then they have to know what is expected if I issue a GET to that URL. Should it return a STIX document? A web page? A word document that is a threat report? We have to codify this in the standard, otherwise there is no point to even having the field because everyone will put different things there. So now, we are codifying data sharing behavior over the network and STIX URL syntaxes, inside STIX, and not TAXII. This proposal makes no sense to me as part of the ID because it is going down this path of tying STIX and TAXII together at the hip. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Jordan, Bret" ---01/22/2016 12:03:33 PM---Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cl From: "Jordan, Bret" <bret.jordan@bluecoat.com> To: John Anderson <janderson@soltra.com> Cc: Trey Darley <trey@soltra.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 01/22/2016 12:03 PM Subject: Re: [cti-stix] Object ID format Sent by: <cti-stix@lists.oasis-open.org> Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cloud? For all of the banks on this list, do you plan on sticking STIX documents on your web server? And making it so that the public can just surf to them? I firmly believe that the vast majority, in the 99+% of STIX objects will NEVER be open to general web surfing.. So we are building a solution to a problem that does not exist. Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." On Jan 22, 2016, at 07:43, John Anderson < janderson@soltra.com > wrote: Trey, Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly "shifting the ground under our feet" by changing Resources. URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object. So, I'd like to think immutability and versioning are orthogonal to Identity. What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's proposal demonstrates.) JSA --------------------------------------------------------------------- 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 [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]

I have another “back further” question – given the rate at which popular websites change permalinks, who realistically thinks that organizations are going to do a good job at creating persistent unique identifiers and versioning them over time?  That’s a massive knowledge management problem that would rely on consolidated technology platforms that don’t yet exist.   STIX co-chairs, what’s the plan for gaining consensus on the object id?   Alex   From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jason Keirstead Sent: Friday, January 22, 2016 11:21 AM To: Jordan, Bret Cc: John Anderson; Trey Darley; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Object ID format   And to go back further.... I still am of the opinion that we can't codify this without TAXII. So we have a URL in an ID.. now what? If anyone wants to make use of that, then they have to know what is expected if I issue a GET to that URL. Should it return a STIX document? A web page? A word document that is a threat report? We have to codify this in the standard, otherwise there is no point to even having the field because everyone will put different things there. So now, we are codifying data sharing behavior over the network and STIX URL syntaxes, inside STIX, and not TAXII. This proposal makes no sense to me as part of the ID because it is going down this path of tying STIX and TAXII together at the hip. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Jordan, Bret" ---01/22/2016 12:03:33 PM---Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cl From: "Jordan, Bret" < bret.jordan@bluecoat.com > To: John Anderson < janderson@soltra.com > Cc: Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Date: 01/22/2016 12:03 PM Subject: Re: [cti-stix] Object ID format Sent by: < cti-stix@lists.oasis-open.org > Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cloud? For all of the banks on this list, do you plan on sticking STIX documents on your web server? And making it so that the public can just surf to them? I firmly believe that the vast majority, in the 99+% of STIX objects will NEVER be open to general web surfing.. So we are building a solution to a problem that does not exist. Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." On Jan 22, 2016, at 07:43, John Anderson < janderson@soltra.com > wrote: Trey, Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly "shifting the ground under our feet" by changing Resources. URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object. So, I'd like to think immutability and versioning are orthogonal to Identity. What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's proposal demonstrates.) JSA --------------------------------------------------------------------- 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 [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM] This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.

+1


URLs tend to be fairly fragile in practice and I would rather have one, single, more complicated method that we can rely on rather than people trying to create URL schemes that are persistent, having some object IDs resolvable and some not, and tying ourselves
to access via a single URI (or maybe in some cases a URL) rather than a list of possible options.


John








From: < cti-stix@lists.oasis-open.org > on behalf of "Foley, Alexander - GIS" < alexander.foley@bankofamerica.com >
Date: Friday, January 22, 2016 at 11:26 AM
To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Jordan, Bret" < bret.jordan@bluecoat.com >
Cc: John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Object ID format








I have another “back further” question – given the rate at which popular websites change permalinks, who realistically thinks that organizations are
going to do a good job at creating persistent unique identifiers and versioning them over time?  That’s a massive knowledge management problem that would rely on consolidated technology platforms that don’t yet exist.
 
STIX co-chairs, what’s the plan for gaining consensus on the object id?


 
Alex


 


From:
cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Jason Keirstead
Sent: Friday, January 22, 2016 11:21 AM
To: Jordan, Bret
Cc: John Anderson; Trey Darley;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format


 
And to go back further.... I still am of the opinion that we can't codify this without TAXII.

So we have a URL in an ID.. now what? If anyone wants to make use of that, then they have to know what is expected if I issue a GET to that URL. Should it return a STIX document? A web page? A word document that is a threat report?

We have to codify this in the standard, otherwise there is no point to even having the field because everyone will put different things there. So now, we are codifying data sharing behavior over the network and STIX URL syntaxes, inside STIX, and not TAXII.


This proposal makes no sense to me as part of the ID because it is going down this path of tying STIX and TAXII together at the hip.

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

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


"Jordan,
Bret" ---01/22/2016 12:03:33 PM---Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cl

From: "Jordan, Bret" < bret.jordan@bluecoat.com >
To: John Anderson < janderson@soltra.com >
Cc: Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Date: 01/22/2016 12:03 PM
Subject: Re: [cti-stix] Object ID format
Sent by: < cti-stix@lists.oasis-open.org >






Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cloud? For all of the banks on this list, do you plan on sticking STIX documents on your web server? And making it so that the public
can just surf to them?

I firmly believe that the vast majority, in the 99+% of STIX objects will NEVER be open to general web surfing.. So we are building a solution to a problem that does not exist.



Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Jan 22, 2016, at 07:43, John Anderson < janderson@soltra.com >
wrote:

Trey,
Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly "shifting the ground under our feet" by changing Resources.

URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object.

So, I'd like to think immutability and versioning are orthogonal to Identity.

What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's
proposal demonstrates.)

JSA
---------------------------------------------------------------------
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
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]





This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at
http://www.bankofamerica.com/emaildisclaimer . If you are not the intended recipient, please delete this message.

Is there anyone that this proposed structure doesn’t work for (even if you don’t agree with the field names)? I think this alleviates Jason’s concern of tying STIX to a specific transport, and the “what do you expect?” is answered by the reference key
(e.g., “taxii2”), assuming there is some degree of definition behind the key (and individual enclaves can use their own special sauce!).


{ "type" : "indicator" , "id" : "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" , "references" : { "taxii2" : " https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 " , "amqp?" : "amqp://user:pass@host:10000/vhost#SomeOtherStuff" , “ sneakernet" : "Ask Mark (555) 555-5555" }, "producer" : "MarkDavidson" // Omit field for anonymity } Thank you. -Mark





From: < cti-stix@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Friday, January 22, 2016 at 11:54 AM
To: "Foley, Alexander - GIS" < alexander.foley@bankofamerica.com >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Jordan,
Bret" < bret.jordan@bluecoat.com >
Cc: John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Object ID format






+1


URLs tend to be fairly fragile in practice and I would rather have one, single, more complicated method that we can rely on rather than people trying to create URL schemes that are persistent, having some object IDs resolvable and some not, and tying ourselves
to access via a single URI (or maybe in some cases a URL) rather than a list of possible options.


John








From: < cti-stix@lists.oasis-open.org > on behalf of "Foley, Alexander - GIS" < alexander.foley@bankofamerica.com >
Date: Friday, January 22, 2016 at 11:26 AM
To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Jordan, Bret" < bret.jordan@bluecoat.com >
Cc: John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Object ID format








I have another “back further” question – given the rate at which popular websites change permalinks, who realistically thinks that organizations are
going to do a good job at creating persistent unique identifiers and versioning them over time?  That’s a massive knowledge management problem that would rely on consolidated technology platforms that don’t yet exist.
 
STIX co-chairs, what’s the plan for gaining consensus on the object id?


 
Alex


 


From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Jason Keirstead
Sent: Friday, January 22, 2016 11:21 AM
To: Jordan, Bret
Cc: John Anderson; Trey Darley;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format


 
And to go back further.... I still am of the opinion that we can't codify this without TAXII.

So we have a URL in an ID.. now what? If anyone wants to make use of that, then they have to know what is expected if I issue a GET to that URL. Should it return a STIX document? A web page? A word document that is a threat report?

We have to codify this in the standard, otherwise there is no point to even having the field because everyone will put different things there. So now, we are codifying data sharing behavior over the network and STIX URL syntaxes, inside STIX, and not TAXII.


This proposal makes no sense to me as part of the ID because it is going down this path of tying STIX and TAXII together at the hip.

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

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


"Jordan,
Bret" ---01/22/2016 12:03:33 PM---Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cl

From: "Jordan, Bret" < bret.jordan@bluecoat.com >
To: John Anderson < janderson@soltra.com >
Cc: Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Date: 01/22/2016 12:03 PM
Subject: Re: [cti-stix] Object ID format
Sent by: < cti-stix@lists.oasis-open.org >






Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cloud? For all of the banks on this list, do you plan on sticking STIX documents on your web server? And making it so that the public
can just surf to them?

I firmly believe that the vast majority, in the 99+% of STIX objects will NEVER be open to general web surfing.. So we are building a solution to a problem that does not exist.



Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Jan 22, 2016, at 07:43, John Anderson < janderson@soltra.com >
wrote:

Trey,
Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly "shifting the ground under our feet" by changing Resources.

URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object.

So, I'd like to think immutability and versioning are orthogonal to Identity.

What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's
proposal demonstrates.)

JSA
---------------------------------------------------------------------
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
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]





This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at
http://www.bankofamerica.com/emaildisclaimer . If you are not the intended recipient, please delete this message.

Assuming "producer" points at InformationSource object - looks great. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Mark Davidson ---01/22/2016 02:02:48 PM---Is there anyone that this proposed structure doesn’t work for (even if you don’t agree with the fiel From: Mark Davidson <mdavidson@soltra.com> To: "Wunder, John A." <jwunder@mitre.org>, "Foley, Alexander - GIS" <alexander.foley@bankofamerica.com>, Jason Keirstead/CanEast/IBM@IBMCA, "Jordan, Bret" <bret.jordan@bluecoat.com> Cc: John Anderson <janderson@soltra.com>, Trey Darley <trey@soltra.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 01/22/2016 02:02 PM Subject: Re: [cti-stix] Object ID format Sent by: <cti-stix@lists.oasis-open.org> Is there anyone that this proposed structure doesn’t work for (even if you don’t agree with the field names)? I think this alleviates Jason’s concern of tying STIX to a specific transport, and the “what do you expect?” is answered by the reference key (e.g., “taxii2”), assuming there is some degree of definition behind the key (and individual enclaves can use their own special sauce!). {   "type" : "indicator" ,   "id" : "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" ,   "references" : { "taxii2" : " https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 " ,                 "amqp?" : "amqp://user:pass@host:10000/vhost#SomeOtherStuff" ,                 “sneakernet" : "Ask Mark (555) 555-5555" },   "producer" : "MarkDavidson" // Omit field for anonymity } Thank you. -Mark From: < cti-stix@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org > Date: Friday, January 22, 2016 at 11:54 AM To: "Foley, Alexander - GIS" < alexander.foley@bankofamerica.com >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Object ID format +1 URLs tend to be fairly fragile in practice and I would rather have one, single, more complicated method that we can rely on rather than people trying to create URL schemes that are persistent, having some object IDs resolvable and some not, and tying ourselves to access via a single URI (or maybe in some cases a URL) rather than a list of possible options. John From: < cti-stix@lists.oasis-open.org > on behalf of "Foley, Alexander - GIS" < alexander.foley@bankofamerica.com > Date: Friday, January 22, 2016 at 11:26 AM To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Jordan, Bret" < bret.jordan@bluecoat.com > Cc: John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: RE: [cti-stix] Object ID format I have another “back further” question – given the rate at which popular websites change permalinks, who realistically thinks that organizations are going to do a good job at creating persistent unique identifiers and versioning them over time? That’s a massive knowledge management problem that would rely on consolidated technology platforms that don’t yet exist. STIX co-chairs, what’s the plan for gaining consensus on the object id? Alex From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Jason Keirstead Sent: Friday, January 22, 2016 11:21 AM To: Jordan, Bret Cc: John Anderson; Trey Darley; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Object ID format And to go back further.... I still am of the opinion that we can't codify this without TAXII. So we have a URL in an ID.. now what? If anyone wants to make use of that, then they have to know what is expected if I issue a GET to that URL. Should it return a STIX document? A web page? A word document that is a threat report? We have to codify this in the standard, otherwise there is no point to even having the field because everyone will put different things there. So now, we are codifying data sharing behavior over the network and STIX URL syntaxes, inside STIX, and not TAXII. This proposal makes no sense to me as part of the ID because it is going down this path of tying STIX and TAXII together at the hip. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Jordan, Bret" ---01/22/2016 12:03:33 PM---Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cl From: "Jordan, Bret" < bret.jordan@bluecoat.com > To: John Anderson < janderson@soltra.com > Cc: Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Date: 01/22/2016 12:03 PM Subject: Re: [cti-stix] Object ID format Sent by: < cti-stix@lists.oasis-open.org > Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cloud? For all of the banks on this list, do you plan on sticking STIX documents on your web server? And making it so that the public can just surf to them? I firmly believe that the vast majority, in the 99+% of STIX objects will NEVER be open to general web surfing.. So we are building a solution to a problem that does not exist. Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." On Jan 22, 2016, at 07:43, John Anderson < janderson@soltra.com > wrote: Trey, Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly "shifting the ground under our feet" by changing Resources. URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object. So, I'd like to think immutability and versioning are orthogonal to Identity. What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's proposal demonstrates.) JSA --------------------------------------------------------------------- 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 [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM] This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer . If you are not the intended recipient, please delete this message. --------------------------------------------------------------------- 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   [attachment "image001.gif" deleted by Jason Keirstead/CanEast/IBM]

Hi Mark,
 
Me unfortunately (just slightly). The problem that I have with direct references to where to get the data, is that it goes stale. As
mentioned in my other email, companies are bought by other companies, domain names change, web servers and taxi servers move. So for those reasons, I think we need a way to allow the location of an organizations data repositories to change too.
 
Using the structure you proposed, if an organization did change its domain name, they would need to reissue revisions to all their
objects to update the location of their data store. Or, they would need to ensure that there was a reverse proxy in front of their web services to ‘map’ the old location to the new location on the fly.  Both of these options have their problems. The first
results in a large number of updates that need to be rebroadcast out to the various communities that the organization belongs to; the second results in additional infrastructure that the Organization needs to keep up to date.

 
I think your idea is excellent Mark, and with a little tweak could be even better….
 
Idea:
What if the data location wasn’t actually attached to the Indicator object itself, but instead was bound to the Identity of the producer of the STIX object?

 
An illustrative example….
 
If you have an Indicator object you want to share (and you want people to know where to get it), you would insert a stix_producer_ref
field pointing to the Identity object of who made and published the STIX object:
 
{   "type" : "indicator" ,   "id" : "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" ,   "stix_producer_ref" : " Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d", // Omit field for anonymity
 ….. }
 
Then you have the Identity Object for the stix object creator – and that Identity contains a list of ways for consumers to get more
information about STIX objects that this identity has produced:
 
}
 
"type" :
"identity" ,
  "id" : " Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d",
  "title" :
"Mark Davidson",

  "stix_resources" : {
                
"taxii2" :
"https://example.com/taxii2 " ,
                 "amqp?" :
"amqp://user:pass@host:10000/vhost" ,
                 “sneakernet" :
"Ask Mark (555) 555-5555"
  
},

}
 
There are some really great benefits to having this kind of structure.
 
1.       
If the Organization domain name changes, then the Organization just produces a new revision of its Identity object (one object)and
sends it out to the communities it belongs to. Everyone who receives it know knows how to get the latest updates of objects – even objects created 3 years ago!
2.       
If the Organization’s domain name changes, there are no changes needed to any of the other Objects previously released by
the Organization (apart from the Identity one).
3.       
If the Organization decided to move from HTTPS based TAXII to AMQP or binary or carrier-pigeon based networking then all
that needs to be done is a new revision of the Identity object with a modified stix_resources section!
 
Simple!
 
Cheers
 

Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA   An FS-ISAC and DTCC Company
+61 (407) 203 206
terry@soltra.com
 

 


From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Mark Davidson
Sent: Saturday, 23 January 2016 5:02 AM
To: Wunder, John A. <jwunder@mitre.org>; Foley, Alexander - GIS <alexander.foley@bankofamerica.com>; Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Jordan, Bret <bret.jordan@bluecoat.com>
Cc: John Anderson <janderson@soltra.com>; Trey Darley <trey@soltra.com>; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format


 


Is there anyone that this proposed structure doesn’t work for (even if you don’t agree with the field names)? I think this alleviates Jason’s concern of tying STIX
to a specific transport, and the “what do you expect?” is answered by the reference key (e.g., “taxii2”), assuming there is some degree of definition behind the key (and individual enclaves can use their own special sauce!).



{   "type" : "indicator" ,   "id" : "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" ,   "references" : { "taxii2" : " https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 " ,                  "amqp?" : "amqp://user:pass@host:10000/vhost#SomeOtherStuff" ,                  “sneakernet" : "Ask Mark (555) 555-5555" },   "producer" : "MarkDavidson" // Omit field for anonymity }

Thank you.


-Mark





From:
< cti-stix@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Friday, January 22, 2016 at 11:54 AM
To: "Foley, Alexander - GIS" < alexander.foley@bankofamerica.com >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Jordan, Bret" < bret.jordan@bluecoat.com >
Cc: John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Object ID format


 





+1


 


URLs tend to be fairly fragile in practice and I would rather have one, single, more complicated method that we can rely on rather than people trying to create
URL schemes that are persistent, having some object IDs resolvable and some not, and tying ourselves to access via a single URI (or maybe in some cases a URL) rather than a list of possible options.


 


John



 


From:
< cti-stix@lists.oasis-open.org > on behalf of "Foley, Alexander - GIS" < alexander.foley@bankofamerica.com >
Date: Friday, January 22, 2016 at 11:26 AM
To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Jordan, Bret" < bret.jordan@bluecoat.com >
Cc: John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Object ID format


 



I have another “back further” question – given the rate at which popular websites change permalinks, who realistically thinks that organizations
are going to do a good job at creating persistent unique identifiers and versioning them over time?  That’s a massive knowledge management problem that would rely on consolidated technology platforms that don’t yet exist.
 
STIX co-chairs, what’s the plan for gaining consensus on the object id?


 
Alex


 


From: cti-stix@lists.oasis-open.org
[ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Jason Keirstead
Sent: Friday, January 22, 2016 11:21 AM
To: Jordan, Bret
Cc: John Anderson; Trey Darley;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format


 
And to go back further.... I still am of the opinion that we can't codify this without TAXII.

So we have a URL in an ID.. now what? If anyone wants to make use of that, then they have to know what is expected if I issue a GET to that URL. Should it return a STIX document? A web page? A word document that is a threat report?

We have to codify this in the standard, otherwise there is no point to even having the field because everyone will put different things there. So now, we are codifying data sharing behavior over the network and STIX URL syntaxes, inside STIX, and not TAXII.


This proposal makes no sense to me as part of the ID because it is going down this path of tying STIX and TAXII together at the hip.

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

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


"Jordan,
Bret" ---01/22/2016 12:03:33 PM---Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cl

From: "Jordan, Bret" < bret.jordan@bluecoat.com >
To: John Anderson < janderson@soltra.com >
Cc: Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Date: 01/22/2016 12:03 PM
Subject:
Re: [cti-stix] Object ID format
Sent by:
< cti-stix@lists.oasis-open.org >








Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cloud? For all of the banks on this list, do you plan on sticking STIX documents on your web server?
And making it so that the public can just surf to them?

I firmly believe that the vast majority, in the 99+% of STIX objects will NEVER be open to general web surfing.. So we are building a solution to a problem that does not exist.



Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Jan 22, 2016, at 07:43, John Anderson < janderson@soltra.com >
wrote:

Trey,
Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly "shifting the ground under our feet" by changing Resources.

URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object.

So, I'd like to think immutability and versioning are orthogonal to Identity.

What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's
proposal demonstrates.)

JSA
---------------------------------------------------------------------
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
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]







This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary
and subject to important terms and conditions available at
http://www.bankofamerica.com/emaildisclaimer . If you are not the intended recipient, please delete this message.

(Copying the TAXII list because the topic has bled over)




I think we are mostly in agreement. A few of your statements touch on a larger topic for me – I think the way we think about architectures could be updated such that some of these traditional sticking points (versioning, revocation) can be minimized. It’s a
topic orthogonal to this thread; suffice to say I do not know of another technology that moves information like we tend to envision it: highly sensitive information packages that contain policy information being redistributed arbitrarily (as long as those
movements conform to policy). Newsgroups do not fit because there is not policy information; email/web don't not fit because they are not redistributed arbitrarily (within the protocol, anyway).



As for tying producer information to the lookup information, I am not sold on two points. I don't believe the producer MUST host objects they create (though they MAY), and I am not sold that hosted objects MUST have producer
information (though they MAY). An organization may host anonymous information on behalf of good-samaritan submitters, for instance. In that case, the producer isn’t hosting the object and the hosted objects would not contain producer information. A key thing
for me is decoupling producer identification from hosting information, as I don’t think there is a compelling reason to tie them together, and I think tying them together has some notable drawbacks.




An idea I really like from your email is the idea that producer information could list TAXII capabilities or other stix-relevant network capabilities. IMO this is good as one option for resolving content (connect to server->search for object). Adding to this
idea, if the hosting organization advertised their TAXII in DNS, they would only need identify a domain name (e.g., example.com instead of
https://example.com/taxii2 /). I think that would possibly be a neat capability.




Updating the example, I could see:




{ "type" : "indicator" , "id" : "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" , "references" : { "taxii2" : "https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" , "amqp?" : "amqp://user:pass@host:10000/vhost#SomeOtherStuff" , "sneakernet" : "Ask Mark (555) 555-5555" }, "producer_ref" : "Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d" // Omit field for anonymity }

{ "type" : "identity" , "id" : " Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d" , "title" : "Mark Davidson" , "stix_resolvers" : { "taxii2" : "example.com" , // Use DNS to identify TAXII Server & perform lookups ? "amqp?" : "amqp://user:pass@host:10000/vhost" , "sneakernet" : "Ask Mark (555) 555-5555" } } My idea is that the reference listed directly on the object is the “best path” for resolving the content. The TAXII capabilities listed on the producer are the “second path” for resolving content. I will note the inconsistency between the references values and the STIX resolvers values, which I don’t like, but I’m not sure how to solve . Thank you.


-Mark









From: Terry MacDonald < terry@soltra.com >
Date: Saturday, January 23, 2016 at 1:08 AM
To: Mark Davidson < mdavidson@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Object ID format








Hi Mark,
 
Me unfortunately (just slightly). The problem that I have with direct references to where to get the data, is that it goes stale. As
mentioned in my other email, companies are bought by other companies, domain names change, web servers and taxi servers move. So for those reasons, I think we need a way to allow the location of an organizations data repositories to change too.
 
Using the structure you proposed, if an organization did change its domain name, they would need to reissue revisions to all their
objects to update the location of their data store. Or, they would need to ensure that there was a reverse proxy in front of their web services to ‘map’ the old location to the new location on the fly.  Both of these options have their problems. The first
results in a large number of updates that need to be rebroadcast out to the various communities that the organization belongs to; the second results in additional infrastructure that the Organization needs to keep up to date.

 
I think your idea is excellent Mark, and with a little tweak could be even better….
 
Idea:
What if the data location wasn’t actually attached to the Indicator object itself, but instead was bound to the Identity of the producer of the STIX object?

 
An illustrative example….
 
If you have an Indicator object you want to share (and you want people to know where to get it), you would insert a stix_producer_ref
field pointing to the Identity object of who made and published the STIX object:
 
{   "type" : "indicator" ,   "id" : "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" ,   "stix_producer_ref" : " Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d", // Omit field for anonymity
 ….. }
 
Then you have the Identity Object for the stix object creator – and that Identity contains a list of ways for consumers to get more
information about STIX objects that this identity has produced:
 
}
 
"type" :
"identity" ,
  "id" : " Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d",
  "title" :
"Mark Davidson",

  "stix_resources" : {
                
"taxii2" :
" https://example.com/taxii2 " ,
                 "amqp?" :
"amqp://user:pass@host:10000/vhost" ,
                 “sneakernet" :
"Ask Mark (555) 555-5555"
  
},
}
 
There are some really great benefits to having this kind of structure.
 
1.       
If the Organization domain name changes, then the Organization just produces a new revision of its Identity object (one
object)and sends it out to the communities it belongs to. Everyone who receives it know knows how to get the latest updates of objects – even objects created 3 years ago!
2.       
If the Organization’s domain name changes, there are no changes needed to any of the other Objects previously released
by the Organization (apart from the Identity one).
3.       
If the Organization decided to move from HTTPS based TAXII to AMQP or binary or carrier-pigeon based networking then
all that needs to be done is a new revision of the Identity object with a modified stix_resources section!
 
Simple!
 
Cheers
 

Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA   An FS-ISAC and DTCC Company
+61 (407) 203 206
terry@soltra.com
 

 


From:
cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Mark Davidson
Sent: Saturday, 23 January 2016 5:02 AM
To: Wunder, John A. < jwunder@mitre.org >; Foley, Alexander - GIS < alexander.foley@bankofamerica.com >; Jason Keirstead < Jason.Keirstead@ca.ibm.com >;
Jordan, Bret < bret.jordan@bluecoat.com >
Cc: John Anderson < janderson@soltra.com >; Trey Darley < trey@soltra.com >;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format


 


Is there anyone that this proposed structure doesn’t work for (even if you don’t agree with the field names)? I think this alleviates Jason’s concern of tying STIX
to a specific transport, and the “what do you expect?” is answered by the reference key (e.g., “taxii2”), assuming there is some degree of definition behind the key (and individual enclaves can use their own special sauce!).



{   "type" : "indicator" ,   "id" : "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" ,   "references" : { "taxii2" : " https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 " ,                  "amqp?" : "amqp://user:pass@host:10000/vhost#SomeOtherStuff" ,                  “sneakernet" : "Ask Mark (555) 555-5555" },   "producer" : "MarkDavidson" // Omit field for anonymity }

Thank you.


-Mark





From:
< cti-stix@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Friday, January 22, 2016 at 11:54 AM
To: "Foley, Alexander - GIS" < alexander.foley@bankofamerica.com >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Jordan, Bret" < bret.jordan@bluecoat.com >
Cc: John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Object ID format


 





+1


 


URLs tend to be fairly fragile in practice and I would rather have one, single, more complicated method that we can rely on rather than people trying to create
URL schemes that are persistent, having some object IDs resolvable and some not, and tying ourselves to access via a single URI (or maybe in some cases a URL) rather than a list of possible options.


 


John



 


From:
< cti-stix@lists.oasis-open.org > on behalf of "Foley, Alexander - GIS" < alexander.foley@bankofamerica.com >
Date: Friday, January 22, 2016 at 11:26 AM
To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Jordan, Bret" < bret.jordan@bluecoat.com >
Cc: John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Object ID format


 



I have another “back further” question – given the rate at which popular websites change permalinks, who realistically thinks that organizations
are going to do a good job at creating persistent unique identifiers and versioning them over time?  That’s a massive knowledge management problem that would rely on consolidated technology platforms that don’t yet exist.
 
STIX co-chairs, what’s the plan for gaining consensus on the object id?


 
Alex


 


From: cti-stix@lists.oasis-open.org
[ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Jason Keirstead
Sent: Friday, January 22, 2016 11:21 AM
To: Jordan, Bret
Cc: John Anderson; Trey Darley;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format


 
And to go back further.... I still am of the opinion that we can't codify this without TAXII.

So we have a URL in an ID.. now what? If anyone wants to make use of that, then they have to know what is expected if I issue a GET to that URL. Should it return a STIX document? A web page? A word document that is a threat report?

We have to codify this in the standard, otherwise there is no point to even having the field because everyone will put different things there. So now, we are codifying data sharing behavior over the network and STIX URL syntaxes, inside STIX, and not TAXII.


This proposal makes no sense to me as part of the ID because it is going down this path of tying STIX and TAXII together at the hip.

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

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


"Jordan,
Bret" ---01/22/2016 12:03:33 PM---Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cl

From: "Jordan, Bret" < bret.jordan@bluecoat.com >
To: John Anderson < janderson@soltra.com >
Cc: Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Date: 01/22/2016 12:03 PM
Subject:
Re: [cti-stix] Object ID format
Sent by:
< cti-stix@lists.oasis-open.org >








Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cloud? For all of the banks on this list, do you plan on sticking STIX documents on your web server?
And making it so that the public can just surf to them?

I firmly believe that the vast majority, in the 99+% of STIX objects will NEVER be open to general web surfing.. So we are building a solution to a problem that does not exist.



Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Jan 22, 2016, at 07:43, John Anderson < janderson@soltra.com >
wrote:

Trey,
Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly "shifting the ground under our feet" by changing Resources.

URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object.

So, I'd like to think immutability and versioning are orthogonal to Identity.

What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's
proposal demonstrates.)

JSA
---------------------------------------------------------------------
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
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]







This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary
and subject to important terms and conditions available at
http://www.bankofamerica.com/emaildisclaimer . If you are not the intended recipient, please delete this message.

Hi Mark,
 
I’m torn between liking the idea of keeping direct references and not liking the idea.
 
Liking them because:
·         
The answer is right there!
·         
There is no need for identity lookup at all
·         
We have a ‘get out of jail free’ card of the stix_resolvers list if it doesn’t work. This might speed things up.
 
Not liking them because:
·         
They take up extra space in every object in addition to the Identity Object reference
·         
It won’t take long to compute the same thing from the stix_resolvers, saving space
·         
The references could become wrong over time.
·         
Is the extra space consumed with the references array on high volume objects such as Observations and Indicators worth the
few nanoseconds difference in computing the references from the Identity object stix_resolvers field?
 
What do others think?
 
Cheers
 

Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA   An FS-ISAC and DTCC Company
+61 (407) 203 206
terry@soltra.com
 

 


From: Mark Davidson

Sent: Sunday, 24 January 2016 11:57 PM
To: Terry MacDonald <terry@soltra.com>; cti-stix@lists.oasis-open.org
Cc: cti-taxii@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format


 


(Copying the TAXII list because the topic has bled over)


 


I think we are mostly in agreement. A few of your statements touch on a larger topic for me – I think the way we think about architectures could be updated such
that some of these traditional sticking points (versioning, revocation) can be minimized. It’s a topic orthogonal to this thread; suffice to say I do not know of another technology that moves information like we tend to envision it: highly sensitive information
packages that contain policy information being redistributed arbitrarily (as long as those movements conform to policy). Newsgroups do not fit because there is not policy information; email/web don't not fit because they are not redistributed arbitrarily (within
the protocol, anyway).


 


As for tying producer information to the lookup information, I am not sold on two points. I don't believe the producer MUST host objects they create (though they MAY), and I am not sold that
hosted objects MUST have producer information (though they MAY). An organization may host anonymous information on behalf of good-samaritan submitters, for instance. In that case, the producer isn’t hosting the object and the hosted objects would not contain
producer information. A key thing for me is decoupling producer identification from hosting information, as I don’t think there is a compelling reason to tie them together, and I think tying them together has some notable drawbacks.


 


An idea I really like from your email is the idea that producer information could list TAXII capabilities or other stix-relevant network capabilities. IMO this
is good as one option for resolving content (connect to server->search for object). Adding to this idea, if the hosting organization advertised their TAXII in DNS, they would only need identify a domain name (e.g., example.com instead of
https://example.com/taxii2 /). I think that would possibly be a neat capability.


 


Updating the example, I could see:


 


{   "type" : "indicator" ,   "id" : "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" ,   "references" : { "taxii2" : " https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 " ,                  "amqp?" : "amqp://user:pass@host:10000/vhost#SomeOtherStuff" ,                  "sneakernet" : "Ask Mark (555) 555-5555" },   "producer_ref" : "Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d" // Omit field for anonymity }
 
{   "type" : "identity" ,   "id" : " Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d" ,   "title" : "Mark Davidson" ,   "stix_resolvers" : {                   "taxii2" : "example.com" ,  // Use DNS to identify TAXII Server & perform lookups ?                  "amqp?" : "amqp://user:pass@host:10000/vhost" ,                  "sneakernet" : "Ask Mark (555) 555-5555"    } }
 
My idea is that the reference listed directly on the object is the “best path” for resolving the content. The TAXII capabilities listed on the producer are the “second path” for resolving content. I will note the inconsistency between the references values and the STIX resolvers values, which I don’t like, but I’m not sure how to solve .
 
Thank you.


-Mark



 


From:
Terry MacDonald < terry@soltra.com >
Date: Saturday, January 23, 2016 at 1:08 AM
To: Mark Davidson < mdavidson@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Object ID format


 



Hi Mark,
 
Me unfortunately (just slightly). The problem that I have with direct references to where to get the data, is that it goes stale. As
mentioned in my other email, companies are bought by other companies, domain names change, web servers and taxi servers move. So for those reasons, I think we need a way to allow the location of an organizations data repositories to change too.
 
Using the structure you proposed, if an organization did change its domain name, they would need to reissue revisions to all their
objects to update the location of their data store. Or, they would need to ensure that there was a reverse proxy in front of their web services to ‘map’ the old location to the new location on the fly.  Both of these options have their problems. The first
results in a large number of updates that need to be rebroadcast out to the various communities that the organization belongs to; the second results in additional infrastructure that the Organization needs to keep up to date.

 
I think your idea is excellent Mark, and with a little tweak could be even better….
 
Idea:
What if the data location wasn’t actually attached to the Indicator object itself, but instead was bound to the Identity of the producer of the STIX object?

 
An illustrative example….
 
If you have an Indicator object you want to share (and you want people to know where to get it), you would insert a stix_producer_ref
field pointing to the Identity object of who made and published the STIX object:
 
{   "type" : "indicator" ,   "id" : "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" ,   "stix_producer_ref" : " Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d", // Omit field for anonymity
 ….. }
 
Then you have the Identity Object for the stix object creator – and that Identity contains a list of ways for consumers to get more
information about STIX objects that this identity has produced:
 
}
 
"type" :
"identity" ,
  "id" : " Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d",
  "title" :
"Mark Davidson",

  "stix_resources" : {
                
"taxii2" :
" https://example.com/taxii2 " ,
                 "amqp?" :
"amqp://user:pass@host:10000/vhost" ,
                 “sneakernet" :
"Ask Mark (555) 555-5555"
  
},
}
 
There are some really great benefits to having this kind of structure.
 
1.      
If the Organization domain name changes, then the Organization just produces a new revision of its Identity object (one object)and
sends it out to the communities it belongs to. Everyone who receives it know knows how to get the latest updates of objects – even objects created 3 years ago!
2.      
If the Organization’s domain name changes, there are no changes needed to any of the other Objects previously released by
the Organization (apart from the Identity one).
3.      
If the Organization decided to move from HTTPS based TAXII to AMQP or binary or carrier-pigeon based networking then all
that needs to be done is a new revision of the Identity object with a modified stix_resources section!
 
Simple!
 
Cheers
 

Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA   An FS-ISAC and DTCC Company
+61 (407) 203 206
terry@soltra.com
 

 


From:
cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Mark Davidson
Sent: Saturday, 23 January 2016 5:02 AM
To: Wunder, John A. < jwunder@mitre.org >; Foley, Alexander - GIS < alexander.foley@bankofamerica.com >; Jason Keirstead < Jason.Keirstead@ca.ibm.com >;
Jordan, Bret < bret.jordan@bluecoat.com >
Cc: John Anderson < janderson@soltra.com >; Trey Darley < trey@soltra.com >;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format


 


Is there anyone that this proposed structure doesn’t work for (even if you don’t agree with the field names)? I think this alleviates Jason’s concern of tying STIX
to a specific transport, and the “what do you expect?” is answered by the reference key (e.g., “taxii2”), assuming there is some degree of definition behind the key (and individual enclaves can use their own special sauce!).



{   "type" : "indicator" ,   "id" : "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" ,   "references" : { "taxii2" : " https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 " ,                  "amqp?" : "amqp://user:pass@host:10000/vhost#SomeOtherStuff" ,                  “sneakernet" : "Ask Mark (555) 555-5555" },   "producer" : "MarkDavidson" // Omit field for anonymity }

Thank you.


-Mark





From:
< cti-stix@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Friday, January 22, 2016 at 11:54 AM
To: "Foley, Alexander - GIS" < alexander.foley@bankofamerica.com >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Jordan, Bret" < bret.jordan@bluecoat.com >
Cc: John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Object ID format


 





+1


 


URLs tend to be fairly fragile in practice and I would rather have one, single, more complicated method that we can rely on rather than people trying to create
URL schemes that are persistent, having some object IDs resolvable and some not, and tying ourselves to access via a single URI (or maybe in some cases a URL) rather than a list of possible options.


 


John



 


From:
< cti-stix@lists.oasis-open.org > on behalf of "Foley, Alexander - GIS" < alexander.foley@bankofamerica.com >
Date: Friday, January 22, 2016 at 11:26 AM
To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Jordan, Bret" < bret.jordan@bluecoat.com >
Cc: John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Object ID format


 



I have another “back further” question – given the rate at which popular websites change permalinks, who realistically thinks that organizations
are going to do a good job at creating persistent unique identifiers and versioning them over time?  That’s a massive knowledge management problem that would rely on consolidated technology platforms that don’t yet exist.
 
STIX co-chairs, what’s the plan for gaining consensus on the object id?


 
Alex


 


From: cti-stix@lists.oasis-open.org
[ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Jason Keirstead
Sent: Friday, January 22, 2016 11:21 AM
To: Jordan, Bret
Cc: John Anderson; Trey Darley;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format


 
And to go back further.... I still am of the opinion that we can't codify this without TAXII.

So we have a URL in an ID.. now what? If anyone wants to make use of that, then they have to know what is expected if I issue a GET to that URL. Should it return a STIX document? A web page? A word document that is a threat report?

We have to codify this in the standard, otherwise there is no point to even having the field because everyone will put different things there. So now, we are codifying data sharing behavior over the network and STIX URL syntaxes, inside STIX, and not TAXII.


This proposal makes no sense to me as part of the ID because it is going down this path of tying STIX and TAXII together at the hip.

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

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


"Jordan,
Bret" ---01/22/2016 12:03:33 PM---Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cl

From: "Jordan, Bret" < bret.jordan@bluecoat.com >
To: John Anderson < janderson@soltra.com >
Cc: Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Date: 01/22/2016 12:03 PM
Subject:
Re: [cti-stix] Object ID format
Sent by:
< cti-stix@lists.oasis-open.org >










Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cloud? For all of the banks on this list, do you plan on sticking STIX documents on your web server?
And making it so that the public can just surf to them?

I firmly believe that the vast majority, in the 99+% of STIX objects will NEVER be open to general web surfing.. So we are building a solution to a problem that does not exist.



Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Jan 22, 2016, at 07:43, John Anderson < janderson@soltra.com >
wrote:

Trey,
Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly "shifting the ground under our feet" by changing Resources.

URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object.

So, I'd like to think immutability and versioning are orthogonal to Identity.

What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's
proposal demonstrates.)

JSA
---------------------------------------------------------------------
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
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]








This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary
and subject to important terms and conditions available at
http://www.bankofamerica.com/emaildisclaimer . If you are not the intended recipient, please delete this message.

Hi Mark,
 
I’m torn between liking the idea of keeping direct references and not liking the idea.
 
Liking them because:
·         
The answer is right there!
·         
There is no need for identity lookup at all
·         
We have a ‘get out of jail free’ card of the stix_resolvers list if it doesn’t work. This might speed things up.
 
Not liking them because:
·         
They take up extra space in every object in addition to the Identity Object reference
·         
It won’t take long to compute the same thing from the stix_resolvers, saving space
·         
The references could become wrong over time.
·         
Is the extra space consumed with the references array on high volume objects such as Observations and Indicators worth the
few nanoseconds difference in computing the references from the Identity object stix_resolvers field?
 
What do others think?
 
Cheers
 

Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA   An FS-ISAC and DTCC Company
+61 (407) 203 206
terry@soltra.com
 

 


From: Mark Davidson

Sent: Sunday, 24 January 2016 11:57 PM
To: Terry MacDonald <terry@soltra.com>; cti-stix@lists.oasis-open.org
Cc: cti-taxii@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format


 


(Copying the TAXII list because the topic has bled over)


 


I think we are mostly in agreement. A few of your statements touch on a larger topic for me – I think the way we think about architectures could be updated such
that some of these traditional sticking points (versioning, revocation) can be minimized. It’s a topic orthogonal to this thread; suffice to say I do not know of another technology that moves information like we tend to envision it: highly sensitive information
packages that contain policy information being redistributed arbitrarily (as long as those movements conform to policy). Newsgroups do not fit because there is not policy information; email/web don't not fit because they are not redistributed arbitrarily (within
the protocol, anyway).


 


As for tying producer information to the lookup information, I am not sold on two points. I don't believe the producer MUST host objects they create (though they MAY), and I am not sold that
hosted objects MUST have producer information (though they MAY). An organization may host anonymous information on behalf of good-samaritan submitters, for instance. In that case, the producer isn’t hosting the object and the hosted objects would not contain
producer information. A key thing for me is decoupling producer identification from hosting information, as I don’t think there is a compelling reason to tie them together, and I think tying them together has some notable drawbacks.


 


An idea I really like from your email is the idea that producer information could list TAXII capabilities or other stix-relevant network capabilities. IMO this
is good as one option for resolving content (connect to server->search for object). Adding to this idea, if the hosting organization advertised their TAXII in DNS, they would only need identify a domain name (e.g., example.com instead of
https://example.com/taxii2 /). I think that would possibly be a neat capability.


 


Updating the example, I could see:


 


{   "type" : "indicator" ,   "id" : "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" ,   "references" : { "taxii2" : " https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 " ,                  "amqp?" : "amqp://user:pass@host:10000/vhost#SomeOtherStuff" ,                  "sneakernet" : "Ask Mark (555) 555-5555" },   "producer_ref" : "Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d" // Omit field for anonymity }
 
{   "type" : "identity" ,   "id" : " Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d" ,   "title" : "Mark Davidson" ,   "stix_resolvers" : {                   "taxii2" : "example.com" ,  // Use DNS to identify TAXII Server & perform lookups ?                  "amqp?" : "amqp://user:pass@host:10000/vhost" ,                  "sneakernet" : "Ask Mark (555) 555-5555"    } }
 
My idea is that the reference listed directly on the object is the “best path” for resolving the content. The TAXII capabilities listed on the producer are the “second path” for resolving content. I will note the inconsistency between the references values and the STIX resolvers values, which I don’t like, but I’m not sure how to solve .
 
Thank you.


-Mark



 


From:
Terry MacDonald < terry@soltra.com >
Date: Saturday, January 23, 2016 at 1:08 AM
To: Mark Davidson < mdavidson@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Object ID format


 



Hi Mark,
 
Me unfortunately (just slightly). The problem that I have with direct references to where to get the data, is that it goes stale. As
mentioned in my other email, companies are bought by other companies, domain names change, web servers and taxi servers move. So for those reasons, I think we need a way to allow the location of an organizations data repositories to change too.
 
Using the structure you proposed, if an organization did change its domain name, they would need to reissue revisions to all their
objects to update the location of their data store. Or, they would need to ensure that there was a reverse proxy in front of their web services to ‘map’ the old location to the new location on the fly.  Both of these options have their problems. The first
results in a large number of updates that need to be rebroadcast out to the various communities that the organization belongs to; the second results in additional infrastructure that the Organization needs to keep up to date.

 
I think your idea is excellent Mark, and with a little tweak could be even better….
 
Idea:
What if the data location wasn’t actually attached to the Indicator object itself, but instead was bound to the Identity of the producer of the STIX object?

 
An illustrative example….
 
If you have an Indicator object you want to share (and you want people to know where to get it), you would insert a stix_producer_ref
field pointing to the Identity object of who made and published the STIX object:
 
{   "type" : "indicator" ,   "id" : "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" ,   "stix_producer_ref" : " Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d", // Omit field for anonymity
 ….. }
 
Then you have the Identity Object for the stix object creator – and that Identity contains a list of ways for consumers to get more
information about STIX objects that this identity has produced:
 
}
 
"type" :
"identity" ,
  "id" : " Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d",
  "title" :
"Mark Davidson",

  "stix_resources" : {
                
"taxii2" :
" https://example.com/taxii2 " ,
                 "amqp?" :
"amqp://user:pass@host:10000/vhost" ,
                 “sneakernet" :
"Ask Mark (555) 555-5555"
  
},
}
 
There are some really great benefits to having this kind of structure.
 
1.      
If the Organization domain name changes, then the Organization just produces a new revision of its Identity object (one object)and
sends it out to the communities it belongs to. Everyone who receives it know knows how to get the latest updates of objects – even objects created 3 years ago!
2.      
If the Organization’s domain name changes, there are no changes needed to any of the other Objects previously released by
the Organization (apart from the Identity one).
3.      
If the Organization decided to move from HTTPS based TAXII to AMQP or binary or carrier-pigeon based networking then all
that needs to be done is a new revision of the Identity object with a modified stix_resources section!
 
Simple!
 
Cheers
 

Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA   An FS-ISAC and DTCC Company
+61 (407) 203 206
terry@soltra.com
 

 


From:
cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Mark Davidson
Sent: Saturday, 23 January 2016 5:02 AM
To: Wunder, John A. < jwunder@mitre.org >; Foley, Alexander - GIS < alexander.foley@bankofamerica.com >; Jason Keirstead < Jason.Keirstead@ca.ibm.com >;
Jordan, Bret < bret.jordan@bluecoat.com >
Cc: John Anderson < janderson@soltra.com >; Trey Darley < trey@soltra.com >;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format


 


Is there anyone that this proposed structure doesn’t work for (even if you don’t agree with the field names)? I think this alleviates Jason’s concern of tying STIX
to a specific transport, and the “what do you expect?” is answered by the reference key (e.g., “taxii2”), assuming there is some degree of definition behind the key (and individual enclaves can use their own special sauce!).



{   "type" : "indicator" ,   "id" : "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" ,   "references" : { "taxii2" : " https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 " ,                  "amqp?" : "amqp://user:pass@host:10000/vhost#SomeOtherStuff" ,                  “sneakernet" : "Ask Mark (555) 555-5555" },   "producer" : "MarkDavidson" // Omit field for anonymity }

Thank you.


-Mark





From:
< cti-stix@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Friday, January 22, 2016 at 11:54 AM
To: "Foley, Alexander - GIS" < alexander.foley@bankofamerica.com >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Jordan, Bret" < bret.jordan@bluecoat.com >
Cc: John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Object ID format


 





+1


 


URLs tend to be fairly fragile in practice and I would rather have one, single, more complicated method that we can rely on rather than people trying to create
URL schemes that are persistent, having some object IDs resolvable and some not, and tying ourselves to access via a single URI (or maybe in some cases a URL) rather than a list of possible options.


 


John



 


From:
< cti-stix@lists.oasis-open.org > on behalf of "Foley, Alexander - GIS" < alexander.foley@bankofamerica.com >
Date: Friday, January 22, 2016 at 11:26 AM
To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Jordan, Bret" < bret.jordan@bluecoat.com >
Cc: John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Object ID format


 



I have another “back further” question – given the rate at which popular websites change permalinks, who realistically thinks that organizations
are going to do a good job at creating persistent unique identifiers and versioning them over time?  That’s a massive knowledge management problem that would rely on consolidated technology platforms that don’t yet exist.
 
STIX co-chairs, what’s the plan for gaining consensus on the object id?


 
Alex


 


From: cti-stix@lists.oasis-open.org
[ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Jason Keirstead
Sent: Friday, January 22, 2016 11:21 AM
To: Jordan, Bret
Cc: John Anderson; Trey Darley;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format


 
And to go back further.... I still am of the opinion that we can't codify this without TAXII.

So we have a URL in an ID.. now what? If anyone wants to make use of that, then they have to know what is expected if I issue a GET to that URL. Should it return a STIX document? A web page? A word document that is a threat report?

We have to codify this in the standard, otherwise there is no point to even having the field because everyone will put different things there. So now, we are codifying data sharing behavior over the network and STIX URL syntaxes, inside STIX, and not TAXII.


This proposal makes no sense to me as part of the ID because it is going down this path of tying STIX and TAXII together at the hip.

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

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


"Jordan,
Bret" ---01/22/2016 12:03:33 PM---Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cl

From: "Jordan, Bret" < bret.jordan@bluecoat.com >
To: John Anderson < janderson@soltra.com >
Cc: Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Date: 01/22/2016 12:03 PM
Subject:
Re: [cti-stix] Object ID format
Sent by:
< cti-stix@lists.oasis-open.org >










Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cloud? For all of the banks on this list, do you plan on sticking STIX documents on your web server?
And making it so that the public can just surf to them?

I firmly believe that the vast majority, in the 99+% of STIX objects will NEVER be open to general web surfing.. So we are building a solution to a problem that does not exist.



Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Jan 22, 2016, at 07:43, John Anderson < janderson@soltra.com >
wrote:

Trey,
Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly "shifting the ground under our feet" by changing Resources.

URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object.

So, I'd like to think immutability and versioning are orthogonal to Identity.

What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's
proposal demonstrates.)

JSA
---------------------------------------------------------------------
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
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]








This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary
and subject to important terms and conditions available at
http://www.bankofamerica.com/emaildisclaimer . If you are not the intended recipient, please delete this message.

I think people will get confused and ask why is their and InfomrationSourceType and an extra blob of data outside of it that also gives information about the Producer.  Can we please have just one object that contains information about the Producer and where people can go to talk to that Producer????? Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Jan 24, 2016, at 22:03, Terry MacDonald < terry@soltra.com > wrote: Hi Mark,   I’m torn between liking the idea of keeping direct references and not liking the idea.   Liking them because: ·            The answer is right there! ·            There is no need for identity lookup at all ·            We have a ‘get out of jail free’ card of the stix_resolvers list if it doesn’t work. This might speed things up.   Not liking them because: ·            They take up extra space in every object in addition to the Identity Object reference ·            It won’t take long to compute the same thing from the stix_resolvers, saving space ·            The references could become wrong over time. ·            Is the extra space consumed with the references array on high volume objects such as Observations and Indicators worth the few nanoseconds difference in computing the references from the Identity object stix_resolvers field?   What do others think?   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA   An FS-ISAC and DTCC Company +61 (407) 203 206   terry@soltra.com     From:   Mark Davidson   Sent:   Sunday, 24 January 2016 11:57 PM To:   Terry MacDonald < terry@soltra.com >;   cti-stix@lists.oasis-open.org Cc:   cti-taxii@lists.oasis-open.org Subject:   Re: [cti-stix] Object ID format   (Copying the TAXII list because the topic has bled over)   I think we are mostly in agreement. A few of your statements touch on a larger topic for me – I think the way we think about architectures could be updated such that some of these traditional sticking points (versioning, revocation) can be minimized. It’s a topic orthogonal to this thread; suffice to say I do not know of another technology that moves information like we tend to envision it: highly sensitive information packages that contain policy information being redistributed arbitrarily (as long as those movements conform to policy). Newsgroups do not fit because there is not policy information; email/web don't not fit because they are not redistributed arbitrarily (within the protocol, anyway).   As for tying producer information to the lookup information, I am not sold on two points. I don't believe the producer MUST host objects they create (though they MAY), and I am not sold that hosted objects MUST have producer information (though they MAY). An organization may host anonymous information on behalf of good-samaritan submitters, for instance. In that case, the producer isn’t hosting the object and the hosted objects would not contain producer information. A key thing for me is decoupling producer identification from hosting information, as I don’t think there is a compelling reason to tie them together, and I think tying them together has some notable drawbacks.   An idea I really like from your email is the idea that producer information could list TAXII capabilities or other stix-relevant network capabilities. IMO this is good as one option for resolving content (connect to server->search for object). Adding to this idea, if the hosting organization advertised their TAXII in DNS, they would only need identify a domain name (e.g.,   example.com   instead of   https://example.com/taxii2 /). I think that would possibly be a neat capability.   Updating the example, I could see:   {   type : indicator ,   id : Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 ,   references : { taxii2 : https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 ,                  amqp? : amqp://user:pass@host:10000/vhost#SomeOtherStuff ,                  sneakernet : Ask Mark (555) 555-5555 },   producer_ref : Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d // Omit field for anonymity }   {   type : identity ,   id : Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d ,   title : Mark Davidson ,   stix_resolvers : {                   taxii2 : example.com ,  // Use DNS to identify TAXII Server & perform lookups ?                  amqp? : amqp://user:pass@host:10000/vhost ,                  sneakernet : Ask Mark (555) 555-5555    } }   My idea is that the reference listed directly on the object is the “best path” for resolving the content. The TAXII capabilities listed on the producer are the “second path” for resolving content. I will note the inconsistency between the references values and the STIX resolvers values, which I don’t like, but I’m not sure how to solve .   Thank you. -Mark   From:   Terry MacDonald < terry@soltra.com > Date:   Saturday, January 23, 2016 at 1:08 AM To:   Mark Davidson < mdavidson@soltra.com >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject:   RE: [cti-stix] Object ID format   Hi Mark,   Me unfortunately (just slightly). The problem that I have with direct references to where to get the data, is that it goes stale. As mentioned in my other email, companies are bought by other companies, domain names change, web servers and taxi servers move. So for those reasons, I think we need a way to allow the location of an organizations data repositories to change too.   Using the structure you proposed, if an organization did change its domain name, they would need to reissue revisions to all their objects to update the location of their data store. Or, they would need to ensure that there was a reverse proxy in front of their web services to ‘map’ the old location to the new location on the fly.  Both of these options have their problems. The first results in a large number of updates that need to be rebroadcast out to the various communities that the organization belongs to; the second results in additional infrastructure that the Organization needs to keep up to date.   I think your idea is excellent Mark, and with a little tweak could be even better….   Idea:   What if the data location wasn’t actually attached to the Indicator object itself, but instead was bound to the Identity of the producer of the STIX object?   An illustrative example….   If you have an Indicator object you want to share (and you want people to know where to get it), you would insert a stix_producer_ref field pointing to the Identity object of who made and published the STIX object:   {   type : indicator ,   id : Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 ,   stix_producer_ref : Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d , // Omit field for anonymity  ….. }   Then you have the Identity Object for the stix object creator – and that Identity contains a list of ways for consumers to get more information about STIX objects that this identity has produced:   }     type :   identity ,   id : Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d ,   title :   Mark Davidson ,    stix_resources : {                    taxii2 :   https://example.com/taxii2   ,                    amqp? :   amqp://user:pass@host:10000/vhost ,                    “sneakernet :   Ask Mark (555) 555-5555      }, }   There are some really great benefits to having this kind of structure.   1.         If the Organization domain name changes, then the Organization just produces a new revision of its Identity object (one object)and sends it out to the communities it belongs to. Everyone who receives it know knows how to get the latest updates of objects – even objects created 3 years ago! 2.         If the Organization’s domain name changes, there are no changes needed to any of the other Objects previously released by the Organization (apart from the Identity one). 3.         If the Organization decided to move from HTTPS based TAXII to AMQP or binary or carrier-pigeon based networking then all that needs to be done is a new revision of the Identity object with a modified stix_resources section!   Simple!   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA   An FS-ISAC and DTCC Company +61 (407) 203 206   terry@soltra.com     From:   cti-stix@lists.oasis-open.org   [ mailto:cti-stix@lists.oasis-open.org ]   On Behalf Of   Mark Davidson Sent:   Saturday, 23 January 2016 5:02 AM To:   Wunder, John A. < jwunder@mitre.org >; Foley, Alexander - GIS < alexander.foley@bankofamerica.com >; Jason Keirstead < Jason.Keirstead@ca.ibm.com >; Jordan, Bret < bret.jordan@bluecoat.com > Cc:   John Anderson < janderson@soltra.com >; Trey Darley < trey@soltra.com >;   cti-stix@lists.oasis-open.org Subject:   Re: [cti-stix] Object ID format   Is there anyone that this proposed structure doesn’t work for (even if you don’t agree with the field names)? I think this alleviates Jason’s concern of tying STIX to a specific transport, and the “what do you expect?” is answered by the reference key (e.g., “taxii2”), assuming there is some degree of definition behind the key (and individual enclaves can use their own special sauce!). {   type : indicator ,   id : Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 ,   references : { taxii2 : https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 ,                  amqp? : amqp://user:pass@host:10000/vhost#SomeOtherStuff ,                  “sneakernet : Ask Mark (555) 555-5555 },   producer : MarkDavidson // Omit field for anonymity } Thank you. -Mark From:   < cti-stix@lists.oasis-open.org > on behalf of Wunder, John A. < jwunder@mitre.org > Date:   Friday, January 22, 2016 at 11:54 AM To:   Foley, Alexander - GIS < alexander.foley@bankofamerica.com >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Jordan, Bret < bret.jordan@bluecoat.com > Cc:   John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject:   Re: [cti-stix] Object ID format   +1   URLs tend to be fairly fragile in practice and I would rather have one, single, more complicated method that we can rely on rather than people trying to create URL schemes that are persistent, having some object IDs resolvable and some not, and tying ourselves to access via a single URI (or maybe in some cases a URL) rather than a list of possible options.   John   From:   < cti-stix@lists.oasis-open.org > on behalf of Foley, Alexander - GIS < alexander.foley@bankofamerica.com > Date:   Friday, January 22, 2016 at 11:26 AM To:   Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Jordan, Bret < bret.jordan@bluecoat.com > Cc:   John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject:   RE: [cti-stix] Object ID format   I have another “back further” question – given the rate at which popular websites change permalinks, who realistically thinks that organizations are going to do a good job at creating persistent unique identifiers and versioning them over time?  That’s a massive knowledge management problem that would rely on consolidated technology platforms that don’t yet exist.   STIX co-chairs, what’s the plan for gaining consensus on the object id?   Alex   From: cti-stix@lists.oasis-open.org   [ mailto:cti-stix@lists.oasis-open.org ]   On Behalf Of   Jason Keirstead Sent:   Friday, January 22, 2016 11:21 AM To:   Jordan, Bret Cc:   John Anderson; Trey Darley;   cti-stix@lists.oasis-open.org Subject:   Re: [cti-stix] Object ID format   And to go back further.... I still am of the opinion that we can't codify this without TAXII. So we have a URL in an ID.. now what? If anyone wants to make use of that, then they have to know what is expected if I issue a GET to that URL. Should it return a STIX document? A web page? A word document that is a threat report? We have to codify this in the standard, otherwise there is no point to even having the field because everyone will put different things there. So now, we are codifying data sharing behavior over the network and STIX URL syntaxes, inside STIX, and not TAXII.   This proposal makes no sense to me as part of the ID because it is going down this path of tying STIX and TAXII together at the hip. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security     www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown   <image001.gif> Jordan, Bret ---01/22/2016 12:03:33 PM---Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cl From:   Jordan, Bret < bret.jordan@bluecoat.com > To:   John Anderson < janderson@soltra.com > Cc:   Trey Darley < trey@soltra.com >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Date:   01/22/2016 12:03 PM Subject:   Re: [cti-stix] Object ID format Sent by:   < cti-stix@lists.oasis-open.org > Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cloud? For all of the banks on this list, do you plan on sticking STIX documents on your web server? And making it so that the public can just surf to them? I firmly believe that the vast majority, in the 99+% of STIX objects will NEVER be open to general web surfing.. So we are building a solution to a problem that does not exist.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg. On Jan 22, 2016, at 07:43, John Anderson < janderson@soltra.com > wrote: Trey, Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly shifting the ground under our feet by changing Resources. URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object. So, I'd like to think immutability and versioning are orthogonal to Identity. What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's proposal demonstrates.) JSA --------------------------------------------------------------------- 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 [attachment signature.asc deleted by Jason Keirstead/CanEast/IBM]   This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at   http://www.bankofamerica.com/emaildisclaimer . If you are not the intended recipient, please delete this message. Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

I think people will get confused and ask why is their and InfomrationSourceType and an extra blob of data outside of it that also gives information about the Producer.  Can we please have just one object that contains information about the Producer and where people can go to talk to that Producer????? Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Jan 24, 2016, at 22:03, Terry MacDonald < terry@soltra.com > wrote: Hi Mark,   I’m torn between liking the idea of keeping direct references and not liking the idea.   Liking them because: ·            The answer is right there! ·            There is no need for identity lookup at all ·            We have a ‘get out of jail free’ card of the stix_resolvers list if it doesn’t work. This might speed things up.   Not liking them because: ·            They take up extra space in every object in addition to the Identity Object reference ·            It won’t take long to compute the same thing from the stix_resolvers, saving space ·            The references could become wrong over time. ·            Is the extra space consumed with the references array on high volume objects such as Observations and Indicators worth the few nanoseconds difference in computing the references from the Identity object stix_resolvers field?   What do others think?   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA   An FS-ISAC and DTCC Company +61 (407) 203 206   terry@soltra.com     From:   Mark Davidson   Sent:   Sunday, 24 January 2016 11:57 PM To:   Terry MacDonald < terry@soltra.com >;   cti-stix@lists.oasis-open.org Cc:   cti-taxii@lists.oasis-open.org Subject:   Re: [cti-stix] Object ID format   (Copying the TAXII list because the topic has bled over)   I think we are mostly in agreement. A few of your statements touch on a larger topic for me – I think the way we think about architectures could be updated such that some of these traditional sticking points (versioning, revocation) can be minimized. It’s a topic orthogonal to this thread; suffice to say I do not know of another technology that moves information like we tend to envision it: highly sensitive information packages that contain policy information being redistributed arbitrarily (as long as those movements conform to policy). Newsgroups do not fit because there is not policy information; email/web don't not fit because they are not redistributed arbitrarily (within the protocol, anyway).   As for tying producer information to the lookup information, I am not sold on two points. I don't believe the producer MUST host objects they create (though they MAY), and I am not sold that hosted objects MUST have producer information (though they MAY). An organization may host anonymous information on behalf of good-samaritan submitters, for instance. In that case, the producer isn’t hosting the object and the hosted objects would not contain producer information. A key thing for me is decoupling producer identification from hosting information, as I don’t think there is a compelling reason to tie them together, and I think tying them together has some notable drawbacks.   An idea I really like from your email is the idea that producer information could list TAXII capabilities or other stix-relevant network capabilities. IMO this is good as one option for resolving content (connect to server->search for object). Adding to this idea, if the hosting organization advertised their TAXII in DNS, they would only need identify a domain name (e.g.,   example.com   instead of   https://example.com/taxii2 /). I think that would possibly be a neat capability.   Updating the example, I could see:   {   type : indicator ,   id : Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 ,   references : { taxii2 : https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 ,                  amqp? : amqp://user:pass@host:10000/vhost#SomeOtherStuff ,                  sneakernet : Ask Mark (555) 555-5555 },   producer_ref : Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d // Omit field for anonymity }   {   type : identity ,   id : Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d ,   title : Mark Davidson ,   stix_resolvers : {                   taxii2 : example.com ,  // Use DNS to identify TAXII Server & perform lookups ?                  amqp? : amqp://user:pass@host:10000/vhost ,                  sneakernet : Ask Mark (555) 555-5555    } }   My idea is that the reference listed directly on the object is the “best path” for resolving the content. The TAXII capabilities listed on the producer are the “second path” for resolving content. I will note the inconsistency between the references values and the STIX resolvers values, which I don’t like, but I’m not sure how to solve .   Thank you. -Mark   From:   Terry MacDonald < terry@soltra.com > Date:   Saturday, January 23, 2016 at 1:08 AM To:   Mark Davidson < mdavidson@soltra.com >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject:   RE: [cti-stix] Object ID format   Hi Mark,   Me unfortunately (just slightly). The problem that I have with direct references to where to get the data, is that it goes stale. As mentioned in my other email, companies are bought by other companies, domain names change, web servers and taxi servers move. So for those reasons, I think we need a way to allow the location of an organizations data repositories to change too.   Using the structure you proposed, if an organization did change its domain name, they would need to reissue revisions to all their objects to update the location of their data store. Or, they would need to ensure that there was a reverse proxy in front of their web services to ‘map’ the old location to the new location on the fly.  Both of these options have their problems. The first results in a large number of updates that need to be rebroadcast out to the various communities that the organization belongs to; the second results in additional infrastructure that the Organization needs to keep up to date.   I think your idea is excellent Mark, and with a little tweak could be even better….   Idea:   What if the data location wasn’t actually attached to the Indicator object itself, but instead was bound to the Identity of the producer of the STIX object?   An illustrative example….   If you have an Indicator object you want to share (and you want people to know where to get it), you would insert a stix_producer_ref field pointing to the Identity object of who made and published the STIX object:   {   type : indicator ,   id : Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 ,   stix_producer_ref : Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d , // Omit field for anonymity  ….. }   Then you have the Identity Object for the stix object creator – and that Identity contains a list of ways for consumers to get more information about STIX objects that this identity has produced:   }     type :   identity ,   id : Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d ,   title :   Mark Davidson ,    stix_resources : {                    taxii2 :   https://example.com/taxii2   ,                    amqp? :   amqp://user:pass@host:10000/vhost ,                    “sneakernet :   Ask Mark (555) 555-5555      }, }   There are some really great benefits to having this kind of structure.   1.         If the Organization domain name changes, then the Organization just produces a new revision of its Identity object (one object)and sends it out to the communities it belongs to. Everyone who receives it know knows how to get the latest updates of objects – even objects created 3 years ago! 2.         If the Organization’s domain name changes, there are no changes needed to any of the other Objects previously released by the Organization (apart from the Identity one). 3.         If the Organization decided to move from HTTPS based TAXII to AMQP or binary or carrier-pigeon based networking then all that needs to be done is a new revision of the Identity object with a modified stix_resources section!   Simple!   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA   An FS-ISAC and DTCC Company +61 (407) 203 206   terry@soltra.com     From:   cti-stix@lists.oasis-open.org   [ mailto:cti-stix@lists.oasis-open.org ]   On Behalf Of   Mark Davidson Sent:   Saturday, 23 January 2016 5:02 AM To:   Wunder, John A. < jwunder@mitre.org >; Foley, Alexander - GIS < alexander.foley@bankofamerica.com >; Jason Keirstead < Jason.Keirstead@ca.ibm.com >; Jordan, Bret < bret.jordan@bluecoat.com > Cc:   John Anderson < janderson@soltra.com >; Trey Darley < trey@soltra.com >;   cti-stix@lists.oasis-open.org Subject:   Re: [cti-stix] Object ID format   Is there anyone that this proposed structure doesn’t work for (even if you don’t agree with the field names)? I think this alleviates Jason’s concern of tying STIX to a specific transport, and the “what do you expect?” is answered by the reference key (e.g., “taxii2”), assuming there is some degree of definition behind the key (and individual enclaves can use their own special sauce!). {   type : indicator ,   id : Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 ,   references : { taxii2 : https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 ,                  amqp? : amqp://user:pass@host:10000/vhost#SomeOtherStuff ,                  “sneakernet : Ask Mark (555) 555-5555 },   producer : MarkDavidson // Omit field for anonymity } Thank you. -Mark From:   < cti-stix@lists.oasis-open.org > on behalf of Wunder, John A. < jwunder@mitre.org > Date:   Friday, January 22, 2016 at 11:54 AM To:   Foley, Alexander - GIS < alexander.foley@bankofamerica.com >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Jordan, Bret < bret.jordan@bluecoat.com > Cc:   John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject:   Re: [cti-stix] Object ID format   +1   URLs tend to be fairly fragile in practice and I would rather have one, single, more complicated method that we can rely on rather than people trying to create URL schemes that are persistent, having some object IDs resolvable and some not, and tying ourselves to access via a single URI (or maybe in some cases a URL) rather than a list of possible options.   John   From:   < cti-stix@lists.oasis-open.org > on behalf of Foley, Alexander - GIS < alexander.foley@bankofamerica.com > Date:   Friday, January 22, 2016 at 11:26 AM To:   Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Jordan, Bret < bret.jordan@bluecoat.com > Cc:   John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject:   RE: [cti-stix] Object ID format   I have another “back further” question – given the rate at which popular websites change permalinks, who realistically thinks that organizations are going to do a good job at creating persistent unique identifiers and versioning them over time?  That’s a massive knowledge management problem that would rely on consolidated technology platforms that don’t yet exist.   STIX co-chairs, what’s the plan for gaining consensus on the object id?   Alex   From: cti-stix@lists.oasis-open.org   [ mailto:cti-stix@lists.oasis-open.org ]   On Behalf Of   Jason Keirstead Sent:   Friday, January 22, 2016 11:21 AM To:   Jordan, Bret Cc:   John Anderson; Trey Darley;   cti-stix@lists.oasis-open.org Subject:   Re: [cti-stix] Object ID format   And to go back further.... I still am of the opinion that we can't codify this without TAXII. So we have a URL in an ID.. now what? If anyone wants to make use of that, then they have to know what is expected if I issue a GET to that URL. Should it return a STIX document? A web page? A word document that is a threat report? We have to codify this in the standard, otherwise there is no point to even having the field because everyone will put different things there. So now, we are codifying data sharing behavior over the network and STIX URL syntaxes, inside STIX, and not TAXII.   This proposal makes no sense to me as part of the ID because it is going down this path of tying STIX and TAXII together at the hip. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security     www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown   <image001.gif> Jordan, Bret ---01/22/2016 12:03:33 PM---Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cl From:   Jordan, Bret < bret.jordan@bluecoat.com > To:   John Anderson < janderson@soltra.com > Cc:   Trey Darley < trey@soltra.com >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Date:   01/22/2016 12:03 PM Subject:   Re: [cti-stix] Object ID format Sent by:   < cti-stix@lists.oasis-open.org > Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cloud? For all of the banks on this list, do you plan on sticking STIX documents on your web server? And making it so that the public can just surf to them? I firmly believe that the vast majority, in the 99+% of STIX objects will NEVER be open to general web surfing.. So we are building a solution to a problem that does not exist.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg. On Jan 22, 2016, at 07:43, John Anderson < janderson@soltra.com > wrote: Trey, Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly shifting the ground under our feet by changing Resources. URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object. So, I'd like to think immutability and versioning are orthogonal to Identity. What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's proposal demonstrates.) JSA --------------------------------------------------------------------- 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 [attachment signature.asc deleted by Jason Keirstead/CanEast/IBM]   This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at   http://www.bankofamerica.com/emaildisclaimer . If you are not the intended recipient, please delete this message. Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

(Copying the TAXII list because the topic has bled over)




I think we are mostly in agreement. A few of your statements touch on a larger topic for me – I think the way we think about architectures could be updated such that some of these traditional sticking points (versioning, revocation) can be minimized. It’s a
topic orthogonal to this thread; suffice to say I do not know of another technology that moves information like we tend to envision it: highly sensitive information packages that contain policy information being redistributed arbitrarily (as long as those
movements conform to policy). Newsgroups do not fit because there is not policy information; email/web don't not fit because they are not redistributed arbitrarily (within the protocol, anyway).



As for tying producer information to the lookup information, I am not sold on two points. I don't believe the producer MUST host objects they create (though they MAY), and I am not sold that hosted objects MUST have producer
information (though they MAY). An organization may host anonymous information on behalf of good-samaritan submitters, for instance. In that case, the producer isn’t hosting the object and the hosted objects would not contain producer information. A key thing
for me is decoupling producer identification from hosting information, as I don’t think there is a compelling reason to tie them together, and I think tying them together has some notable drawbacks.




An idea I really like from your email is the idea that producer information could list TAXII capabilities or other stix-relevant network capabilities. IMO this is good as one option for resolving content (connect to server->search for object). Adding to this
idea, if the hosting organization advertised their TAXII in DNS, they would only need identify a domain name (e.g., example.com instead of
https://example.com/taxii2 /). I think that would possibly be a neat capability.




Updating the example, I could see:




{ "type" : "indicator" , "id" : "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" , "references" : { "taxii2" : "https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" , "amqp?" : "amqp://user:pass@host:10000/vhost#SomeOtherStuff" , "sneakernet" : "Ask Mark (555) 555-5555" }, "producer_ref" : "Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d" // Omit field for anonymity }

{ "type" : "identity" , "id" : " Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d" , "title" : "Mark Davidson" , "stix_resolvers" : { "taxii2" : "example.com" , // Use DNS to identify TAXII Server & perform lookups ? "amqp?" : "amqp://user:pass@host:10000/vhost" , "sneakernet" : "Ask Mark (555) 555-5555" } } My idea is that the reference listed directly on the object is the “best path” for resolving the content. The TAXII capabilities listed on the producer are the “second path” for resolving content. I will note the inconsistency between the references values and the STIX resolvers values, which I don’t like, but I’m not sure how to solve . Thank you.


-Mark









From: Terry MacDonald < terry@soltra.com >
Date: Saturday, January 23, 2016 at 1:08 AM
To: Mark Davidson < mdavidson@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Object ID format








Hi Mark,
 
Me unfortunately (just slightly). The problem that I have with direct references to where to get the data, is that it goes stale. As
mentioned in my other email, companies are bought by other companies, domain names change, web servers and taxi servers move. So for those reasons, I think we need a way to allow the location of an organizations data repositories to change too.
 
Using the structure you proposed, if an organization did change its domain name, they would need to reissue revisions to all their
objects to update the location of their data store. Or, they would need to ensure that there was a reverse proxy in front of their web services to ‘map’ the old location to the new location on the fly.  Both of these options have their problems. The first
results in a large number of updates that need to be rebroadcast out to the various communities that the organization belongs to; the second results in additional infrastructure that the Organization needs to keep up to date.

 
I think your idea is excellent Mark, and with a little tweak could be even better….
 
Idea:
What if the data location wasn’t actually attached to the Indicator object itself, but instead was bound to the Identity of the producer of the STIX object?

 
An illustrative example….
 
If you have an Indicator object you want to share (and you want people to know where to get it), you would insert a stix_producer_ref
field pointing to the Identity object of who made and published the STIX object:
 
{   "type" : "indicator" ,   "id" : "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" ,   "stix_producer_ref" : " Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d", // Omit field for anonymity
 ….. }
 
Then you have the Identity Object for the stix object creator – and that Identity contains a list of ways for consumers to get more
information about STIX objects that this identity has produced:
 
}
 
"type" :
"identity" ,
  "id" : " Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d",
  "title" :
"Mark Davidson",

  "stix_resources" : {
                
"taxii2" :
" https://example.com/taxii2 " ,
                 "amqp?" :
"amqp://user:pass@host:10000/vhost" ,
                 “sneakernet" :
"Ask Mark (555) 555-5555"
  
},
}
 
There are some really great benefits to having this kind of structure.
 
1.       
If the Organization domain name changes, then the Organization just produces a new revision of its Identity object (one
object)and sends it out to the communities it belongs to. Everyone who receives it know knows how to get the latest updates of objects – even objects created 3 years ago!
2.       
If the Organization’s domain name changes, there are no changes needed to any of the other Objects previously released
by the Organization (apart from the Identity one).
3.       
If the Organization decided to move from HTTPS based TAXII to AMQP or binary or carrier-pigeon based networking then
all that needs to be done is a new revision of the Identity object with a modified stix_resources section!
 
Simple!
 
Cheers
 

Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA   An FS-ISAC and DTCC Company
+61 (407) 203 206
terry@soltra.com
 

 


From:
cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Mark Davidson
Sent: Saturday, 23 January 2016 5:02 AM
To: Wunder, John A. < jwunder@mitre.org >; Foley, Alexander - GIS < alexander.foley@bankofamerica.com >; Jason Keirstead < Jason.Keirstead@ca.ibm.com >;
Jordan, Bret < bret.jordan@bluecoat.com >
Cc: John Anderson < janderson@soltra.com >; Trey Darley < trey@soltra.com >;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format


 


Is there anyone that this proposed structure doesn’t work for (even if you don’t agree with the field names)? I think this alleviates Jason’s concern of tying STIX
to a specific transport, and the “what do you expect?” is answered by the reference key (e.g., “taxii2”), assuming there is some degree of definition behind the key (and individual enclaves can use their own special sauce!).



{   "type" : "indicator" ,   "id" : "Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29" ,   "references" : { "taxii2" : " https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 " ,                  "amqp?" : "amqp://user:pass@host:10000/vhost#SomeOtherStuff" ,                  “sneakernet" : "Ask Mark (555) 555-5555" },   "producer" : "MarkDavidson" // Omit field for anonymity }

Thank you.


-Mark





From:
< cti-stix@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Friday, January 22, 2016 at 11:54 AM
To: "Foley, Alexander - GIS" < alexander.foley@bankofamerica.com >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Jordan, Bret" < bret.jordan@bluecoat.com >
Cc: John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Object ID format


 





+1


 


URLs tend to be fairly fragile in practice and I would rather have one, single, more complicated method that we can rely on rather than people trying to create
URL schemes that are persistent, having some object IDs resolvable and some not, and tying ourselves to access via a single URI (or maybe in some cases a URL) rather than a list of possible options.


 


John



 


From:
< cti-stix@lists.oasis-open.org > on behalf of "Foley, Alexander - GIS" < alexander.foley@bankofamerica.com >
Date: Friday, January 22, 2016 at 11:26 AM
To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Jordan, Bret" < bret.jordan@bluecoat.com >
Cc: John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Object ID format


 



I have another “back further” question – given the rate at which popular websites change permalinks, who realistically thinks that organizations
are going to do a good job at creating persistent unique identifiers and versioning them over time?  That’s a massive knowledge management problem that would rely on consolidated technology platforms that don’t yet exist.
 
STIX co-chairs, what’s the plan for gaining consensus on the object id?


 
Alex


 


From: cti-stix@lists.oasis-open.org
[ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Jason Keirstead
Sent: Friday, January 22, 2016 11:21 AM
To: Jordan, Bret
Cc: John Anderson; Trey Darley;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Object ID format


 
And to go back further.... I still am of the opinion that we can't codify this without TAXII.

So we have a URL in an ID.. now what? If anyone wants to make use of that, then they have to know what is expected if I issue a GET to that URL. Should it return a STIX document? A web page? A word document that is a threat report?

We have to codify this in the standard, otherwise there is no point to even having the field because everyone will put different things there. So now, we are codifying data sharing behavior over the network and STIX URL syntaxes, inside STIX, and not TAXII.


This proposal makes no sense to me as part of the ID because it is going down this path of tying STIX and TAXII together at the hip.

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

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


"Jordan,
Bret" ---01/22/2016 12:03:33 PM---Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cl

From: "Jordan, Bret" < bret.jordan@bluecoat.com >
To: John Anderson < janderson@soltra.com >
Cc: Trey Darley < trey@soltra.com >, " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Date: 01/22/2016 12:03 PM
Subject:
Re: [cti-stix] Object ID format
Sent by:
< cti-stix@lists.oasis-open.org >








Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cloud? For all of the banks on this list, do you plan on sticking STIX documents on your web server?
And making it so that the public can just surf to them?

I firmly believe that the vast majority, in the 99+% of STIX objects will NEVER be open to general web surfing.. So we are building a solution to a problem that does not exist.



Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Jan 22, 2016, at 07:43, John Anderson < janderson@soltra.com >
wrote:

Trey,
Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly "shifting the ground under our feet" by changing Resources.

URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object.

So, I'd like to think immutability and versioning are orthogonal to Identity.

What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's
proposal demonstrates.)

JSA
---------------------------------------------------------------------
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
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]







This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary
and subject to important terms and conditions available at
http://www.bankofamerica.com/emaildisclaimer . If you are not the intended recipient, please delete this message.

Terry, We already have this object, it is called the InformationSourceType and that is where all of this information should live.  Lets not recreate it.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Jan 22, 2016, at 23:08, Terry MacDonald < terry@soltra.com > wrote: Hi Mark,   Me unfortunately (just slightly). The problem that I have with direct references to where to get the data, is that it goes stale. As mentioned in my other email, companies are bought by other companies, domain names change, web servers and taxi servers move. So for those reasons, I think we need a way to allow the location of an organizations data repositories to change too.   Using the structure you proposed, if an organization did change its domain name, they would need to reissue revisions to all their objects to update the location of their data store. Or, they would need to ensure that there was a reverse proxy in front of their web services to ‘map’ the old location to the new location on the fly.  Both of these options have their problems. The first results in a large number of updates that need to be rebroadcast out to the various communities that the organization belongs to; the second results in additional infrastructure that the Organization needs to keep up to date.   I think your idea is excellent Mark, and with a little tweak could be even better….   Idea:   What if the data location wasn’t actually attached to the Indicator object itself, but instead was bound to the Identity of the producer of the STIX object?   An illustrative example….   If you have an Indicator object you want to share (and you want people to know where to get it), you would insert a stix_producer_ref field pointing to the Identity object of who made and published the STIX object:   {   type : indicator ,   id : Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 ,   stix_producer_ref : Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d , // Omit field for anonymity  ….. }   Then you have the Identity Object for the stix object creator – and that Identity contains a list of ways for consumers to get more information about STIX objects that this identity has produced:   }     type :   identity ,   id : Identity-f0efd87f-1509-492b-9aa9-343a6444ac1d ,   title :   Mark Davidson ,    stix_resources : {                    taxii2 :   https://example.com/taxii2   ,                    amqp? :   amqp://user:pass@host:10000/vhost ,                    “sneakernet :   Ask Mark (555) 555-5555      },   }   There are some really great benefits to having this kind of structure.   1.          If the Organization domain name changes, then the Organization just produces a new revision of its Identity object (one object)and sends it out to the communities it belongs to. Everyone who receives it know knows how to get the latest updates of objects – even objects created 3 years ago! 2.          If the Organization’s domain name changes, there are no changes needed to any of the other Objects previously released by the Organization (apart from the Identity one). 3.          If the Organization decided to move from HTTPS based TAXII to AMQP or binary or carrier-pigeon based networking then all that needs to be done is a new revision of the Identity object with a modified stix_resources section!   Simple!   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA   An FS-ISAC and DTCC Company +61 (407) 203 206   terry@soltra.com     From:   cti-stix@lists.oasis-open.org   [ mailto:cti-stix@lists.oasis-open.org ]   On Behalf Of   Mark Davidson Sent:   Saturday, 23 January 2016 5:02 AM To:   Wunder, John A. < jwunder@mitre.org >; Foley, Alexander - GIS < alexander.foley@bankofamerica.com >; Jason Keirstead < Jason.Keirstead@ca.ibm.com >; Jordan, Bret < bret.jordan@bluecoat.com > Cc:   John Anderson < janderson@soltra.com >; Trey Darley < trey@soltra.com >;   cti-stix@lists.oasis-open.org Subject:   Re: [cti-stix] Object ID format   Is there anyone that this proposed structure doesn’t work for (even if you don’t agree with the field names)? I think this alleviates Jason’s concern of tying STIX to a specific transport, and the “what do you expect?” is answered by the reference key (e.g., “taxii2”), assuming there is some degree of definition behind the key (and individual enclaves can use their own special sauce!). {   type : indicator ,   id : Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 ,   references : { taxii2 : https://example.com/taxii/collections/mycollection/indicators/Indicator-4e78f46f-a023-4e5f-bc24-71b3ca22ec29 ,                  amqp? : amqp://user:pass@host:10000/vhost#SomeOtherStuff ,                  “sneakernet : Ask Mark (555) 555-5555 },   producer : MarkDavidson // Omit field for anonymity } Thank you. -Mark From:   < cti-stix@lists.oasis-open.org > on behalf of Wunder, John A. < jwunder@mitre.org > Date:   Friday, January 22, 2016 at 11:54 AM To:   Foley, Alexander - GIS < alexander.foley@bankofamerica.com >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Jordan, Bret < bret.jordan@bluecoat.com > Cc:   John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject:   Re: [cti-stix] Object ID format   +1   URLs tend to be fairly fragile in practice and I would rather have one, single, more complicated method that we can rely on rather than people trying to create URL schemes that are persistent, having some object IDs resolvable and some not, and tying ourselves to access via a single URI (or maybe in some cases a URL) rather than a list of possible options.   John   From:   < cti-stix@lists.oasis-open.org > on behalf of Foley, Alexander - GIS < alexander.foley@bankofamerica.com > Date:   Friday, January 22, 2016 at 11:26 AM To:   Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Jordan, Bret < bret.jordan@bluecoat.com > Cc:   John Anderson < janderson@soltra.com >, Trey Darley < trey@soltra.com >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject:   RE: [cti-stix] Object ID format   I have another “back further” question – given the rate at which popular websites change permalinks, who realistically thinks that organizations are going to do a good job at creating persistent unique identifiers and versioning them over time?  That’s a massive knowledge management problem that would rely on consolidated technology platforms that don’t yet exist.   STIX co-chairs, what’s the plan for gaining consensus on the object id?   Alex   From: cti-stix@lists.oasis-open.org   [ mailto:cti-stix@lists.oasis-open.org ]   On Behalf Of   Jason Keirstead Sent:   Friday, January 22, 2016 11:21 AM To:   Jordan, Bret Cc:   John Anderson; Trey Darley;   cti-stix@lists.oasis-open.org Subject:   Re: [cti-stix] Object ID format   And to go back further.... I still am of the opinion that we can't codify this without TAXII. So we have a URL in an ID.. now what? If anyone wants to make use of that, then they have to know what is expected if I issue a GET to that URL. Should it return a STIX document? A web page? A word document that is a threat report? We have to codify this in the standard, otherwise there is no point to even having the field because everyone will put different things there. So now, we are codifying data sharing behavior over the network and STIX URL syntaxes, inside STIX, and not TAXII.   This proposal makes no sense to me as part of the ID because it is going down this path of tying STIX and TAXII together at the hip. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security     www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown   <image001.gif> Jordan, Bret ---01/22/2016 12:03:33 PM---Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cl From:   Jordan, Bret < bret.jordan@bluecoat.com > To:   John Anderson < janderson@soltra.com > Cc:   Trey Darley < trey@soltra.com >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Date:   01/22/2016 12:03 PM Subject:   Re: [cti-stix] Object ID format Sent by:   < cti-stix@lists.oasis-open.org > Do we honestly think people are going to publish STIX content on their web servers in their DMZ / Cloud? For all of the banks on this list, do you plan on sticking STIX documents on your web server? And making it so that the public can just surf to them? I firmly believe that the vast majority, in the 99+% of STIX objects will NEVER be open to general web surfing.. So we are building a solution to a problem that does not exist.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg. On Jan 22, 2016, at 07:43, John Anderson < janderson@soltra.com > wrote: Trey, Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly shifting the ground under our feet by changing Resources. URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object. So, I'd like to think immutability and versioning are orthogonal to Identity. What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's proposal demonstrates.) JSA --------------------------------------------------------------------- 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 [attachment signature.asc deleted by Jason Keirstead/CanEast/IBM]   This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at   http://www.bankofamerica.com/emaildisclaimer . If you are not the intended recipient, please delete this message. Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

Hi John, Companies are bought by other companies. Organizations rebrand. Groups replace and redesign networks. All of these real-world things affect where things are located and reachable in the Internet. I would still trust these companies, as what they are doing is normal behaviour - and yet they are still changing their Resources. 'Hard linking' the Object-IDs directly to any destination (i.e. using URLs) is a bad idea, as it means that that Object is tied to the location forever. If a company moves to a new network design and we use hard-linking, then the consumer is no longer able to ask for help, unless there is some kind of translation web proxy created that understands Object IDs. I prefer a 'look it up at the time' mechanism for resolving the actual 'real' location of Object IDs. If an ID is in the format [Object]-[UUID], and it links to an InformationSource Object, and that object has a domain name in it, then I will be able to look up the TAXII Domain Service record, and that can then tell me what the current latest (and valid) location is to get more information. In fact we could even include the TAXII server location in the InformationSource Object itself, and if our domain name changes then we can update the InformationSource Object and republish it out to the community. Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA  An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com  
Original Message----- From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of John Anderson Sent: Saturday, 23 January 2016 1:43 AM To: Trey Darley <trey@soltra.com>; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Re: Object ID format Trey, Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly "shifting the ground under our feet" by changing Resources. URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object. So, I'd like to think immutability and versioning are orthogonal to Identity. What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's proposal demonstrates.) JSA --------------------------------------------------------------------- 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

Along these lines, I also envision long-term having well known InformationSource objects.  Like once for a CERT or MITRE or major vendor XYZ. Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Jan 22, 2016, at 14:52, Terry MacDonald < terry@soltra.com > wrote: Hi John, Companies are bought by other companies. Organizations rebrand. Groups replace and redesign networks. All of these real-world things affect where things are located and reachable in the Internet. I would still trust these companies, as what they are doing is normal behaviour - and yet they are still changing their Resources. 'Hard linking' the Object-IDs directly to any destination (i.e. using URLs) is a bad idea, as it means that that Object is tied to the location forever. If a company moves to a new network design and we use hard-linking, then the consumer is no longer able to ask for help, unless there is some kind of translation web proxy created that understands Object IDs. I prefer a 'look it up at the time' mechanism for resolving the actual 'real' location of Object IDs. If an ID is in the format [Object]-[UUID], and it links to an InformationSource Object, and that object has a domain name in it, then I will be able to look up the TAXII Domain Service record, and that can then tell me what the current latest (and valid) location is to get more information. In fact we could even include the TAXII server location in the InformationSource Object itself, and if our domain name changes then we can update the InformationSource Object and republish it out to the community. Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA  An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com  
Original Message----- From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of John Anderson Sent: Saturday, 23 January 2016 1:43 AM To: Trey Darley < trey@soltra.com >; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Re: Object ID format Trey, Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly shifting the ground under our feet by changing Resources. URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object. So, I'd like to think immutability and versioning are orthogonal to Identity. What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's proposal demonstrates.) JSA --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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 Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

Agree - this is key and it is also needed for a proper AA system for threat intel. IE, this threat object is sourced from this InformationSource, and it is digitally signed within the InformationSource - so you know (a) it hasn't been altered, (b) it came from who you think it came from, (c) the person who sent it was authorized to sign it as coming from that source. You simply can't communicate all of this in a URL (well unless the URL is ridiculously long). - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown "Jordan, Bret" ---01/22/2016 09:29:11 PM---Along these lines, I also envision long-term having well known InformationSource objects. Like once From: "Jordan, Bret" <bret.jordan@bluecoat.com> To: Terry MacDonald <terry@soltra.com> Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 01/22/2016 09:29 PM Subject: Re: [cti-stix] Re: Object ID format Sent by: <cti-stix@lists.oasis-open.org> Along these lines, I also envision long-term having well known InformationSource objects. Like once for a CERT or MITRE or major vendor XYZ. Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." On Jan 22, 2016, at 14:52, Terry MacDonald < terry@soltra.com > wrote: Hi John, Companies are bought by other companies. Organizations rebrand. Groups replace and redesign networks. All of these real-world things affect where things are located and reachable in the Internet. I would still trust these companies, as what they are doing is normal behaviour - and yet they are still changing their Resources. 'Hard linking' the Object-IDs directly to any destination (i.e. using URLs) is a bad idea, as it means that that Object is tied to the location forever. If a company moves to a new network design and we use hard-linking, then the consumer is no longer able to ask for help, unless there is some kind of translation web proxy created that understands Object IDs. I prefer a 'look it up at the time' mechanism for resolving the actual 'real' location of Object IDs. If an ID is in the format [Object]-[UUID], and it links to an InformationSource Object, and that object has a domain name in it, then I will be able to look up the TAXII Domain Service record, and that can then tell me what the current latest (and valid) location is to get more information. In fact we could even include the TAXII server location in the InformationSource Object itself, and if our domain name changes then we can update the InformationSource Object and republish it out to the community. Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com
Original Message----- From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of John Anderson Sent: Saturday, 23 January 2016 1:43 AM To: Trey Darley < trey@soltra.com >; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Re: Object ID format Trey, Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly "shifting the ground under our feet" by changing Resources. URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object. So, I'd like to think immutability and versioning are orthogonal to Identity. What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's proposal demonstrates.) JSA --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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 [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]

Terry, True, content does disappear from the Internet sometimes. Sometimes that's a good thing. Other times, how does the web handle that? I can think of three ways: 1. Responsible redirects. (When the purchasing company cares about the content it's moving.) 2. Google. (When other people who link to the content care about its new location.) 3. Wayback machine. (When...?) I wonder how CTI is different from web documents. I mean: If the content is not worth the effort to maintain, why do I care if I can't find it anymore? (Also, keeping a local snapshot is perfectly valid. People mirror the web all the time.) JSA PS-After reading Mark's response, I'm probably beating a dead horse. But I want us to really think hard about why we can't just use the established web for CTI. ________________________________________ From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald <terry@soltra.com> Sent: Friday, January 22, 2016 4:52 PM To: cti-stix@lists.oasis-open.org Subject: RE: [cti-stix] Re: Object ID format Hi John, Companies are bought by other companies. Organizations rebrand. Groups replace and redesign networks. All of these real-world things affect where things are located and reachable in the Internet. I would still trust these companies, as what they are doing is normal behaviour - and yet they are still changing their Resources. 'Hard linking' the Object-IDs directly to any destination (i.e. using URLs) is a bad idea, as it means that that Object is tied to the location forever. If a company moves to a new network design and we use hard-linking, then the consumer is no longer able to ask for help, unless there is some kind of translation web proxy created that understands Object IDs. I prefer a 'look it up at the time' mechanism for resolving the actual 'real' location of Object IDs. If an ID is in the format [Object]-[UUID], and it links to an InformationSource Object, and that object has a domain name in it, then I will be able to look up the TAXII Domain Service record, and that can then tell me what the current latest (and valid) location is to get more information. In fact we could even include the TAXII server location in the InformationSource Object itself, and if our domain name changes then we can update the InformationSource Object and republish it out to the community. Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com
Original Message----- From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of John Anderson Sent: Saturday, 23 January 2016 1:43 AM To: Trey Darley <trey@soltra.com>; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Re: Object ID format Trey, Your concerns about immutability and versioning are still valid. It would be hard to trust a source if it is constantly "shifting the ground under our feet" by changing Resources. URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how UUID-as-ID-via-TAXII solves them, either. Someone can always hack their own database and change the content in an Object. So, I'd like to think immutability and versioning are orthogonal to Identity. What URL-as-ID brings to the table is this: I can always ATTEMPT to browse to a URL, without knowing anything more about scheme, namespace, and all that jazz. And that's the Big Win I'm going for. (Without it, we get a lot more complexity, as Mark Davidson's proposal demonstrates.) JSA --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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

The content may be relevant, current, and not at the URL published in the STIX document. For example, something could have a URI pointing to redcliffconsulting.com. Oops, that is mandiant.com. Oops, that is fireeye.com. So, the data might be important, available, but not at the same URI it lived at when it was published. That is why URI’s are either URL’s (with the location) and URN’s (just the name). I could see where we just specify STIX includes a URI, and the choice of a URL or URN is up to the sharing community. I could see large, long-lived communities standing up a URN directory resolver. I could see ad hoc and smaller communities leverage the ease of a URL. I.e., let’s have our cake and eat it too. Note this does not violate Eric’s Law™: pick one and only one way of doing something. The one and only one way is a URI. It just happens the URI can be a URN. > On Jan 24, 2016, at 9:35 PM, John Anderson <janderson@soltra.com> wrote: > > True, content does disappear from the Internet sometimes. Sometimes that's a good thing. Other times, how does the web handle that? I can think of three ways: > > 1. Responsible redirects. (When the purchasing company cares about the content it's moving.) > 2. Google. (When other people who link to the content care about its new location.) > 3. Wayback machine. (When...?) > > I wonder how CTI is different from web documents. I mean: If the content is not worth the effort to maintain, why do I care if I can't find it anymore? Attachment: smime.p7s Description: S/MIME cryptographic signature

On 22.01.2016 15:43:18, John Anderson wrote: > > URL-as-ID-over-HTTP doesn't solve those issues. I'm not sure how > UUID-as-ID-via-TAXII solves them, either. Someone can always hack > their own database and change the content in an Object. > Hi, John - This is where normative language in the spec comes into play. Of course the TC can't prevent somebody mucking about in their database to alter an object's content but as a TC we *can* say that compliant implementations *MUST* not do so. -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com -- "No matter how hard you push and no matter what the priority, you can't increase the speed of light." --RFC 1925 Attachment: signature.asc Description: PGP signature

I agree that “wholesale webification” likely does not make sense but being able to offer resolvable IDs for content to trusted parties and filtering what goes out based on trust and access permissions would be very powerful. It has potential value for rapid access to content, federated analysis, federated visualization, etc. sean On 1/21/16, 4:10 AM, "Trey Darley" <cti-stix@lists.oasis-open.org on behalf of trey@soltra.com> wrote: >On 21.01.2016 02:01:35, John Anderson wrote: >> >> What about actual URLs? (Not URIs [1].) Let's actually use http: and >> make our Resources resolvable via the Web. (And maybe even let >> Google index some of them!) >> > >Hey, John - > >Threat intel is less than worthless if your adversary knows what you >know. Wholesale webification of CTI is no panacea. > >-- >Cheers, >Trey >-- >Trey Darley >Senior Security Engineer >4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 >Soltra An FS-ISAC & DTCC Company >www.soltra.com >-- >"With sufficient thrust, pigs fly just fine. However, this is not >necessarily a good idea. It is hard to be sure where they are going to >land, and it could be dangerous sitting under them as they fly >overhead." --RFC 1925

On 21.01.2016 15:12:03, Barnum, Sean D. wrote: > ...but being able to offer resolvable IDs for content to trusted > parties and filtering what goes out based on trust and access > permissions would be very powerful. > I agree with you, Sean. I think this is a case of John and I talking past each other in (more-or-less) violent agreement. It's unfortunate that we didn't managed to run the object id question to the ground during the F2F and are hence chasing our respective tails on the mailing list. :-/ -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com -- "It is always something." --RFC 1925 Attachment: signature.asc Description: PGP signature