[cti-users] Re: [cti-stix] Re: [cti-users] Model / Binding Motions

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[cti-users] Re: [cti-stix] Re: [cti-users] Model / Binding Motions

Aharon Chernin
This leads me to a question. Should default bindings or MTI that cover almost all the CTI specs be something that we debate only within the STIX SC? Seems like the STIX SC is almost too narrow of a focus for something that also impacts CybOX and potentially TAXII.

Aharon

From: <[hidden email]> on behalf of "Barnum, Sean D."
Date: Tuesday, October 6, 2015 at 2:15 PM
To: "Foley, Alexander - GIS", "[hidden email]", "[hidden email]"
Subject: [cti-stix] Re: [cti-users] Model / Binding Motions

I do not believe that we are at all ready to be making any decisions on MTI or even really on default bindings yet.

Before such decisions can be made we first need four things:
  • Understanding and consensus on the requirements and evaluation criteria that should be used to select an MTI or default binding
  • Identification and understanding of potential binding options and their capabilities and limitations
  • Understanding of how each potential binding option meets or does not meet the consensus requirements and evaluation criteria
  • Understanding of member opinions and preferences

We simply do not have any of these things yet. Ongoing discussions on the list demonstrate that clearly, I believe.
Even if we had all of the above worked out for our current knowledge, we still would not necessarily have enough to make a decision today as many of the issues and proposals for STIX 2.0 changes have the likelihood of affecting the consensus requirements and evaluation criteria for an MTI. 
Any decisions made on incomplete information are likely to be poor ones.

I would propose that attempting to cut short discussions aimed at addressing the above needs would be premature at this time.

sean

From: <[hidden email]> on behalf of "Foley, Alexander - GIS"
Date: Tuesday, October 6, 2015 at 2:05 PM
To: "[hidden email]", "[hidden email]"
Subject: [cti-users] Model / Binding Motions

By my count:

 

1.      We have Bret’s motion that we require a default binding for STIX and CybOX and it requires a second.

a.      If this motion succeeds, we have Bret’s motion that JSON be chosen as the default binding for STIX and CybOX and it requires a second.

                                                    i.     Kevin Wetzel, I apologize but I do not see you as a member of the cti committee… please follow up with myself, Rich, Chet or OASIS if that’s an incorrect assumption

b.      We also have an (alternate?) proposal from Cory that JSON-LD specifically be chosen as our default binding and it requires a second.

 

I must admit this conversation has been very difficult to follow – if I’m missing a key motion that we construct a UML / RDF / OWL model that’s separate from choosing a new preferred binding / data encoding, please feel free to propose or second any motions.

 

Thanks,

 

Alex

 

From:[hidden email] [[hidden email]] On Behalf Of Jordan, Bret
Sent: Tuesday, October 06, 2015 12:49 PM
To: Aharon Chernin
Cc: [hidden email]; [hidden email]
Subject: [cti-users] Re: [cti-stix] MTI Binding

 

Sounds good...

 

I would like to formally make a motion that we require a default binding for STIX 2.0 and CybOX 3.0.  

 

 

If this is agreed upon, then:

 

I would like to formally make a motion that the default binding for STIX 2.0 and CybOX 3.0 be JSON.

 

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 6, 2015, at 10:40, Aharon Chernin <[hidden email]> wrote:

 

Bret, I think we need to propose that STIX, CybOX, and TAXII have to require a default binding type first. Then the MTI motion could be changed to something like, “I would like to propose that we adopt JSON as the default binding”.

 

Aharon

 

From: <[hidden email]> on behalf of "Jordan, Bret"
Date: Tuesday, October 6, 2015 at 11:45 AM
To: "[hidden email]", "[hidden email]"
Subject: [cti-stix] MTI Binding

 

We have had a good discussion here and on the wiki and I have seen a lot of people advocating for JSON to be used as the MTI.  While a few other options have been tossed around and discussed they do not seem to have an advocate pushing for them nor do they seem to have the broad support that JSON does.  

 

Therefore, I would like to formally propose that we adopt JSON as the MTI for STIX 2.0 and CybOX 3.0.

 

 

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 6, 2015, at 06:17, Davidson II, Mark S <[hidden email]> wrote:

 

I think we’re wrapped around the axle a little bit on this whole topic. I’d like to try and step back and ask some basic questions:

 

1. Is anyone actually proposing JSON-LD as the MTI for STIX? I’ve seen the question asked, and I’ve seen lots of discussion. Is there somebody who would like to come forward and state their opinion that JSON-LD should be the MTI for STIX?

Note: I see this question as a higher bar than asking who thinks we should consider it – IMO the recent discussion makes it clear that we are considering it


2. There was an opinion that the proposed examples (the indicator and incident idioms) wouldn’t be sufficient for comparing size and complexity. What examples would be sufficient?


3. What toolchain is required to develop software that supports using a model without any custom code? Maybe I’m missing something, but if I have a product and I want to add STIX support, won’t developers have to write code? 

I guess at its core – I hear what people are saying about models and not programming to the data syntax, I just don’t understand how that actually works (the more concrete the example the better, at least for me).

 

Thank you.

-Mark

 

 

 


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

[cti-users] Re: [cti-stix] Re: [cti-users] Model / Binding Motions

Barnum, Sean D.
Agree. I think it would certainly be advantageous to deal with this decision across the SCs.

sean

From: Aharon Chernin
Date: Tuesday, October 6, 2015 at 2:24 PM
To: "Barnum, Sean D.", "Foley, Alexander - GIS", "[hidden email]", "[hidden email]"
Subject: Re: [cti-stix] Re: [cti-users] Model / Binding Motions

This leads me to a question. Should default bindings or MTI that cover almost all the CTI specs be something that we debate only within the STIX SC? Seems like the STIX SC is almost too narrow of a focus for something that also impacts CybOX and potentially TAXII.

Aharon

From: <[hidden email]> on behalf of "Barnum, Sean D."
Date: Tuesday, October 6, 2015 at 2:15 PM
To: "Foley, Alexander - GIS", "[hidden email]", "[hidden email]"
Subject: [cti-stix] Re: [cti-users] Model / Binding Motions

I do not believe that we are at all ready to be making any decisions on MTI or even really on default bindings yet.

Before such decisions can be made we first need four things:
  • Understanding and consensus on the requirements and evaluation criteria that should be used to select an MTI or default binding
  • Identification and understanding of potential binding options and their capabilities and limitations
  • Understanding of how each potential binding option meets or does not meet the consensus requirements and evaluation criteria
  • Understanding of member opinions and preferences

We simply do not have any of these things yet. Ongoing discussions on the list demonstrate that clearly, I believe.
Even if we had all of the above worked out for our current knowledge, we still would not necessarily have enough to make a decision today as many of the issues and proposals for STIX 2.0 changes have the likelihood of affecting the consensus requirements and evaluation criteria for an MTI. 
Any decisions made on incomplete information are likely to be poor ones.

I would propose that attempting to cut short discussions aimed at addressing the above needs would be premature at this time.

sean

From: <[hidden email]> on behalf of "Foley, Alexander - GIS"
Date: Tuesday, October 6, 2015 at 2:05 PM
To: "[hidden email]", "[hidden email]"
Subject: [cti-users] Model / Binding Motions

By my count:

 

1.      We have Bret’s motion that we require a default binding for STIX and CybOX and it requires a second.

a.      If this motion succeeds, we have Bret’s motion that JSON be chosen as the default binding for STIX and CybOX and it requires a second.

                                                    i.     Kevin Wetzel, I apologize but I do not see you as a member of the cti committee… please follow up with myself, Rich, Chet or OASIS if that’s an incorrect assumption

b.      We also have an (alternate?) proposal from Cory that JSON-LD specifically be chosen as our default binding and it requires a second.

 

I must admit this conversation has been very difficult to follow – if I’m missing a key motion that we construct a UML / RDF / OWL model that’s separate from choosing a new preferred binding / data encoding, please feel free to propose or second any motions.

 

Thanks,

 

Alex

 

From:[hidden email] [[hidden email]] On Behalf Of Jordan, Bret
Sent: Tuesday, October 06, 2015 12:49 PM
To: Aharon Chernin
Cc: [hidden email]; [hidden email]
Subject: [cti-users] Re: [cti-stix] MTI Binding

 

Sounds good...

 

I would like to formally make a motion that we require a default binding for STIX 2.0 and CybOX 3.0.  

 

 

If this is agreed upon, then:

 

I would like to formally make a motion that the default binding for STIX 2.0 and CybOX 3.0 be JSON.

 

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 6, 2015, at 10:40, Aharon Chernin <[hidden email]> wrote:

 

Bret, I think we need to propose that STIX, CybOX, and TAXII have to require a default binding type first. Then the MTI motion could be changed to something like, “I would like to propose that we adopt JSON as the default binding”.

 

Aharon

 

From: <[hidden email]> on behalf of "Jordan, Bret"
Date: Tuesday, October 6, 2015 at 11:45 AM
To: "[hidden email]", "[hidden email]"
Subject: [cti-stix] MTI Binding

 

We have had a good discussion here and on the wiki and I have seen a lot of people advocating for JSON to be used as the MTI.  While a few other options have been tossed around and discussed they do not seem to have an advocate pushing for them nor do they seem to have the broad support that JSON does.  

 

Therefore, I would like to formally propose that we adopt JSON as the MTI for STIX 2.0 and CybOX 3.0.

 

 

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 6, 2015, at 06:17, Davidson II, Mark S <[hidden email]> wrote:

 

I think we’re wrapped around the axle a little bit on this whole topic. I’d like to try and step back and ask some basic questions:

 

1. Is anyone actually proposing JSON-LD as the MTI for STIX? I’ve seen the question asked, and I’ve seen lots of discussion. Is there somebody who would like to come forward and state their opinion that JSON-LD should be the MTI for STIX?

Note: I see this question as a higher bar than asking who thinks we should consider it – IMO the recent discussion makes it clear that we are considering it


2. There was an opinion that the proposed examples (the indicator and incident idioms) wouldn’t be sufficient for comparing size and complexity. What examples would be sufficient?


3. What toolchain is required to develop software that supports using a model without any custom code? Maybe I’m missing something, but if I have a product and I want to add STIX support, won’t developers have to write code? 

I guess at its core – I hear what people are saying about models and not programming to the data syntax, I just don’t understand how that actually works (the more concrete the example the better, at least for me).

 

Thank you.

-Mark

 

 

 


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

[cti-users] Re: [cti-stix] [cti-users] Model / Binding Motions

Jordan, Bret
In reply to this post by Aharon Chernin
It is important for sure that STIX and CybOX be discussed at the same level.  TAXII is a protocol that will transport more than just STIX and CybOX, so its message types are really independent from this discussion.  


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 6, 2015, at 12:24, Aharon Chernin <[hidden email]> wrote:

This leads me to a question. Should default bindings or MTI that cover almost all the CTI specs be something that we debate only within the STIX SC? Seems like the STIX SC is almost too narrow of a focus for something that also impacts CybOX and potentially TAXII.

Aharon

From: <[hidden email]> on behalf of "Barnum, Sean D."
Date: Tuesday, October 6, 2015 at 2:15 PM
To: "Foley, Alexander - GIS", "[hidden email]", "[hidden email]"
Subject: [cti-stix] Re: [cti-users] Model / Binding Motions

I do not believe that we are at all ready to be making any decisions on MTI or even really on default bindings yet.

Before such decisions can be made we first need four things:
  • Understanding and consensus on the requirements and evaluation criteria that should be used to select an MTI or default binding
  • Identification and understanding of potential binding options and their capabilities and limitations
  • Understanding of how each potential binding option meets or does not meet the consensus requirements and evaluation criteria
  • Understanding of member opinions and preferences

We simply do not have any of these things yet. Ongoing discussions on the list demonstrate that clearly, I believe.
Even if we had all of the above worked out for our current knowledge, we still would not necessarily have enough to make a decision today as many of the issues and proposals for STIX 2.0 changes have the likelihood of affecting the consensus requirements and evaluation criteria for an MTI. 
Any decisions made on incomplete information are likely to be poor ones.

I would propose that attempting to cut short discussions aimed at addressing the above needs would be premature at this time.

sean

From: <[hidden email]> on behalf of "Foley, Alexander - GIS"
Date: Tuesday, October 6, 2015 at 2:05 PM
To: "[hidden email]", "[hidden email]"
Subject: [cti-users] Model / Binding Motions

By my count:
 
1.      We have Bret’s motion that we require a default binding for STIX and CybOX and it requires a second.
a.      If this motion succeeds, we have Bret’s motion that JSON be chosen as the default binding for STIX and CybOX and it requires a second.
                                                    i.     Kevin Wetzel, I apologize but I do not see you as a member of the cti committee… please follow up with myself, Rich, Chet or OASIS if that’s an incorrect assumption
b.      We also have an (alternate?) proposal from Cory that JSON-LD specifically be chosen as our default binding and it requires a second.
 
I must admit this conversation has been very difficult to follow – if I’m missing a key motion that we construct a UML / RDF / OWL model that’s separate from choosing a new preferred binding / data encoding, please feel free to propose or second any motions.
 
Thanks,
 
Alex
 
From:[hidden email] [[hidden email]] On Behalf Of Jordan, Bret
Sent: Tuesday, October 06, 2015 12:49 PM
To: Aharon Chernin
Cc: [hidden email]; [hidden email]
Subject: [cti-users] Re: [cti-stix] MTI Binding
 
Sounds good...
 
I would like to formally make a motion that we require a default binding for STIX 2.0 and CybOX 3.0.  
 
 
If this is agreed upon, then:
 
I would like to formally make a motion that the default binding for STIX 2.0 and CybOX 3.0 be JSON.

 

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 6, 2015, at 10:40, Aharon Chernin <[hidden email]> wrote:
 
Bret, I think we need to propose that STIX, CybOX, and TAXII have to require a default binding type first. Then the MTI motion could be changed to something like, “I would like to propose that we adopt JSON as the default binding”.
 
Aharon
 
From: <[hidden email]> on behalf of "Jordan, Bret"
Date: Tuesday, October 6, 2015 at 11:45 AM
To: "[hidden email]", "[hidden email]"
Subject: [cti-stix] MTI Binding
 
We have had a good discussion here and on the wiki and I have seen a lot of people advocating for JSON to be used as the MTI.  While a few other options have been tossed around and discussed they do not seem to have an advocate pushing for them nor do they seem to have the broad support that JSON does.  
 
Therefore, I would like to formally propose that we adopt JSON as the MTI for STIX 2.0 and CybOX 3.0.
 
 
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 6, 2015, at 06:17, Davidson II, Mark S <[hidden email]> wrote:
 
I think we’re wrapped around the axle a little bit on this whole topic. I’d like to try and step back and ask some basic questions:
 
1. Is anyone actually proposing JSON-LD as the MTI for STIX? I’ve seen the question asked, and I’ve seen lots of discussion. Is there somebody who would like to come forward and state their opinion that JSON-LD should be the MTI for STIX?
Note: I see this question as a higher bar than asking who thinks we should consider it – IMO the recent discussion makes it clear that we are considering it


2. There was an opinion that the proposed examples (the indicator and incident idioms) wouldn’t be sufficient for comparing size and complexity. What examples would be sufficient?


3. What toolchain is required to develop software that supports using a model without any custom code? Maybe I’m missing something, but if I have a product and I want to add STIX support, won’t developers have to write code? 
I guess at its core – I hear what people are saying about models and not programming to the data syntax, I just don’t understand how that actually works (the more concrete the example the better, at least for me).
 
Thank you.
-Mark
 
 
 

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


signature.asc (859 bytes) Download Attachment