CTI STIX Subcommittee

The only other one I can think of is revisiting versioning. Last time we talked about the relationship object it came up. I would add that towards the end of this list though.









From: < cti-stix@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org >
Date: Wednesday, October 28, 2015 at 2:12 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0






All,




On the STIX SC call last week we talked about the issue of making immediate progress on STIX v2.0 while we work out prioritizing the full issues list and fleshing out use cases.

We proposed that we simply choose the first 2-3 issues to officially tackle based on list interest rather than any official “voting” and listed a few possible options asking for your opinions.

The list of “hot” issue options given was:


Sightings Relationships ID format Abstracting constructs (identity, victim, source and asset) In-line vs referencing of content Data Markings Other suggestions?


We did not really get back very many explicit opinions but the activity on the list since the meeting and architectural level considerations make the first two items on the list (Sightings and Relationships) fairly obvious choices for initial issues.




So, we would like to propose officially establishing that the following two issues are the active issues currently under consideration for STIX v2.0:



Abstract Sightings into an independent construct rather than embedded within Indicator  ( #306)


Abstract relationships as top-level constructs rather than embedded within other constructs  ( #291)


If anyone has any serious objections to this decision please let us know.

Hopefully we can continue the great discussions on these topics, going even deeper on the details, considering various options and implications and eventually reach some consensus and move on to other topics.

While the cti-stix email list is likely to continue as the primary venue for these discussions we encourage everyone to capture key thoughts, observations, opinions and proposals within the issue tracker as well as this will be the official record of our discourse
and where we will eventually be declaring our consensus.




If no strong objections are heard these issues will be the primary issue topics of discussion in relation to STIX v2.0 for the SC on the cti-stix list and elsewhere.

This does not mean that other issues cannot be raised or commented on if there is need but in the interests of focus and keeping up with list traffic we would like to encourage everyone as much as possible to focus on the active issues under consideration and
minimize other issue topics that are likely to distract from deliberative progress on these issues. This should be a pretty fundamental guideline for all issues as we go forward. If you have new issue topics you would like to raise or comments on existing
issue topics that are not under active consideration we encourage you to enter these in the issue trackers at any time.







Sean 

STIX SC Co-chair

Versioning(if different form ID Format) and Duplicates will definitely come up again.

-Marlon
 

From : Wunder, John A. [mailto:jwunder@mitre.org]

Sent : Wednesday, October 28, 2015 02:46 PM
To : Barnum, Sean D. <sbarnum@mitre.org>; cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org>

Subject : Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0

 



The only other one I can think of is revisiting versioning. Last time we talked about the relationship object it came up. I would add that towards the end of this list though.









From: < cti-stix@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org >
Date: Wednesday, October 28, 2015 at 2:12 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0






All,




On the STIX SC call last week we talked about the issue of making immediate progress on STIX v2.0 while we work out prioritizing the full issues list and fleshing out use cases.

We proposed that we simply choose the first 2-3 issues to officially tackle based on list interest rather than any official “voting” and listed a few possible options asking for your opinions.

The list of “hot” issue options given was:


Sightings Relationships ID format Abstracting constructs (identity, victim, source and asset) In-line vs referencing of content Data Markings Other suggestions?


We did not really get back very many explicit opinions but the activity on the list since the meeting and architectural level considerations make the first two items on the list (Sightings and Relationships) fairly obvious choices for initial issues.




So, we would like to propose officially establishing that the following two issues are the active issues currently under consideration for STIX v2.0:



Abstract Sightings into an independent construct rather than embedded within Indicator  ( #306)


Abstract relationships as top-level constructs rather than embedded within other constructs  ( #291)


If anyone has any serious objections to this decision please let us know.

Hopefully we can continue the great discussions on these topics, going even deeper on the details, considering various options and implications and eventually reach some consensus and move on to other topics.

While the cti-stix email list is likely to continue as the primary venue for these discussions we encourage everyone to capture key thoughts, observations, opinions and proposals within the issue tracker as well as this will be the official record of our discourse
and where we will eventually be declaring our consensus.




If no strong objections are heard these issues will be the primary issue topics of discussion in relation to STIX v2.0 for the SC on the cti-stix list and elsewhere.

This does not mean that other issues cannot be raised or commented on if there is need but in the interests of focus and keeping up with list traffic we would like to encourage everyone as much as possible to focus on the active issues under consideration and
minimize other issue topics that are likely to distract from deliberative progress on these issues. This should be a pretty fundamental guideline for all issues as we go forward. If you have new issue topics you would like to raise or comments on existing
issue topics that are not under active consideration we encourage you to enter these in the issue trackers at any time.







Sean 

STIX SC Co-chair

Does ID naming also cover ‘namespace mapping to domain name’? That’s another issue that has big implications for the use of relationship
objects, TAXII query and STIX requests/responses (which I need to do a big post about).
 
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 Taylor, Marlon
Sent: Thursday, 29 October 2015 5:50 AM
To: 'jwunder@mitre.org' <jwunder@mitre.org>; 'sbarnum@mitre.org' <sbarnum@mitre.org>; 'cti-stix@lists.oasis-open.org' <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0


 
Versioning(if different form ID Format) and Duplicates will definitely come up again.

-Marlon
 

From : Wunder, John A. [ mailto:jwunder@mitre.org ]

Sent : Wednesday, October 28, 2015 02:46 PM
To : Barnum, Sean D. < sbarnum@mitre.org >;
cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org >

Subject : Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0

 




The only other one I can think of is revisiting versioning. Last time we talked about the relationship object it came up. I would add that towards the end of this
list though.




 


From:
< cti-stix@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org >
Date: Wednesday, October 28, 2015 at 2:12 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0


 




All,


 


On the STIX SC call last week we talked about the issue of making immediate progress on STIX v2.0 while we work out prioritizing the full issues list and fleshing
out use cases.


We proposed that we simply choose the first 2-3 issues to officially tackle based on list interest rather than any official “voting” and listed a few possible options
asking for your opinions.


The list of “hot” issue options given was:



§  
Sightings

§  
Relationships

§  
ID format

§  
Abstracting constructs (identity, victim, source and asset)

§  
In-line vs referencing of content

§  
Data Markings

§  
Other suggestions?


We did not really get back very many explicit opinions but the activity on the list since the meeting and architectural level considerations make the first two
items on the list (Sightings and Relationships) fairly obvious choices for initial issues.


 


So, we would like to propose officially establishing that the following two issues are the active issues currently under consideration for STIX v2.0:


·         
Abstract Sightings into an independent construct
rather than embedded within Indicator  ( #306)

·         
Abstract relationships as top-level constructs
rather than embedded within other constructs  ( #291)

If anyone has any serious objections to this decision please let us know.


Hopefully we can continue the great discussions on these topics, going even deeper on the details, considering various options and implications and eventually reach
some consensus and move on to other topics.


While the cti-stix email list is likely to continue as the primary venue for these discussions we encourage everyone to capture key thoughts, observations, opinions
and proposals within the issue tracker as well as this will be the official record of our discourse and where we will eventually be declaring our consensus.


 


If no strong objections are heard these issues will be the primary issue topics of discussion in relation to STIX v2.0 for the SC on the cti-stix list and elsewhere.


This does not mean that other issues cannot be raised or commented on if there is need but in the interests of focus and keeping up with list traffic we would like
to encourage everyone as much as possible to focus on the active issues under consideration and minimize other issue topics that are likely to distract from deliberative progress on these issues. This should be a pretty fundamental guideline for all issues
as we go forward. If you have new issue topics you would like to raise or comments on existing issue topics that are not under active consideration we encourage you to enter these in the issue trackers at any time.


 


 


Sean 


STIX SC Co-chair

Terry, yes. Some keep that in mind ;p On Thursday, 29 October 2015, Terry MacDonald < terry@soltra.com > wrote: Does ID naming also cover ‘namespace mapping to domain name’? That’s another issue that has big implications for the use of relationship objects, TAXII query and STIX requests/responses (which I need to do a big post about).   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 Taylor, Marlon Sent: Thursday, 29 October 2015 5:50 AM To: ' jwunder@mitre.org ' < jwunder@mitre.org >; ' sbarnum@mitre.org ' < sbarnum@mitre.org >; ' cti-stix@lists.oasis-open.org ' < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   Versioning(if different form ID Format) and Duplicates will definitely come up again. -Marlon   From : Wunder, John A. [ mailto:jwunder@mitre.org ] Sent : Wednesday, October 28, 2015 02:46 PM To : Barnum, Sean D. < sbarnum@mitre.org >; cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject : Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   The only other one I can think of is revisiting versioning. Last time we talked about the relationship object it came up. I would add that towards the end of this list though.   From: < cti-stix@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org > Date: Wednesday, October 28, 2015 at 2:12 PM To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   All,   On the STIX SC call last week we talked about the issue of making immediate progress on STIX v2.0 while we work out prioritizing the full issues list and fleshing out use cases. We proposed that we simply choose the first 2-3 issues to officially tackle based on list interest rather than any official “voting” and listed a few possible options asking for your opinions. The list of “hot” issue options given was: §   Sightings §   Relationships §   ID format §   Abstracting constructs (identity, victim, source and asset) §   In-line vs referencing of content §   Data Markings §   Other suggestions? We did not really get back very many explicit opinions but the activity on the list since the meeting and architectural level considerations make the first two items on the list (Sightings and Relationships) fairly obvious choices for initial issues.   So, we would like to propose officially establishing that the following two issues are the active issues currently under consideration for STIX v2.0: ·          Abstract Sightings into an independent construct rather than embedded within Indicator  ( #306) ·          Abstract relationships as top-level constructs rather than embedded within other constructs  ( #291) If anyone has any serious objections to this decision please let us know. Hopefully we can continue the great discussions on these topics, going even deeper on the details, considering various options and implications and eventually reach some consensus and move on to other topics. While the cti-stix email list is likely to continue as the primary venue for these discussions we encourage everyone to capture key thoughts, observations, opinions and proposals within the issue tracker as well as this will be the official record of our discourse and where we will eventually be declaring our consensus.   If no strong objections are heard these issues will be the primary issue topics of discussion in relation to STIX v2.0 for the SC on the cti-stix list and elsewhere. This does not mean that other issues cannot be raised or commented on if there is need but in the interests of focus and keeping up with list traffic we would like to encourage everyone as much as possible to focus on the active issues under consideration and minimize other issue topics that are likely to distract from deliberative progress on these issues. This should be a pretty fundamental guideline for all issues as we go forward. If you have new issue topics you would like to raise or comments on existing issue topics that are not under active consideration we encourage you to enter these in the issue trackers at any time.     Sean  STIX SC Co-chair

Terry, I am not sure I understand your question. Could clarify for me?


sean









From: Terry MacDonald < terry@soltra.com >
Date: Wednesday, October 28, 2015 at 7:41 PM
To: "Taylor, Marlon" < Marlon.Taylor@hq.dhs.gov >, John Wunder < jwunder@mitre.org >, "Barnum, Sean D." < sbarnum@mitre.org >,
" cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0








Does ID naming also cover ‘namespace mapping to domain name’? That’s another issue that has big implications for the use of relationship objects,
TAXII query and STIX requests/responses (which I need to do a big post about).
 
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 Taylor, Marlon
Sent: Thursday, 29 October 2015 5:50 AM
To: 'jwunder@mitre.org ' < jwunder@mitre.org >;
'sbarnum@mitre.org ' < sbarnum@mitre.org >;
'cti-stix@lists.oasis-open.org ' < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0


 
Versioning(if different form ID Format) and Duplicates will definitely come up again.

-Marlon
 

From : Wunder, John A. [ mailto:jwunder@mitre.org ]

Sent : Wednesday, October 28, 2015 02:46 PM
To : Barnum, Sean D. < sbarnum@mitre.org >;
cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org >

Subject : Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0

 




The only other one I can think of is revisiting versioning. Last time we talked about the relationship object it came up. I would add that towards the end
of this list though.




 


From:
< cti-stix@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org >
Date: Wednesday, October 28, 2015 at 2:12 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0


 




All,


 


On the STIX SC call last week we talked about the issue of making immediate progress on STIX v2.0 while we work out prioritizing the full issues list and fleshing
out use cases.


We proposed that we simply choose the first 2-3 issues to officially tackle based on list interest rather than any official “voting” and listed a few possible
options asking for your opinions.


The list of “hot” issue options given was:



§  
Sightings

§  
Relationships

§  
ID format

§  
Abstracting constructs (identity, victim, source and asset)

§  
In-line vs referencing of content

§  
Data Markings

§  
Other suggestions?


We did not really get back very many explicit opinions but the activity on the list since the meeting and architectural level considerations make the first
two items on the list (Sightings and Relationships) fairly obvious choices for initial issues.


 


So, we would like to propose officially establishing that the following two issues are the active issues currently under consideration for STIX v2.0:


·         
Abstract Sightings into
an independent construct rather than embedded within Indicator  ( #306)

·         
Abstract relationships as top-level
constructs rather than embedded within other constructs  ( #291)

If anyone has any serious objections to this decision please let us know.


Hopefully we can continue the great discussions on these topics, going even deeper on the details, considering various options and implications and eventually
reach some consensus and move on to other topics.


While the cti-stix email list is likely to continue as the primary venue for these discussions we encourage everyone to capture key thoughts, observations,
opinions and proposals within the issue tracker as well as this will be the official record of our discourse and where we will eventually be declaring our consensus.


 


If no strong objections are heard these issues will be the primary issue topics of discussion in relation to STIX v2.0 for the SC on the cti-stix list and
elsewhere.


This does not mean that other issues cannot be raised or commented on if there is need but in the interests of focus and keeping up with list traffic we would
like to encourage everyone as much as possible to focus on the active issues under consideration and minimize other issue topics that are likely to distract from deliberative progress on these issues. This should be a pretty fundamental guideline for all issues
as we go forward. If you have new issue topics you would like to raise or comments on existing issue topics that are not under active consideration we encourage you to enter these in the issue trackers at any time.


 


 


Sean 


STIX SC Co-chair

I guess it is something like While/when considering 'refactoring' IDs, could we consider to provide as best practice (or enforce) the use of 'domain names' as part of the IDs as a factor of identification of the source/producer. E.g.: ID=microsoft.com-indicator-12345 Terry would correct me if I am wrong On Thursday, 29 October 2015, Barnum, Sean D. < sbarnum@mitre.org > wrote: Terry, I am not sure I understand your question. Could clarify for me? sean From: Terry MacDonald < terry@soltra.com > Date: Wednesday, October 28, 2015 at 7:41 PM To: "Taylor, Marlon" < Marlon.Taylor@hq.dhs.gov >, John Wunder < jwunder@mitre.org >, "Barnum, Sean D." < sbarnum@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0 Does ID naming also cover ‘namespace mapping to domain name’? That’s another issue that has big implications for the use of relationship objects, TAXII query and STIX requests/responses (which I need to do a big post about).   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 Taylor, Marlon Sent: Thursday, 29 October 2015 5:50 AM To: 'jwunder@mitre.org ' < jwunder@mitre.org >; 'sbarnum@mitre.org ' < sbarnum@mitre.org >; 'cti-stix@lists.oasis-open.org ' < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   Versioning(if different form ID Format) and Duplicates will definitely come up again. -Marlon   From : Wunder, John A. [ mailto:jwunder@mitre.org ] Sent : Wednesday, October 28, 2015 02:46 PM To : Barnum, Sean D. < sbarnum@mitre.org >; cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject : Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   The only other one I can think of is revisiting versioning. Last time we talked about the relationship object it came up. I would add that towards the end of this list though.   From: < cti-stix@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org > Date: Wednesday, October 28, 2015 at 2:12 PM To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   All,   On the STIX SC call last week we talked about the issue of making immediate progress on STIX v2.0 while we work out prioritizing the full issues list and fleshing out use cases. We proposed that we simply choose the first 2-3 issues to officially tackle based on list interest rather than any official “voting” and listed a few possible options asking for your opinions. The list of “hot” issue options given was: §   Sightings §   Relationships §   ID format §   Abstracting constructs (identity, victim, source and asset) §   In-line vs referencing of content §   Data Markings §   Other suggestions? We did not really get back very many explicit opinions but the activity on the list since the meeting and architectural level considerations make the first two items on the list (Sightings and Relationships) fairly obvious choices for initial issues.   So, we would like to propose officially establishing that the following two issues are the active issues currently under consideration for STIX v2.0: ·          Abstract Sightings into an independent construct rather than embedded within Indicator  ( #306) ·          Abstract relationships as top-level constructs rather than embedded within other constructs  ( #291) If anyone has any serious objections to this decision please let us know. Hopefully we can continue the great discussions on these topics, going even deeper on the details, considering various options and implications and eventually reach some consensus and move on to other topics. While the cti-stix email list is likely to continue as the primary venue for these discussions we encourage everyone to capture key thoughts, observations, opinions and proposals within the issue tracker as well as this will be the official record of our discourse and where we will eventually be declaring our consensus.   If no strong objections are heard these issues will be the primary issue topics of discussion in relation to STIX v2.0 for the SC on the cti-stix list and elsewhere. This does not mean that other issues cannot be raised or commented on if there is need but in the interests of focus and keeping up with list traffic we would like to encourage everyone as much as possible to focus on the active issues under consideration and minimize other issue topics that are likely to distract from deliberative progress on these issues. This should be a pretty fundamental guideline for all issues as we go forward. If you have new issue topics you would like to raise or comments on existing issue topics that are not under active consideration we encourage you to enter these in the issue trackers at any time.     Sean  STIX SC Co-chair

Ah. That makes sense. 


What I meant when I included “ID format” in the list of topics was that there have been community members who have complained about the use of Qualified Names as the STIX ID format and that discussion around this question and possible alternative options
could occur. Now that we have abstracted from just XSD it likely makes sense to look into whether there are other more preferable forms.


I think the key is just to try to support the basic capabilities we have in Qnames (the ability to specify some sort of sub-identifier for the producer of the ID and some sort of sub-identifier that is globally unique within the producer sub-identifier
context). 
I think the option that I heard being mentioned before was to look into URIs containing a domain name (and possibly path) as the producer sub-identifier and then the globally unique identifier (e.g., GUID/UUID) as either the end of the path or as a fragment.
I don’t recall any opinions being expressed on appropriate schemes to use or if that mattered.
I am not arguing for or against this approach but definitely think it should be part of any discussion around exploring new ID format options.


So, I guess the answer to Terry’s question is yes. ;-)


sean








From: Jerome Athias < athiasjerome@gmail.com >
Date: Thursday, October 29, 2015 at 1:35 AM
To: "Barnum, Sean D." < sbarnum@mitre.org >
Cc: Terry MacDonald < terry@soltra.com >, "Taylor, Marlon" < Marlon.Taylor@hq.dhs.gov >, John Wunder < jwunder@mitre.org >,
" cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0




I guess it is something like
While/when considering 'refactoring' IDs, could we consider to provide as best practice (or enforce) the use of 'domain names' as part of the IDs as a factor of identification of the source/producer.
E.g.:
ID=microsoft.com-indicator-12345


Terry would correct me if I am wrong

On Thursday, 29 October 2015, Barnum, Sean D. < sbarnum@mitre.org > wrote:




Terry, I am not sure I understand your question. Could clarify for me?


sean









From: Terry MacDonald < terry@soltra.com >
Date: Wednesday, October 28, 2015 at 7:41 PM
To: "Taylor, Marlon" < Marlon.Taylor@hq.dhs.gov >, John Wunder < jwunder@mitre.org >,
"Barnum, Sean D." < sbarnum@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0






Does ID naming also cover ‘namespace mapping to domain name’? That’s another issue that has big implications for the use of relationship objects,
TAXII query and STIX requests/responses (which I need to do a big post about).
 
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 Taylor, Marlon
Sent: Thursday, 29 October 2015 5:50 AM
To:
'jwunder@mitre.org ' < jwunder@mitre.org >;

'sbarnum@mitre.org ' < sbarnum@mitre.org >;

'cti-stix@lists.oasis-open.org ' < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0


 
Versioning(if different form ID Format) and Duplicates will definitely come up again.

-Marlon
 

From : Wunder, John A. [ mailto:jwunder@mitre.org ]

Sent : Wednesday, October 28, 2015 02:46 PM
To : Barnum, Sean D. < sbarnum@mitre.org >;

cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org >

Subject : Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0

 




The only other one I can think of is revisiting versioning. Last time we talked about the relationship object it came up. I would add that towards the end
of this list though.




 


From:
< cti-stix@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org >
Date: Wednesday, October 28, 2015 at 2:12 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0


 




All,


 


On the STIX SC call last week we talked about the issue of making immediate progress on STIX v2.0 while we work out prioritizing the full issues list and fleshing
out use cases.


We proposed that we simply choose the first 2-3 issues to officially tackle based on list interest rather than any official “voting” and listed a few possible
options asking for your opinions.


The list of “hot” issue options given was:


§  
Sightings
§  
Relationships
§  
ID format
§  
Abstracting constructs (identity, victim, source and asset)
§  
In-line vs referencing of content
§  
Data Markings
§  
Other suggestions?


We did not really get back very many explicit opinions but the activity on the list since the meeting and architectural level considerations make the first
two items on the list (Sightings and Relationships) fairly obvious choices for initial issues.


 


So, we would like to propose officially establishing that the following two issues are the active issues currently under consideration for STIX v2.0:


·         
Abstract Sightings into an independent construct
rather than embedded within Indicator  ( #306)

·         
Abstract relationships as top-level constructs rather
than embedded within other constructs  ( #291)

If anyone has any serious objections to this decision please let us know.


Hopefully we can continue the great discussions on these topics, going even deeper on the details, considering various options and implications and eventually
reach some consensus and move on to other topics.


While the cti-stix email list is likely to continue as the primary venue for these discussions we encourage everyone to capture key thoughts, observations,
opinions and proposals within the issue tracker as well as this will be the official record of our discourse and where we will eventually be declaring our consensus.


 


If no strong objections are heard these issues will be the primary issue topics of discussion in relation to STIX v2.0 for the SC on the cti-stix list and
elsewhere.


This does not mean that other issues cannot be raised or commented on if there is need but in the interests of focus and keeping up with list traffic we would
like to encourage everyone as much as possible to focus on the active issues under consideration and minimize other issue topics that are likely to distract from deliberative progress on these issues. This should be a pretty fundamental guideline for all issues
as we go forward. If you have new issue topics you would like to raise or comments on existing issue topics that are not under active consideration we encourage you to enter these in the issue trackers at any time.


 


 


Sean 


STIX SC Co-chair

Yes :D.
 

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

 


From: Barnum, Sean D. [mailto:sbarnum@mitre.org]

Sent: Thursday, 29 October 2015 4:49 PM
To: Jerome Athias <athiasjerome@gmail.com>
Cc: Terry MacDonald <terry@soltra.com>; Taylor, Marlon <Marlon.Taylor@hq.dhs.gov>; Wunder, John A. <jwunder@mitre.org>; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0


 


Ah. That makes sense. 


 


What I meant when I included “ID format” in the list of topics was that there have been community members who have complained about the use of Qualified Names as
the STIX ID format and that discussion around this question and possible alternative options could occur. Now that we have abstracted from just XSD it likely makes sense to look into whether there are other more preferable forms.


 


I think the key is just to try to support the basic capabilities we have in Qnames (the ability to specify some sort of sub-identifier for the producer of the ID
and some sort of sub-identifier that is globally unique within the producer sub-identifier context). 


I think the option that I heard being mentioned before was to look into URIs containing a domain name (and possibly path) as the producer sub-identifier and then
the globally unique identifier (e.g., GUID/UUID) as either the end of the path or as a fragment. I don’t recall any opinions being expressed on appropriate schemes to use or if that mattered.


I am not arguing for or against this approach but definitely think it should be part of any discussion around exploring new ID format options.


 


So, I guess the answer to Terry’s question is yes. ;-)


 


sean



 


From:
Jerome Athias < athiasjerome@gmail.com >
Date: Thursday, October 29, 2015 at 1:35 AM
To: "Barnum, Sean D." < sbarnum@mitre.org >
Cc: Terry MacDonald < terry@soltra.com >, "Taylor, Marlon" < Marlon.Taylor@hq.dhs.gov >, John Wunder < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0


 



I guess it is something like


While/when considering 'refactoring' IDs, could we consider to provide as best practice (or enforce) the use of 'domain names' as part of the IDs as a factor of
identification of the source/producer.


E.g.:


ID=microsoft.com-indicator-12345


 


Terry would correct me if I am wrong

On Thursday, 29 October 2015, Barnum, Sean D. < sbarnum@mitre.org > wrote:





Terry, I am not sure I understand your question. Could clarify for me?


 


sean




 


From:
Terry MacDonald < terry@soltra.com >
Date: Wednesday, October 28, 2015 at 7:41 PM
To: "Taylor, Marlon" < Marlon.Taylor@hq.dhs.gov >, John Wunder < jwunder@mitre.org >, "Barnum,
Sean D." < sbarnum@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0


 




Does ID naming also cover ‘namespace mapping to domain name’? That’s another issue that has big implications
for the use of relationship objects, TAXII query and STIX requests/responses (which I need to do a big post about).
 
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 Taylor, Marlon
Sent: Thursday, 29 October 2015 5:50 AM
To:
'jwunder@mitre.org ' < jwunder@mitre.org >;

'sbarnum@mitre.org ' < sbarnum@mitre.org >;

'cti-stix@lists.oasis-open.org ' < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0


 
Versioning(if different form ID Format) and Duplicates will definitely come up again.

-Marlon
 

From : Wunder,
John A. [ mailto:jwunder@mitre.org ]

Sent : Wednesday, October 28, 2015 02:46 PM
To : Barnum, Sean D. < sbarnum@mitre.org >;

cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org >

Subject : Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0

 




The only other one I can think of is revisiting versioning. Last time we talked about the relationship
object it came up. I would add that towards the end of this list though.




 


From:
< cti-stix@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org >
Date: Wednesday, October 28, 2015 at 2:12 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0


 




All,


 


On the STIX SC call last week we talked about the issue of making immediate progress on STIX v2.0 while
we work out prioritizing the full issues list and fleshing out use cases.


We proposed that we simply choose the first 2-3 issues to officially tackle based on list interest rather
than any official “voting” and listed a few possible options asking for your opinions.


The list of “hot” issue options given was:


§  
Sightings
§  
Relationships
§  
ID format
§  
Abstracting constructs (identity, victim, source and asset)
§  
In-line vs referencing of content
§  
Data Markings
§  
Other suggestions?


We did not really get back very many explicit opinions but the activity on the list since the meeting
and architectural level considerations make the first two items on the list (Sightings and Relationships) fairly obvious choices for initial issues.


 


So, we would like to propose officially establishing that the following two issues are the active issues
currently under consideration for STIX v2.0:


·         
Abstract Sightings into an independent construct rather than embedded within
Indicator  ( #306)

·         
Abstract relationships as top-level constructs rather than embedded within other
constructs  ( #291)

If anyone has any serious objections to this decision please let us know.


Hopefully we can continue the great discussions on these topics, going even deeper on the details, considering
various options and implications and eventually reach some consensus and move on to other topics.


While the cti-stix email list is likely to continue as the primary venue for these discussions we encourage
everyone to capture key thoughts, observations, opinions and proposals within the issue tracker as well as this will be the official record of our discourse and where we will eventually be declaring our consensus.


 


If no strong objections are heard these issues will be the primary issue topics of discussion in relation
to STIX v2.0 for the SC on the cti-stix list and elsewhere.


This does not mean that other issues cannot be raised or commented on if there is need but in the interests
of focus and keeping up with list traffic we would like to encourage everyone as much as possible to focus on the active issues under consideration and minimize other issue topics that are likely to distract from deliberative progress on these issues. This
should be a pretty fundamental guideline for all issues as we go forward. If you have new issue topics you would like to raise or comments on existing issue topics that are not under active consideration we encourage you to enter these in the issue trackers
at any time.


 


 


Sean 


STIX SC Co-chair

+1 <namespace>:<RFC 4122 UUID> seems to be what most people use in practice. - 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 Terry MacDonald ---2015/10/29 03:15:16 AM---Yes :D. Terry MacDonald From: Terry MacDonald <terry@soltra.com> To: "Barnum, Sean D." <sbarnum@mitre.org>, Jerome Athias <athiasjerome@gmail.com> Cc: "Taylor, Marlon" <Marlon.Taylor@hq.dhs.gov>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 2015/10/29 03:15 AM Subject: RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0 Sent by: <cti-stix@lists.oasis-open.org> Yes :D. Terry MacDonald Senior STIX Subject Matter Expert SOLTRA An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com From: Barnum, Sean D. [ mailto:sbarnum@mitre.org ] Sent: Thursday, 29 October 2015 4:49 PM To: Jerome Athias <athiasjerome@gmail.com> Cc: Terry MacDonald <terry@soltra.com>; Taylor, Marlon <Marlon.Taylor@hq.dhs.gov>; Wunder, John A. <jwunder@mitre.org>; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0 Ah. That makes sense. What I meant when I included “ID format” in the list of topics was that there have been community members who have complained about the use of Qualified Names as the STIX ID format and that discussion around this question and possible alternative options could occur. Now that we have abstracted from just XSD it likely makes sense to look into whether there are other more preferable forms. I think the key is just to try to support the basic capabilities we have in Qnames (the ability to specify some sort of sub-identifier for the producer of the ID and some sort of sub-identifier that is globally unique within the producer sub-identifier context). I think the option that I heard being mentioned before was to look into URIs containing a domain name (and possibly path) as the producer sub-identifier and then the globally unique identifier (e.g., GUID/UUID) as either the end of the path or as a fragment. I don’t recall any opinions being expressed on appropriate schemes to use or if that mattered. I am not arguing for or against this approach but definitely think it should be part of any discussion around exploring new ID format options. So, I guess the answer to Terry’s question is yes. ;-)

:-)




That is basically what we have currently for IDs.  A Q n ame is basically just a namespace
prefix and a unique identifier postfix.  The only specific difference with our current approach is that our suggested practices recommend adding a string descriptor of what type of object is being identified before the UUID in the postscript (e.g. Indicator- e061903a-7e42-11e5-8bcf-feff819cdc9f).
But this is not required and users would be able to use the exact form you describe.


If the form you show ends up being what people want then any migration would be pretty simple. We could just define this form ourselves and move away from
using the official XML-centric Q n ame specification for it.


Again,  I  am not arguing for any specific format at this point. Just observing
opinions. :-)


sean









From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Date: Thursday, October 29, 2015 at 9:23 AM
To: Terry MacDonald < terry@soltra.com >
Cc: "Barnum, Sean D." < sbarnum@mitre.org >, Jerome Athias < athiasjerome@gmail.com >, "Taylor, Marlon" < Marlon.Taylor@hq.dhs.gov >,
John Wunder < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0





+1

<namespace>:<RFC 4122 UUID> seems to be what most people use in practice.


-
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


Terry MacDonald ---2015/10/29 03:15:16 AM---Yes
:D. Terry MacDonald

From: Terry MacDonald < terry@soltra.com >
To: "Barnum, Sean D." < sbarnum@mitre.org >, Jerome Athias < athiasjerome@gmail.com >
Cc: "Taylor, Marlon" < Marlon.Taylor@hq.dhs.gov >, "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Date: 2015/10/29 03:15 AM
Subject: RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0
Sent by: < cti-stix@lists.oasis-open.org >





Yes :D.

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


From: Barnum, Sean D. [ mailto:sbarnum@mitre.org ]

Sent: Thursday, 29 October 2015 4:49 PM
To: Jerome Athias < athiasjerome@gmail.com >
Cc: Terry MacDonald < terry@soltra.com >; Taylor, Marlon < Marlon.Taylor@hq.dhs.gov >; Wunder, John A. < jwunder@mitre.org >;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0

Ah. That makes sense.

What I meant when I included “ID format” in the list of topics was that there have been community members who have complained about the use of Qualified Names as the STIX ID format and that discussion around this question and possible alternative
options could occur. Now that we have abstracted from just XSD it likely makes sense to look into whether there are other more preferable forms.

I think the key is just to try to support the basic capabilities we have in Qnames (the ability to specify some sort of sub-identifier for the producer of the ID and some sort of sub-identifier that is globally unique within the producer
sub-identifier context).
I think the option that I heard being mentioned before was to look into URIs containing a domain name (and possibly path) as the producer sub-identifier and then the globally unique identifier (e.g., GUID/UUID) as either the end of the
path or as a fragment. I don’t recall any opinions being expressed on appropriate schemes to use or if that mattered.
I am not arguing for or against this approach but definitely think it should be part of any discussion around exploring new ID format options.

So, I guess the answer to Terry’s question is yes. ;-)

+1 Sent from my Commodore 64 On Oct 29, 2015, at 6:32 AM, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: +1 <namespace>:<RFC 4122 UUID> seems to be what most people use in practice. - 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 Terry MacDonald ---2015/10/29 03:15:16 AM---Yes :D. Terry MacDonald From: Terry MacDonald < terry@soltra.com > To: "Barnum, Sean D." < sbarnum@mitre.org >, Jerome Athias < athiasjerome@gmail.com > Cc: "Taylor, Marlon" < Marlon.Taylor@hq.dhs.gov >, "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Date: 2015/10/29 03:15 AM Subject: RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0 Sent by: < cti-stix@lists.oasis-open.org > Yes :D. Terry MacDonald Senior STIX Subject Matter Expert SOLTRA An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com From: Barnum, Sean D. [ mailto:sbarnum@mitre.org ] Sent: Thursday, 29 October 2015 4:49 PM To: Jerome Athias < athiasjerome@gmail.com > Cc: Terry MacDonald < terry@soltra.com >; Taylor, Marlon < Marlon.Taylor@hq.dhs.gov >; Wunder, John A. < jwunder@mitre.org >; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0 Ah. That makes sense. What I meant when I included “ID format” in the list of topics was that there have been community members who have complained about the use of Qualified Names as the STIX ID format and that discussion around this question and possible alternative options could occur. Now that we have abstracted from just XSD it likely makes sense to look into whether there are other more preferable forms. I think the key is just to try to support the basic capabilities we have in Qnames (the ability to specify some sort of sub-identifier for the producer of the ID and some sort of sub-identifier that is globally unique within the producer sub-identifier context). I think the option that I heard being mentioned before was to look into URIs containing a domain name (and possibly path) as the producer sub-identifier and then the globally unique identifier (e.g., GUID/UUID) as either the end of the path or as a fragment. I don’t recall any opinions being expressed on appropriate schemes to use or if that mattered. I am not arguing for or against this approach but definitely think it should be part of any discussion around exploring new ID format options. So, I guess the answer to Terry’s question is yes. ;-)

Let's just make sure we do not build an ID system that is so vast that it can enumerate every atom in the known universe.   Bret  Sent from my Commodore 64 On Oct 28, 2015, at 10:48 PM, Barnum, Sean D. < sbarnum@mitre.org > wrote: Ah. That makes sense.  What I meant when I included “ID format” in the list of topics was that there have been community members who have complained about the use of Qualified Names as the STIX ID format and that discussion around this question and possible alternative options could occur. Now that we have abstracted from just XSD it likely makes sense to look into whether there are other more preferable forms. I think the key is just to try to support the basic capabilities we have in Qnames (the ability to specify some sort of sub-identifier for the producer of the ID and some sort of sub-identifier that is globally unique within the producer sub-identifier context).  I think the option that I heard being mentioned before was to look into URIs containing a domain name (and possibly path) as the producer sub-identifier and then the globally unique identifier (e.g., GUID/UUID) as either the end of the path or as a fragment. I don’t recall any opinions being expressed on appropriate schemes to use or if that mattered. I am not arguing for or against this approach but definitely think it should be part of any discussion around exploring new ID format options. So, I guess the answer to Terry’s question is yes. ;-) sean From: Jerome Athias < athiasjerome@gmail.com > Date: Thursday, October 29, 2015 at 1:35 AM To: "Barnum, Sean D." < sbarnum@mitre.org > Cc: Terry MacDonald < terry@soltra.com >, "Taylor, Marlon" < Marlon.Taylor@hq.dhs.gov >, John Wunder < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0 I guess it is something like While/when considering 'refactoring' IDs, could we consider to provide as best practice (or enforce) the use of 'domain names' as part of the IDs as a factor of identification of the source/producer. E.g.: ID= microsoft.com -indicator-12345 Terry would correct me if I am wrong On Thursday, 29 October 2015, Barnum, Sean D. < sbarnum@mitre.org > wrote: Terry, I am not sure I understand your question. Could clarify for me? sean From: Terry MacDonald < terry@soltra.com > Date: Wednesday, October 28, 2015 at 7:41 PM To: "Taylor, Marlon" < Marlon.Taylor@hq.dhs.gov >, John Wunder < jwunder@mitre.org >, "Barnum, Sean D." < sbarnum@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0 Does ID naming also cover ‘namespace mapping to domain name’? That’s another issue that has big implications for the use of relationship objects, TAXII query and STIX requests/responses (which I need to do a big post about).   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 Taylor, Marlon Sent: Thursday, 29 October 2015 5:50 AM To: 'jwunder@mitre.org ' < jwunder@mitre.org >; 'sbarnum@mitre.org ' < sbarnum@mitre.org >; 'cti-stix@lists.oasis-open.org ' < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   Versioning(if different form ID Format) and Duplicates will definitely come up again. -Marlon   From : Wunder, John A. [ mailto:jwunder@mitre.org ] Sent : Wednesday, October 28, 2015 02:46 PM To : Barnum, Sean D. < sbarnum@mitre.org >; cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject : Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   The only other one I can think of is revisiting versioning. Last time we talked about the relationship object it came up. I would add that towards the end of this list though.   From: < cti-stix@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org > Date: Wednesday, October 28, 2015 at 2:12 PM To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   All,   On the STIX SC call last week we talked about the issue of making immediate progress on STIX v2.0 while we work out prioritizing the full issues list and fleshing out use cases. We proposed that we simply choose the first 2-3 issues to officially tackle based on list interest rather than any official “voting” and listed a few possible options asking for your opinions. The list of “hot” issue options given was: §   Sightings §   Relationships §   ID format §   Abstracting constructs (identity, victim, source and asset) §   In-line vs referencing of content §   Data Markings §   Other suggestions? We did not really get back very many explicit opinions but the activity on the list since the meeting and architectural level considerations make the first two items on the list (Sightings and Relationships) fairly obvious choices for initial issues.   So, we would like to propose officially establishing that the following two issues are the active issues currently under consideration for STIX v2.0: ·          Abstract Sightings into an independent construct rather than embedded within Indicator  ( #306) ·          Abstract relationships as top-level constructs rather than embedded within other constructs  ( #291) If anyone has any serious objections to this decision please let us know. Hopefully we can continue the great discussions on these topics, going even deeper on the details, considering various options and implications and eventually reach some consensus and move on to other topics. While the cti-stix email list is likely to continue as the primary venue for these discussions we encourage everyone to capture key thoughts, observations, opinions and proposals within the issue tracker as well as this will be the official record of our discourse and where we will eventually be declaring our consensus.   If no strong objections are heard these issues will be the primary issue topics of discussion in relation to STIX v2.0 for the SC on the cti-stix list and elsewhere. This does not mean that other issues cannot be raised or commented on if there is need but in the interests of focus and keeping up with list traffic we would like to encourage everyone as much as possible to focus on the active issues under consideration and minimize other issue topics that are likely to distract from deliberative progress on these issues. This should be a pretty fundamental guideline for all issues as we go forward. If you have new issue topics you would like to raise or comments on existing issue topics that are not under active consideration we encourage you to enter these in the issue trackers at any time.     Sean  STIX SC Co-chair

If want the ability to dereference arbitrary STIX IDs (for use in accessing some kind of repository, let’s say), then I think requiring a rule whereby STIX IDs can be turned into a URL could be a good requirement (Note: URLs as IDs would satisfy this requirement). While there is a concept for idref today, I personally haven’t seen an implementation that dereferences STIX IDs outside of the document containing the idref.   Thank you. -Mark   PS, a notional example: <stix:Indicator idref=”https://example.org/stix121/indicators/123”/>   From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jordan, Bret Sent: Thursday, October 29, 2015 1:03 PM To: Barnum, Sean D. <sbarnum@mitre.org> Cc: Jerome Athias <athiasjerome@gmail.com>; Terry MacDonald <terry@soltra.com>; Taylor, Marlon <Marlon.Taylor@hq.dhs.gov>; Wunder, John A. <jwunder@mitre.org>; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   Let's just make sure we do not build an ID system that is so vast that it can enumerate every atom in the known universe.     Bret  Sent from my Commodore 64 On Oct 28, 2015, at 10:48 PM, Barnum, Sean D. < sbarnum@mitre.org > wrote: Ah. That makes sense.    What I meant when I included “ID format” in the list of topics was that there have been community members who have complained about the use of Qualified Names as the STIX ID format and that discussion around this question and possible alternative options could occur. Now that we have abstracted from just XSD it likely makes sense to look into whether there are other more preferable forms.   I think the key is just to try to support the basic capabilities we have in Qnames (the ability to specify some sort of sub-identifier for the producer of the ID and some sort of sub-identifier that is globally unique within the producer sub-identifier context).  I think the option that I heard being mentioned before was to look into URIs containing a domain name (and possibly path) as the producer sub-identifier and then the globally unique identifier (e.g., GUID/UUID) as either the end of the path or as a fragment. I don’t recall any opinions being expressed on appropriate schemes to use or if that mattered. I am not arguing for or against this approach but definitely think it should be part of any discussion around exploring new ID format options.   So, I guess the answer to Terry’s question is yes. ;-)   sean   From: Jerome Athias < athiasjerome@gmail.com > Date: Thursday, October 29, 2015 at 1:35 AM To: "Barnum, Sean D." < sbarnum@mitre.org > Cc: Terry MacDonald < terry@soltra.com >, "Taylor, Marlon" < Marlon.Taylor@hq.dhs.gov >, John Wunder < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   I guess it is something like While/when considering 'refactoring' IDs, could we consider to provide as best practice (or enforce) the use of 'domain names' as part of the IDs as a factor of identification of the source/producer. E.g.: ID= microsoft.com -indicator-12345   Terry would correct me if I am wrong On Thursday, 29 October 2015, Barnum, Sean D. < sbarnum@mitre.org > wrote: Terry, I am not sure I understand your question. Could clarify for me?   sean   From: Terry MacDonald < terry@soltra.com > Date: Wednesday, October 28, 2015 at 7:41 PM To: "Taylor, Marlon" < Marlon.Taylor@hq.dhs.gov >, John Wunder < jwunder@mitre.org >, "Barnum, Sean D." < sbarnum@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   Does ID naming also cover ‘namespace mapping to domain name’? That’s another issue that has big implications for the use of relationship objects, TAXII query and STIX requests/responses (which I need to do a big post about).   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 Taylor, Marlon Sent: Thursday, 29 October 2015 5:50 AM To: 'jwunder@mitre.org ' < jwunder@mitre.org >; 'sbarnum@mitre.org ' < sbarnum@mitre.org >; 'cti-stix@lists.oasis-open.org ' < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   Versioning(if different form ID Format) and Duplicates will definitely come up again. -Marlon   From : Wunder, John A. [ mailto:jwunder@mitre.org ] Sent : Wednesday, October 28, 2015 02:46 PM To : Barnum, Sean D. < sbarnum@mitre.org >; cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject : Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   The only other one I can think of is revisiting versioning. Last time we talked about the relationship object it came up. I would add that towards the end of this list though.   From: < cti-stix@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org > Date: Wednesday, October 28, 2015 at 2:12 PM To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   All,   On the STIX SC call last week we talked about the issue of making immediate progress on STIX v2.0 while we work out prioritizing the full issues list and fleshing out use cases. We proposed that we simply choose the first 2-3 issues to officially tackle based on list interest rather than any official “voting” and listed a few possible options asking for your opinions. The list of “hot” issue options given was: §   Sightings §   Relationships §   ID format §   Abstracting constructs (identity, victim, source and asset) §   In-line vs referencing of content §   Data Markings §   Other suggestions? We did not really get back very many explicit opinions but the activity on the list since the meeting and architectural level considerations make the first two items on the list (Sightings and Relationships) fairly obvious choices for initial issues.   So, we would like to propose officially establishing that the following two issues are the active issues currently under consideration for STIX v2.0: ·          Abstract Sightings into an independent construct rather than embedded within Indicator  ( #306) ·          Abstract relationships as top-level constructs rather than embedded within other constructs  ( #291) If anyone has any serious objections to this decision please let us know. Hopefully we can continue the great discussions on these topics, going even deeper on the details, considering various options and implications and eventually reach some consensus and move on to other topics. While the cti-stix email list is likely to continue as the primary venue for these discussions we encourage everyone to capture key thoughts, observations, opinions and proposals within the issue tracker as well as this will be the official record of our discourse and where we will eventually be declaring our consensus.   If no strong objections are heard these issues will be the primary issue topics of discussion in relation to STIX v2.0 for the SC on the cti-stix list and elsewhere. This does not mean that other issues cannot be raised or commented on if there is need but in the interests of focus and keeping up with list traffic we would like to encourage everyone as much as possible to focus on the active issues under consideration and minimize other issue topics that are likely to distract from deliberative progress on these issues. This should be a pretty fundamental guideline for all issues as we go forward. If you have new issue topics you would like to raise or comments on existing issue topics that are not under active consideration we encourage you to enter these in the issue trackers at any time.     Sean  STIX SC Co-chair

I could see the ID in URL format being just an entry points in to a RESTful API location on a TAXII server.   So if a TAXII server has two core concepts (elements of the RESTful API): 1) Channel Communications 2) Data Storage / Query  Then it is possible that IDs could easily fall in to the Data Storage / Query portion of the TAXII 2.0 RESTful API.  If it is decided that something like this is desirable, then we can take up the task in the TAXII SC on what the URLs / REST entry points need to look like.  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 Oct 29, 2015, at 12:05, Davidson II, Mark S < mdavidson@MITRE.ORG > wrote: If want the ability to dereference arbitrary STIX IDs (for use in accessing some kind of repository, let’s say), then I think requiring a rule whereby STIX IDs can be turned into a URL could be a good requirement (Note: URLs as IDs would satisfy this requirement). While there is a concept for idref today, I personally haven’t seen an implementation that dereferences STIX IDs outside of the document containing the idref.   Thank you. -Mark   PS, a notional example: <stix:Indicator idref=” https://example.org/stix121/indicators/123”/ >   From:   cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]   On Behalf Of   Jordan, Bret Sent:   Thursday, October 29, 2015 1:03 PM To:   Barnum, Sean D. < sbarnum@mitre.org > Cc:   Jerome Athias < athiasjerome@gmail.com >; Terry MacDonald < terry@soltra.com >; Taylor, Marlon < Marlon.Taylor@hq.dhs.gov >; Wunder, John A. < jwunder@mitre.org >; cti-stix@lists.oasis-open.org Subject:   Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   Let's just make sure we do not build an ID system that is so vast that it can enumerate every atom in the known universe.     Bret  Sent from my Commodore 64 On Oct 28, 2015, at 10:48 PM, Barnum, Sean D. < sbarnum@mitre.org > wrote: Ah. That makes sense.    What I meant when I included “ID format” in the list of topics was that there have been community members who have complained about the use of Qualified Names as the STIX ID format and that discussion around this question and possible alternative options could occur. Now that we have abstracted from just XSD it likely makes sense to look into whether there are other more preferable forms.   I think the key is just to try to support the basic capabilities we have in Qnames (the ability to specify some sort of sub-identifier for the producer of the ID and some sort of sub-identifier that is globally unique within the producer sub-identifier context).  I think the option that I heard being mentioned before was to look into URIs containing a domain name (and possibly path) as the producer sub-identifier and then the globally unique identifier (e.g., GUID/UUID) as either the end of the path or as a fragment. I don’t recall any opinions being expressed on appropriate schemes to use or if that mattered. I am not arguing for or against this approach but definitely think it should be part of any discussion around exploring new ID format options.   So, I guess the answer to Terry’s question is yes. ;-)   sean   From:   Jerome Athias < athiasjerome@gmail.com > Date:   Thursday, October 29, 2015 at 1:35 AM To:   Barnum, Sean D. < sbarnum@mitre.org > Cc:   Terry MacDonald < terry@soltra.com >, Taylor, Marlon < Marlon.Taylor@hq.dhs.gov >, John Wunder < jwunder@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject:   Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   I guess it is something like   While/when considering 'refactoring' IDs, could we consider to provide as best practice (or enforce) the use of 'domain names' as part of the IDs as a factor of identification of the source/producer. E.g.: ID= microsoft.com -indicator-12345   Terry would correct me if I am wrong On Thursday, 29 October 2015, Barnum, Sean D. < sbarnum@mitre.org > wrote: Terry, I am not sure I understand your question. Could clarify for me?   sean   From:   Terry MacDonald < terry@soltra.com > Date:   Wednesday, October 28, 2015 at 7:41 PM To:   Taylor, Marlon < Marlon.Taylor@hq.dhs.gov >, John Wunder < jwunder@mitre.org >, Barnum, Sean D. < sbarnum@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject:   RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   Does ID naming also cover ‘namespace mapping to domain name’? That’s another issue that has big implications for the use of relationship objects, TAXII query and STIX requests/responses (which I need to do a big post about).   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   Taylor, Marlon Sent:   Thursday, 29 October 2015 5:50 AM To:   'jwunder@mitre.org ' < jwunder@mitre.org >;   'sbarnum@mitre.org ' < sbarnum@mitre.org >;   'cti-stix@lists.oasis-open.org ' < cti-stix@lists.oasis-open.org > Subject:   Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   Versioning(if different form ID Format) and Duplicates will definitely come up again. -Marlon   From : Wunder, John A. [ mailto:jwunder@mitre.org ]   Sent : Wednesday, October 28, 2015 02:46 PM To : Barnum, Sean D. < sbarnum@mitre.org >;   cti-stix@lists.oasis-open.org   < cti-stix@lists.oasis-open.org >   Subject : Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0     The only other one I can think of is revisiting versioning. Last time we talked about the relationship object it came up. I would add that towards the end of this list though.   From:   < cti-stix@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org > Date:   Wednesday, October 28, 2015 at 2:12 PM To:   cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject:   [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   All,   On the STIX SC call last week we talked about the issue of making immediate progress on STIX v2.0 while we work out prioritizing the full issues list and fleshing out use cases. We proposed that we simply choose the first 2-3 issues to officially tackle based on list interest rather than any official “voting” and listed a few possible options asking for your opinions. The list of “hot” issue options given was: §     Sightings §     Relationships §     ID format §     Abstracting constructs (identity, victim, source and asset) §     In-line vs referencing of content §     Data Markings §     Other suggestions? We did not really get back very many explicit opinions but the activity on the list since the meeting and architectural level considerations make the first two items on the list (Sightings and Relationships) fairly obvious choices for initial issues.   So, we would like to propose officially establishing that the following two issues are the active issues currently under consideration for STIX v2.0: ·            Abstract Sightings into an independent construct rather than embedded within Indicator  ( #306) ·            Abstract relationships as top-level constructs rather than embedded within other constructs  ( #291) If anyone has any serious objections to this decision please let us know. Hopefully we can continue the great discussions on these topics, going even deeper on the details, considering various options and implications and eventually reach some consensus and move on to other topics. While the cti-stix email list is likely to continue as the primary venue for these discussions we encourage everyone to capture key thoughts, observations, opinions and proposals within the issue tracker as well as this will be the official record of our discourse and where we will eventually be declaring our consensus.   If no strong objections are heard these issues will be the primary issue topics of discussion in relation to STIX v2.0 for the SC on the cti-stix list and elsewhere. This does not mean that other issues cannot be raised or commented on if there is need but in the interests of focus and keeping up with list traffic we would like to encourage everyone as much as possible to focus on the active issues under consideration and minimize other issue topics that are likely to distract from deliberative progress on these issues. This should be a pretty fundamental guideline for all issues as we go forward. If you have new issue topics you would like to raise or comments on existing issue topics that are not under active consideration we encourage you to enter these in the issue trackers at any time.     Sean  STIX SC Co-chair Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

On 29.10.2015 20:49:30, Jordan, Bret wrote: > I could see the ID in URL format being just an entry points in to a > RESTful API location on a TAXII server. So if a TAXII server has two > core concepts (elements of the RESTful API): > > 1) Channel Communications > 2) Data Storage / Query > > Then it is possible that IDs could easily fall in to the Data > Storage / Query portion of the TAXII 2.0 RESTful API. If it is > decided that something like this is desirable, then we can take up > the task in the TAXII SC on what the URLs / REST entry points need > to look like. > I like this approach on several levels but it does rely on the implementer to ensure the immutability of the object referenced by the URL, doesn't it? -- 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 like this approach on several levels but it does rely on the > implementer to ensure the immutability of the object referenced by the > URL, doesn't it? My opinion would be no. Just like any web resource, the object identified by a particular URL could change over time (e.g., same ID, new version). That said, we could make immutability a rule if we thought it was beneficial. Were you thinking immutability would be a positive or a negative? Thank you. -Mark
Original Message----- From: Trey Darley [ mailto:trey@soltra.com ] Sent: Friday, October 30, 2015 5:29 AM To: Jordan, Bret <bret.jordan@bluecoat.com> Cc: Davidson II, Mark S <mdavidson@mitre.org>; Barnum, Sean D. <sbarnum@mitre.org>; Jerome Athias <athiasjerome@gmail.com>; Terry MacDonald <terry@soltra.com>; Taylor, Marlon <Marlon.Taylor@hq.dhs.gov>; Wunder, John A. <jwunder@mitre.org>; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0 On 29.10.2015 20:49:30, Jordan, Bret wrote: > I could see the ID in URL format being just an entry points in to a > RESTful API location on a TAXII server. So if a TAXII server has two > core concepts (elements of the RESTful API): > > 1) Channel Communications > 2) Data Storage / Query > > Then it is possible that IDs could easily fall in to the Data > Storage / Query portion of the TAXII 2.0 RESTful API. If it is > decided that something like this is desirable, then we can take up > the task in the TAXII SC on what the URLs / REST entry points need > to look like. > I like this approach on several levels but it does rely on the implementer to ensure the immutability of the object referenced by the URL, doesn't it? -- 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

On 30.10.2015 12:01:48, Davidson II, Mark S wrote: > > I like this approach on several levels but it does rely on the > > implementer to ensure the immutability of the object referenced by the > > URL, doesn't it? > > My opinion would be no. Just like any web resource, the object > identified by a particular URL could change over time (e.g., same > ID, new version). That said, we could make immutability a rule if we > thought it was beneficial. Were you thinking immutability would be a > positive or a negative? > For the viewing audience at home, Mark and I spent some time brainstorming around this issue over the past week. Here's my best attempt to summarize our conclusions. [Note that the following discussion assumes a REST-based TAXII Query API.] Immutability of objects under a URL-based object id scheme ========================================================== * If we move to using URLs as object ids, the underlying *data* a URL-based object id refers to *MUST* be treated as immutable. Here's why: * Let's take a strawman Indicator. Currently, the object id would be something like: example.org:indicator-14adf303-bd57-4dad-bf84-4ba8e8ef175c * If we move to URLs, the object id would be something like: taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175c * Now, why should the object behind the URL be immutable? Let's say I'm at Org A and I generate a Report object that links to the Org B Indicator (above). I'm making an direct assertion regarding that *particular* Indicator version. Now, if Org B goes and publishes a revision of the original Indicator *under the same URL*, it creates a problem for Org A. Do we still support our original assertion from our Report, given that Org B are effectively shifting the ground under our feet? Maybe, who knows? Definitely problematic, QED these things should be immutable. Implications for object versioning ================================== * Object versioning has long been a painful subject. Mark and I came up with an interesting approach. (Again, assuming a REST-based TAXII Query API.) * One can envisage a REST-based approach where I can refer to an object like this: taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175c/latest/ ...and get the latest revision of the object. * Additionally, one can envisage a REST-based approach where I can refer to an object like this: taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175c/history/ ...and get back a JSON blob something like this: [{'version': 0, 'object_id': 'taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175c', 'changelog': 'initial publication of indicator'}, {'version': 1, 'object_id': 'taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175d', 'changelog': 'typo fix'}, {'version': 2, 'object_id': 'taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175e', 'changelog': 'revoking indicator, this was actually innocuous'}] * This struck us as an intriguing approach. Curious to hear your thoughts. -- 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 -- "There are only two hard things in Computer Science: cache invalidation and naming things." --Phil Karlton Attachment: signature.asc Description: PGP signature

I like that idea. 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 Nov 4, 2015, at 03:52, Trey Darley < trey@SOLTRA.COM > wrote: On 30.10.2015 12:01:48, Davidson II, Mark S wrote: I like this approach on several levels but it does rely on the implementer to ensure the immutability of the object referenced by the URL, doesn't it? My opinion would be no. Just like any web resource, the object identified by a particular URL could change over time (e.g., same ID, new version). That said, we could make immutability a rule if we thought it was beneficial. Were you thinking immutability would be a positive or a negative? For the viewing audience at home, Mark and I spent some time brainstorming around this issue over the past week. Here's my best attempt to summarize our conclusions. [Note that the following discussion assumes a REST-based TAXII Query API.] Immutability of objects under a URL-based object id scheme ========================================================== * If we move to using URLs as object ids, the underlying *data* a  URL-based object id refers to *MUST* be treated as immutable. Here's  why: * Let's take a strawman Indicator. Currently, the object id would be  something like:    example.org:indicator-14adf303-bd57-4dad-bf84-4ba8e8ef175c * If we move to URLs, the object id would be something like:     taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175c * Now, why should the object behind the URL be immutable? Let's say  I'm at Org A and I generate a Report object that links to the Org B  Indicator (above). I'm making an direct assertion regarding that  *particular* Indicator version. Now, if Org B goes and publishes a  revision of the original Indicator *under the same URL*, it creates  a problem for Org A. Do we still support our original assertion from  our Report, given that Org B are effectively shifting the ground  under our feet? Maybe, who knows? Definitely problematic, QED these  things should be immutable. Implications for object versioning ================================== * Object versioning has long been a painful subject. Mark and I came  up with an interesting approach. (Again, assuming a REST-based TAXII  Query API.) * One can envisage a REST-based approach where I can refer to an  object like this:     taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175c/latest/  ...and get the latest revision of the object. * Additionally, one can envisage a REST-based approach where I can refer to an  object like this:     taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175c/history/  ...and get back a JSON blob something like this:    [{'version': 0, 'object_id':      ' taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175c' ,      'changelog': 'initial publication of indicator'},      {'version': 1, 'object_id':      ' taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175d' ,      'changelog': 'typo fix'},      {'version': 2, 'object_id':      ' taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175e' ,      'changelog': 'revoking indicator, this was actually innocuous'}] * This struck us as an intriguing approach. Curious to hear your thoughts. -- 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 -- There are only two hard things in Computer Science: cache invalidation and naming things. --Phil Karlton Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

Mark,   That should change with the top-level relationship object. It will be quite possible to send just a relationship object in a package. This will mean that the consumer will need the ability to contact the original producer of the reference STIX data object to ask if they are allowed the full object rather than just the reference to it. Having the ability to find the TAXII server from just the STIX object ID is critical to allow this to happen.   This functionality also allows more secretive providers to ‘hide’ their data, such that consumers can understand that relationships exist, but that only a small subset of approved consumers will have access to the actual STIX object data. It gives the ability to hide stuff.   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA   An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com     From: Davidson II, Mark S [mailto:mdavidson@mitre.org] Sent: Friday, 30 October 2015 5:05 AM To: Jordan, Bret <bret.jordan@bluecoat.com>; Barnum, Sean D. <sbarnum@mitre.org> Cc: Jerome Athias <athiasjerome@gmail.com>; Terry MacDonald <terry@soltra.com>; Taylor, Marlon <Marlon.Taylor@hq.dhs.gov>; Wunder, John A. <jwunder@mitre.org>; cti-stix@lists.oasis-open.org Subject: RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   If want the ability to dereference arbitrary STIX IDs (for use in accessing some kind of repository, let’s say), then I think requiring a rule whereby STIX IDs can be turned into a URL could be a good requirement (Note: URLs as IDs would satisfy this requirement). While there is a concept for idref today, I personally haven’t seen an implementation that dereferences STIX IDs outside of the document containing the idref.   Thank you. -Mark   PS, a notional example: <stix:Indicator idref=” https://example.org/stix121/indicators/123 ”/>   From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Jordan, Bret Sent: Thursday, October 29, 2015 1:03 PM To: Barnum, Sean D. < sbarnum@mitre.org > Cc: Jerome Athias < athiasjerome@gmail.com >; Terry MacDonald < terry@soltra.com >; Taylor, Marlon < Marlon.Taylor@hq.dhs.gov >; Wunder, John A. < jwunder@mitre.org >; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   Let's just make sure we do not build an ID system that is so vast that it can enumerate every atom in the known universe.     Bret  Sent from my Commodore 64 On Oct 28, 2015, at 10:48 PM, Barnum, Sean D. < sbarnum@mitre.org > wrote: Ah. That makes sense.    What I meant when I included “ID format” in the list of topics was that there have been community members who have complained about the use of Qualified Names as the STIX ID format and that discussion around this question and possible alternative options could occur. Now that we have abstracted from just XSD it likely makes sense to look into whether there are other more preferable forms.   I think the key is just to try to support the basic capabilities we have in Qnames (the ability to specify some sort of sub-identifier for the producer of the ID and some sort of sub-identifier that is globally unique within the producer sub-identifier context).  I think the option that I heard being mentioned before was to look into URIs containing a domain name (and possibly path) as the producer sub-identifier and then the globally unique identifier (e.g., GUID/UUID) as either the end of the path or as a fragment. I don’t recall any opinions being expressed on appropriate schemes to use or if that mattered. I am not arguing for or against this approach but definitely think it should be part of any discussion around exploring new ID format options.   So, I guess the answer to Terry’s question is yes. ;-)   sean   From: Jerome Athias < athiasjerome@gmail.com > Date: Thursday, October 29, 2015 at 1:35 AM To: "Barnum, Sean D." < sbarnum@mitre.org > Cc: Terry MacDonald < terry@soltra.com >, "Taylor, Marlon" < Marlon.Taylor@hq.dhs.gov >, John Wunder < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   I guess it is something like While/when considering 'refactoring' IDs, could we consider to provide as best practice (or enforce) the use of 'domain names' as part of the IDs as a factor of identification of the source/producer. E.g.: ID= microsoft.com -indicator-12345   Terry would correct me if I am wrong On Thursday, 29 October 2015, Barnum, Sean D. < sbarnum@mitre.org > wrote: Terry, I am not sure I understand your question. Could clarify for me?   sean   From: Terry MacDonald < terry@soltra.com > Date: Wednesday, October 28, 2015 at 7:41 PM To: "Taylor, Marlon" < Marlon.Taylor@hq.dhs.gov >, John Wunder < jwunder@mitre.org >, "Barnum, Sean D." < sbarnum@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   Does ID naming also cover ‘namespace mapping to domain name’? That’s another issue that has big implications for the use of relationship objects, TAXII query and STIX requests/responses (which I need to do a big post about).   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 Taylor, Marlon Sent: Thursday, 29 October 2015 5:50 AM To: 'jwunder@mitre.org ' < jwunder@mitre.org >; 'sbarnum@mitre.org ' < sbarnum@mitre.org >; 'cti-stix@lists.oasis-open.org ' < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   Versioning(if different form ID Format) and Duplicates will definitely come up again. -Marlon   From : Wunder, John A. [ mailto:jwunder@mitre.org ] Sent : Wednesday, October 28, 2015 02:46 PM To : Barnum, Sean D. < sbarnum@mitre.org >; cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject : Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   The only other one I can think of is revisiting versioning. Last time we talked about the relationship object it came up. I would add that towards the end of this list though.   From: < cti-stix@lists.oasis-open.org > on behalf of Sean Barnum < sbarnum@mitre.org > Date: Wednesday, October 28, 2015 at 2:12 PM To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0   All,   On the STIX SC call last week we talked about the issue of making immediate progress on STIX v2.0 while we work out prioritizing the full issues list and fleshing out use cases. We proposed that we simply choose the first 2-3 issues to officially tackle based on list interest rather than any official “voting” and listed a few possible options asking for your opinions. The list of “hot” issue options given was: §   Sightings §   Relationships §   ID format §   Abstracting constructs (identity, victim, source and asset) §   In-line vs referencing of content §   Data Markings §   Other suggestions? We did not really get back very many explicit opinions but the activity on the list since the meeting and architectural level considerations make the first two items on the list (Sightings and Relationships) fairly obvious choices for initial issues.   So, we would like to propose officially establishing that the following two issues are the active issues currently under consideration for STIX v2.0: ·          Abstract Sightings into an independent construct rather than embedded within Indicator  ( #306) ·          Abstract relationships as top-level constructs rather than embedded within other constructs  ( #291) If anyone has any serious objections to this decision please let us know. Hopefully we can continue the great discussions on these topics, going even deeper on the details, considering various options and implications and eventually reach some consensus and move on to other topics. While the cti-stix email list is likely to continue as the primary venue for these discussions we encourage everyone to capture key thoughts, observations, opinions and proposals within the issue tracker as well as this will be the official record of our discourse and where we will eventually be declaring our consensus.   If no strong objections are heard these issues will be the primary issue topics of discussion in relation to STIX v2.0 for the SC on the cti-stix list and elsewhere. This does not mean that other issues cannot be raised or commented on if there is need but in the interests of focus and keeping up with list traffic we would like to encourage everyone as much as possible to focus on the active issues under consideration and minimize other issue topics that are likely to distract from deliberative progress on these issues. This should be a pretty fundamental guideline for all issues as we go forward. If you have new issue topics you would like to raise or comments on existing issue topics that are not under active consideration we encourage you to enter these in the issue trackers at any time.     Sean  STIX SC Co-chair

I know historically I have been pushing for an RFC-Compliant UUID as mandatory component of this - now i am going to backtrack on my previous argument :) I actually think that having a UUID be mandatory is not workable, and here is why: For many (most?) products looking to produce observable and sightings, there is no system-wide "ID" in their product that could be used to represent something like an observable. Similarly, STIX producers like embedded devices and endpoints, do not have the resources or processing capacity to start storing these relationships. As such, said producers have two options for generating sightings:
a) Have a randomly-generated UUID (which is of no use to anyone in the end because it will remove all traceability and create rampant data duplication) b) Have an algorithmically derived ID based on the data (IE, any time I issue an observable for Equals 1.2.3.4, the same ID will be derived) (b) Is really the only workable ID mechanism for most products. I have recently started to run into this in practice in my own product work, so I know it is a real problem that is going to hit a lot of people if we start mandating IDs and UUIDs. Here is an assertion - why is ID even a mandatory field for a sighting? I am not sure why it is useful. If a STIX repository needs an ID for an internal record, it can generate its own in any way it wants. I am not sure why a producer needs to specify an ID. - 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 Terry MacDonald ---2015/10/29 06:51:35 PM---Mark, That should change with the top-level relationship object. It will be quite possible to send j From: Terry MacDonald <terry@soltra.com> To: "Davidson II, Mark S" <mdavidson@mitre.org>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "Barnum, Sean D." <sbarnum@mitre.org> Cc: Jerome Athias <athiasjerome@gmail.com>, "Taylor, Marlon" <Marlon.Taylor@hq.dhs.gov>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 2015/10/29 06:51 PM Subject: RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0 Sent by: <cti-stix@lists.oasis-open.org> Mark, That should change with the top-level relationship object. It will be quite possible to send just a relationship object in a package. This will mean that the consumer will need the ability to contact the original producer of the reference STIX data object to ask if they are allowed the full object rather than just the reference to it. Having the ability to find the TAXII server from just the STIX object ID is critical to allow this to happen. This functionality also allows more secretive providers to ‘hide’ their data, such that consumers can understand that relationships exist, but that only a small subset of approved consumers will have access to the actual STIX object data. It gives the ability to hide stuff. Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com From: Davidson II, Mark S [ mailto:mdavidson@mitre.org ] Sent: Friday, 30 October 2015 5:05 AM To: Jordan, Bret <bret.jordan@bluecoat.com>; Barnum, Sean D. <sbarnum@mitre.org> Cc: Jerome Athias <athiasjerome@gmail.com>; Terry MacDonald <terry@soltra.com>; Taylor, Marlon <Marlon.Taylor@hq.dhs.gov>; Wunder, John A. <jwunder@mitre.org>; cti-stix@lists.oasis-open.org Subject: RE: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0 If want the ability to dereference arbitrary STIX IDs (for use in accessing some kind of repository, let’s say), then I think requiring a rule whereby STIX IDs can be turned into a URL could be a good requirement (Note: URLs as IDs would satisfy this requirement). While there is a concept for idref today, I personally haven’t seen an implementation that dereferences STIX IDs outside of the document containing the idref. Thank you. -Mark PS, a notional example: <stix:Indicator idref=” https://example.org/stix121/indicators/123 ”/> From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Jordan, Bret Sent: Thursday, October 29, 2015 1:03 PM To: Barnum, Sean D. < sbarnum@mitre.org > Cc: Jerome Athias < athiasjerome@gmail.com >; Terry MacDonald < terry@soltra.com >; Taylor, Marlon < Marlon.Taylor@hq.dhs.gov >; Wunder, John A. < jwunder@mitre.org >; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0 Let's just make sure we do not build an ID system that is so vast that it can enumerate every atom in the known universe. Bret Sent from my Commodore 64 STIX SC Co-chair

On 29.10.2015 17:03:11, Jordan, Bret wrote: > Let's just make sure we do not build an ID system that is so vast > that it can enumerate every atom in the known universe. > +100 To abuse Carl Sagan's famous line, "If you wish to index that system, you must first invent the multiverse." -- 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 possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea." --RFC 1925 Attachment: signature.asc Description: PGP signature