[STIX] attn Soltra

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

[STIX] attn Soltra

Josh Larkins

Could someone from Soltra contact me? I have a customer who says Soltra Edge is rejecting a STIX doc that my company produced, but the python STIX validator 1.1.1.2 says it’s valid. I’d like to figure out why it’s being rejected.

 

Josh Larkins

Sr. Threat Intelligence Analyst

Malcovery Security

[hidden email]

www.malcovery.com

 

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] attn Soltra

Aharon Chernin
Can you email me an example document that fails to load? Please send off list.

Aharon

Sent using OWA for iPhone
From: Josh Larkins <[hidden email]>
Sent: Thursday, April 2, 2015 5:10:11 PM
To: [hidden email]
Subject: [STIX] attn Soltra
 

Could someone from Soltra contact me? I have a customer who says Soltra Edge is rejecting a STIX doc that my company produced, but the python STIX validator 1.1.1.2 says it’s valid. I’d like to figure out why it’s being rejected.

 

Josh Larkins

Sr. Threat Intelligence Analyst

Malcovery Security

[hidden email]

www.malcovery.com

 

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] attn Soltra

Aharon Chernin

I am responding back to the list as I think this is information that can help a lot of other folks on here:


* Including IDs in your STIX objects is a documented STIX best practice (http://stixproject.github.io/documentation/suggested-practices/). Which means it will still be valid STIX even if you don't follow the best practices. However, we have made the decision to reject content without IDs. If you add them to your objects the content should import into our product.

* When you do add IDs, make sure you don't use "example" as your namespace prefix. We also reject content that uses the example namespace.

* Whenever possible, provide titles and descriptions for objects. This gives us, and your customers, a way to browse the content you just sent them. Titles and Descriptions are one of the few human readable elements that exist between all the objects.



Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

From: Aharon Chernin <[hidden email]>
Sent: Thursday, April 2, 2015 6:40 PM
To: [hidden email]
Subject: Re: [STIX] attn Soltra
 
Can you email me an example document that fails to load? Please send off list.

Aharon

Sent using OWA for iPhone
From: Josh Larkins <[hidden email]>
Sent: Thursday, April 2, 2015 5:10:11 PM
To: [hidden email]
Subject: [STIX] attn Soltra
 

Could someone from Soltra contact me? I have a customer who says Soltra Edge is rejecting a STIX doc that my company produced, but the python STIX validator 1.1.1.2 says it’s valid. I’d like to figure out why it’s being rejected.

 

Josh Larkins

Sr. Threat Intelligence Analyst

Malcovery Security

[hidden email]

www.malcovery.com

 

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] attn Soltra

Terry MacDonald
Further to that, the stix python validator has a 'best practices' command line switch that will check for some of what Aharon has mentioned. To use:

stix_validator.py --best-practices <stix_document.xml>

Cheers
Terry MacDonald


On 3 April 2015 at 22:16, Aharon Chernin <[hidden email]> wrote:

I am responding back to the list as I think this is information that can help a lot of other folks on here:


* Including IDs in your STIX objects is a documented STIX best practice (http://stixproject.github.io/documentation/suggested-practices/). Which means it will still be valid STIX even if you don't follow the best practices. However, we have made the decision to reject content without IDs. If you add them to your objects the content should import into our product.

* When you do add IDs, make sure you don't use "example" as your namespace prefix. We also reject content that uses the example namespace.

* Whenever possible, provide titles and descriptions for objects. This gives us, and your customers, a way to browse the content you just sent them. Titles and Descriptions are one of the few human readable elements that exist between all the objects.



Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

From: Aharon Chernin <[hidden email]>
Sent: Thursday, April 2, 2015 6:40 PM
To: [hidden email]
Subject: Re: [STIX] attn Soltra
 
Can you email me an example document that fails to load? Please send off list.

Aharon

Sent using OWA for iPhone
From: Josh Larkins <[hidden email]>
Sent: Thursday, April 2, 2015 5:10:11 PM
To: [hidden email]
Subject: [STIX] attn Soltra
 

Could someone from Soltra contact me? I have a customer who says Soltra Edge is rejecting a STIX doc that my company produced, but the python STIX validator 1.1.1.2 says it’s valid. I’d like to figure out why it’s being rejected.

 

Josh Larkins

Sr. Threat Intelligence Analyst

Malcovery Security

[hidden email]

www.malcovery.com

 


Reply | Threaded
Open this post in threaded view
|

Re: [STIX] attn Soltra

Josh Larkins

Thank you for the quick feedback. I guess adding IDs (and other stuff) just bubbled up to the very top of my to do list J

 

Josh

 

 

 

From: Terry MacDonald [mailto:[hidden email]]
Sent: Friday, April 03, 2015 7:26 AM
To: [hidden email]
Subject: Re: [STIX] attn Soltra

 

Further to that, the stix python validator has a 'best practices' command line switch that will check for some of what Aharon has mentioned. To use:

 

stix_validator.py --best-practices <stix_document.xml>


Cheers
Terry MacDonald

 

 

On 3 April 2015 at 22:16, Aharon Chernin <[hidden email]> wrote:

I am responding back to the list as I think this is information that can help a lot of other folks on here:

 

* Including IDs in your STIX objects is a documented STIX best practice (http://stixproject.github.io/documentation/suggested-practices/). Which means it will still be valid STIX even if you don't follow the best practices. However, we have made the decision to reject content without IDs. If you add them to your objects the content should import into our product.

* When you do add IDs, make sure you don't use "example" as your namespace prefix. We also reject content that uses the example namespace.

* Whenever possible, provide titles and descriptions for objects. This gives us, and your customers, a way to browse the content you just sent them. Titles and Descriptions are one of the few human readable elements that exist between all the objects.

 

 

Aharon Chernin
CTO

SOLTRA | An FS-ISAC & DTCC Company

18301 Bermuda green Dr

Tampa, fl 33647

813.470.2173 | [hidden email]


From: Aharon Chernin <[hidden email]>
Sent: Thursday, April 2, 2015 6:40 PM
To: [hidden email]
Subject: Re: [STIX] attn Soltra

 

Can you email me an example document that fails to load? Please send off list.

Aharon

Sent using OWA for iPhone


From: Josh Larkins <[hidden email]>
Sent: Thursday, April 2, 2015 5:10:11 PM
To: [hidden email]
Subject: [STIX] attn Soltra

 

Could someone from Soltra contact me? I have a customer who says Soltra Edge is rejecting a STIX doc that my company produced, but the python STIX validator 1.1.1.2 says it’s valid. I’d like to figure out why it’s being rejected.

 

Josh Larkins

Sr. Threat Intelligence Analyst

Malcovery Security

[hidden email]

www.malcovery.com

 

 

Reply | Threaded
Open this post in threaded view
|

[STIX] Signaling Local Policies

Eric Burger
In reply to this post by Aharon Chernin
This is disturbing. If Soltra does not accept a legal STIX document, Soltra is not a STIX processor. As one of my old CEO’s said, “There is nothing worse than almost compatible."

We may have found a missing feature (a.k.a. bug) in TAXII. It is fine for a site to implement a policy that rejects what would be legal STIX documents. For example, if that site requires IDs and bars com.example.mumble in a STIX document. However, if the implementation cannot signal why it rejected the document (e.g., “Fails local policy check”), then we do not have interoperability, as shown by the initial exchange in this thread.


On Apr 3, 2015, at 7:16 AM, Aharon Chernin <[hidden email]> wrote:

I am responding back to the list as I think this is information that can help a lot of other folks on here:

* Including IDs in your STIX objects is a documented STIX best practice (http://stixproject.github.io/documentation/suggested-practices/). Which means it will still be valid STIX even if you don't follow the best practices. However, we have made the decision to reject content without IDs. If you add them to your objects the content should import into our product.
* When you do add IDs, make sure you don't use "example" as your namespace prefix. We also reject content that uses the example namespace.
* Whenever possible, provide titles and descriptions for objects. This gives us, and your customers, a way to browse the content you just sent them. Titles and Descriptions are one of the few human readable elements that exist between all the objects.


Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

From: Aharon Chernin <[hidden email]>
Sent: Thursday, April 2, 2015 6:40 PM
To: [hidden email]
Subject: Re: [STIX] attn Soltra
 
Can you email me an example document that fails to load? Please send off list.

Aharon

Sent using OWA for iPhone
From: Josh Larkins <[hidden email]>
Sent: Thursday, April 2, 2015 5:10:11 PM
To: [hidden email]
Subject: [STIX] attn Soltra
 
Could someone from Soltra contact me? I have a customer who says Soltra Edge is rejecting a STIX doc that my company produced, but the python STIX validator 1.1.1.2 says it’s valid. I’d like to figure out why it’s being rejected.

 

Josh Larkins
Sr. Threat Intelligence Analyst
Malcovery Security

 



smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Signaling Local Policies

Aharon Chernin

This is disturbing. If Soltra does not accept a legal STIX document, Soltra is not a STIX processor. As one of my old CEO’s said, “There is nothing worse than almost compatible."


It's not as if we are embracing and extending STIX. We are simply enforcing best practices. It's highly likely that these best practices will be made requirements in future releases of STIX (>2.x). We aren't here to prove that we can build a system that can accept poorly formatted STIX, we are here to help our community. One of the ways we do this is by requiring that producers make good STIX. In fact, this is the first time we have received a complaint due to our enforcement of STIX best practices.


As for our rejection in TAXII, we do create a TAXII message that states why the content was rejected.


Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

From: Eric Burger <[hidden email]>
Sent: Friday, April 3, 2015 10:55 AM
To: [hidden email]
Subject: [STIX] Signaling Local Policies
 
This is disturbing. If Soltra does not accept a legal STIX document, Soltra is not a STIX processor. As one of my old CEO’s said, “There is nothing worse than almost compatible."

We may have found a missing feature (a.k.a. bug) in TAXII. It is fine for a site to implement a policy that rejects what would be legal STIX documents. For example, if that site requires IDs and bars com.example.mumble in a STIX document. However, if the implementation cannot signal why it rejected the document (e.g., “Fails local policy check”), then we do not have interoperability, as shown by the initial exchange in this thread.


On Apr 3, 2015, at 7:16 AM, Aharon Chernin <[hidden email]> wrote:

I am responding back to the list as I think this is information that can help a lot of other folks on here:

* Including IDs in your STIX objects is a documented STIX best practice (http://stixproject.github.io/documentation/suggested-practices/). Which means it will still be valid STIX even if you don't follow the best practices. However, we have made the decision to reject content without IDs. If you add them to your objects the content should import into our product.
* When you do add IDs, make sure you don't use "example" as your namespace prefix. We also reject content that uses the example namespace.
* Whenever possible, provide titles and descriptions for objects. This gives us, and your customers, a way to browse the content you just sent them. Titles and Descriptions are one of the few human readable elements that exist between all the objects.


Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

From: Aharon Chernin <[hidden email]>
Sent: Thursday, April 2, 2015 6:40 PM
To: [hidden email]
Subject: Re: [STIX] attn Soltra
 
Can you email me an example document that fails to load? Please send off list.

Aharon

Sent using OWA for iPhone
From: Josh Larkins <[hidden email]>
Sent: Thursday, April 2, 2015 5:10:11 PM
To: [hidden email]
Subject: [STIX] attn Soltra
 
Could someone from Soltra contact me? I have a customer who says Soltra Edge is rejecting a STIX doc that my company produced, but the python STIX validator 1.1.1.2 says it’s valid. I’d like to figure out why it’s being rejected.

 

Josh Larkins
Sr. Threat Intelligence Analyst
Malcovery Security

 


Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Signaling Local Policies

pmaroney
FWIW: "We" are a customer of Aharon and Team at Soltra and insisted on enforcement of this Best Practice.  Not disagreeing with the point Eric is making per se, but support the position Aharon has taken (again as a customer and advocate for IDs as a MUST requirement for our reference implementations).

Patrick Maroney
Office: (856)983-0001
Cell: (609)841-5104
[hidden email]
From: Aharon Chernin <[hidden email]>
Sent: Friday, April 3, 2015 11:30:55 AM
To: [hidden email]
Subject: Re: [STIX] Signaling Local Policies
 

This is disturbing. If Soltra does not accept a legal STIX document, Soltra is not a STIX processor. As one of my old CEO’s said, “There is nothing worse than almost compatible."


It's not as if we are embracing and extending STIX. We are simply enforcing best practices. It's highly likely that these best practices will be made requirements in future releases of STIX (>2.x). We aren't here to prove that we can build a system that can accept poorly formatted STIX, we are here to help our community. One of the ways we do this is by requiring that producers make good STIX. In fact, this is the first time we have received a complaint due to our enforcement of STIX best practices.


As for our rejection in TAXII, we do create a TAXII message that states why the content was rejected.


Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

From: Eric Burger <[hidden email]>
Sent: Friday, April 3, 2015 10:55 AM
To: [hidden email]
Subject: [STIX] Signaling Local Policies
 
This is disturbing. If Soltra does not accept a legal STIX document, Soltra is not a STIX processor. As one of my old CEO’s said, “There is nothing worse than almost compatible."

We may have found a missing feature (a.k.a. bug) in TAXII. It is fine for a site to implement a policy that rejects what would be legal STIX documents. For example, if that site requires IDs and bars com.example.mumble in a STIX document. However, if the implementation cannot signal why it rejected the document (e.g., “Fails local policy check”), then we do not have interoperability, as shown by the initial exchange in this thread.


On Apr 3, 2015, at 7:16 AM, Aharon Chernin <[hidden email]> wrote:

I am responding back to the list as I think this is information that can help a lot of other folks on here:

* Including IDs in your STIX objects is a documented STIX best practice (http://stixproject.github.io/documentation/suggested-practices/). Which means it will still be valid STIX even if you don't follow the best practices. However, we have made the decision to reject content without IDs. If you add them to your objects the content should import into our product.
* When you do add IDs, make sure you don't use "example" as your namespace prefix. We also reject content that uses the example namespace.
* Whenever possible, provide titles and descriptions for objects. This gives us, and your customers, a way to browse the content you just sent them. Titles and Descriptions are one of the few human readable elements that exist between all the objects.


Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

From: Aharon Chernin <[hidden email]>
Sent: Thursday, April 2, 2015 6:40 PM
To: [hidden email]
Subject: Re: [STIX] attn Soltra
 
Can you email me an example document that fails to load? Please send off list.

Aharon

Sent using OWA for iPhone
From: Josh Larkins <[hidden email]>
Sent: Thursday, April 2, 2015 5:10:11 PM
To: [hidden email]
Subject: [STIX] attn Soltra
 
Could someone from Soltra contact me? I have a customer who says Soltra Edge is rejecting a STIX doc that my company produced, but the python STIX validator 1.1.1.2 says it’s valid. I’d like to figure out why it’s being rejected.

 

Josh Larkins
Sr. Threat Intelligence Analyst
Malcovery Security

 


Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Signaling Local Policies

Jordan, Bret
In reply to this post by Aharon Chernin
Aharon +1..   Right now there is a lot of ways to generate loosey-goosey STIX and its children.  In STIX 2.0 I would like to see the best practices and other items be made requirements, basically tighten things a bit to make sure people generate good STIX.

Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Apr 3, 2015, at 9:30 AM, Aharon Chernin <[hidden email]> wrote:

This is disturbing. If Soltra does not accept a legal STIX document, Soltra is not a STIX processor. As one of my old CEO’s said, “There is nothing worse than almost compatible."


It's not as if we are embracing and extending STIX. We are simply enforcing best practices. It's highly likely that these best practices will be made requirements in future releases of STIX (>2.x). We aren't here to prove that we can build a system that can accept poorly formatted STIX, we are here to help our community. One of the ways we do this is by requiring that producers make good STIX. In fact, this is the first time we have received a complaint due to our enforcement of STIX best practices.


As for our rejection in TAXII, we do create a TAXII message that states why the content was rejected.


Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

From: Eric Burger <[hidden email]>
Sent: Friday, April 3, 2015 10:55 AM
To: [hidden email]
Subject: [STIX] Signaling Local Policies
 
This is disturbing. If Soltra does not accept a legal STIX document, Soltra is not a STIX processor. As one of my old CEO’s said, “There is nothing worse than almost compatible."

We may have found a missing feature (a.k.a. bug) in TAXII. It is fine for a site to implement a policy that rejects what would be legal STIX documents. For example, if that site requires IDs and bars com.example.mumble in a STIX document. However, if the implementation cannot signal why it rejected the document (e.g., “Fails local policy check”), then we do not have interoperability, as shown by the initial exchange in this thread.


On Apr 3, 2015, at 7:16 AM, Aharon Chernin <[hidden email]> wrote:

I am responding back to the list as I think this is information that can help a lot of other folks on here:

* Including IDs in your STIX objects is a documented STIX best practice (http://stixproject.github.io/documentation/suggested-practices/). Which means it will still be valid STIX even if you don't follow the best practices. However, we have made the decision to reject content without IDs. If you add them to your objects the content should import into our product.
* When you do add IDs, make sure you don't use "example" as your namespace prefix. We also reject content that uses the example namespace.
* Whenever possible, provide titles and descriptions for objects. This gives us, and your customers, a way to browse the content you just sent them. Titles and Descriptions are one of the few human readable elements that exist between all the objects.


Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

From: Aharon Chernin <[hidden email]>
Sent: Thursday, April 2, 2015 6:40 PM
To: [hidden email]
Subject: Re: [STIX] attn Soltra
 
Can you email me an example document that fails to load? Please send off list.

Aharon

Sent using OWA for iPhone
From: Josh Larkins <[hidden email]>
Sent: Thursday, April 2, 2015 5:10:11 PM
To: [hidden email]
Subject: [STIX] attn Soltra
 
Could someone from Soltra contact me? I have a customer who says Soltra Edge is rejecting a STIX doc that my company produced, but the python STIX validator 1.1.1.2 says it’s valid. I’d like to figure out why it’s being rejected.

 

Josh Larkins
Sr. Threat Intelligence Analyst
Malcovery Security

 




signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Signaling Local Policies

Eric Burger
I am a firm believer in having MUSTs and MUST NOTs and few or no SHOULDs or MAYs. Moreover, for this particular item, if we do not use the ID, it means we cannot refer to the object independently, which means we are paying an enormous complexity tax with no benefit. I am not arguing about whether or not ID should be there. I think it should (must!). What I am saying is no one should need to ask “What’s up with Soltra?” when it rejects a legal STIX document. TAXII should be clear enough to an implementor that when Soltra rejects the document, it is immediately obvious what they need to do.

I’m not sure whether that is something lacking in TAXII or in what Soltra sends back.

I will take exception to an implementation “enforcing best practices” if that means a protocol failure. A response saying, “I don’t like that for my own reasons,” presuming the protocol lets you say that, is OK. A response saying, “What you gave me is not STIX” when it is STIX is not OK. That says the implementation is not STIX. That said, what I think we are in violent agreement over is that STIX (1) must require ID’s (per this thread, in STIX 2.0) and (2) the protocol machinery needs to be clear enough to let an implementation signal to a client why it rejects a legal document.


On Apr 3, 2015, at 1:16 PM, Jordan, Bret <[hidden email]> wrote:

Aharon +1..   Right now there is a lot of ways to generate loosey-goosey STIX and its children.  In STIX 2.0 I would like to see the best practices and other items be made requirements, basically tighten things a bit to make sure people generate good STIX.

Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Apr 3, 2015, at 9:30 AM, Aharon Chernin <[hidden email]> wrote:

This is disturbing. If Soltra does not accept a legal STIX document, Soltra is not a STIX processor. As one of my old CEO’s said, “There is nothing worse than almost compatible."

It's not as if we are embracing and extending STIX. We are simply enforcing best practices. It's highly likely that these best practices will be made requirements in future releases of STIX (>2.x). We aren't here to prove that we can build a system that can accept poorly formatted STIX, we are here to help our community. One of the ways we do this is by requiring that producers make good STIX. In fact, this is the first time we have received a complaint due to our enforcement of STIX best practices.

As for our rejection in TAXII, we do create a TAXII message that states why the content was rejected.

Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

From: Eric Burger <[hidden email]>
Sent: Friday, April 3, 2015 10:55 AM
To: [hidden email]
Subject: [STIX] Signaling Local Policies
 
This is disturbing. If Soltra does not accept a legal STIX document, Soltra is not a STIX processor. As one of my old CEO’s said, “There is nothing worse than almost compatible."

We may have found a missing feature (a.k.a. bug) in TAXII. It is fine for a site to implement a policy that rejects what would be legal STIX documents. For example, if that site requires IDs and bars com.example.mumble in a STIX document. However, if the implementation cannot signal why it rejected the document (e.g., “Fails local policy check”), then we do not have interoperability, as shown by the initial exchange in this thread.


On Apr 3, 2015, at 7:16 AM, Aharon Chernin <[hidden email]> wrote:

I am responding back to the list as I think this is information that can help a lot of other folks on here:

* Including IDs in your STIX objects is a documented STIX best practice (http://stixproject.github.io/documentation/suggested-practices/). Which means it will still be valid STIX even if you don't follow the best practices. However, we have made the decision to reject content without IDs. If you add them to your objects the content should import into our product.
* When you do add IDs, make sure you don't use "example" as your namespace prefix. We also reject content that uses the example namespace.
* Whenever possible, provide titles and descriptions for objects. This gives us, and your customers, a way to browse the content you just sent them. Titles and Descriptions are one of the few human readable elements that exist between all the objects.


Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

From: Aharon Chernin <[hidden email]>
Sent: Thursday, April 2, 2015 6:40 PM
To: [hidden email]
Subject: Re: [STIX] attn Soltra
 
Can you email me an example document that fails to load? Please send off list.

Aharon

Sent using OWA for iPhone 
From: Josh Larkins <[hidden email]>
Sent: Thursday, April 2, 2015 5:10:11 PM
To: [hidden email]
Subject: [STIX] attn Soltra
 
Could someone from Soltra contact me? I have a customer who says Soltra Edge is rejecting a STIX doc that my company produced, but the python STIX validator 1.1.1.2 says it’s valid. I’d like to figure out why it’s being rejected.

 

Josh Larkins
Sr. Threat Intelligence Analyst
Malcovery Security


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Signaling Local Policies

Jordan, Bret
Well said Eric, I agree.  As a TAXII best practice, the error messages coming back for bad STIX should be helpful.  This reminds me of days long ago about Supplicants giving very poor information as to why someone could not connect to the network, even though the supplicant either knew or had a very very good idea as to why.  


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Apr 3, 2015, at 11:56 AM, Eric Burger <[hidden email]> wrote:

I am a firm believer in having MUSTs and MUST NOTs and few or no SHOULDs or MAYs. Moreover, for this particular item, if we do not use the ID, it means we cannot refer to the object independently, which means we are paying an enormous complexity tax with no benefit. I am not arguing about whether or not ID should be there. I think it should (must!). What I am saying is no one should need to ask “What’s up with Soltra?” when it rejects a legal STIX document. TAXII should be clear enough to an implementor that when Soltra rejects the document, it is immediately obvious what they need to do.

I’m not sure whether that is something lacking in TAXII or in what Soltra sends back.

I will take exception to an implementation “enforcing best practices” if that means a protocol failure. A response saying, “I don’t like that for my own reasons,” presuming the protocol lets you say that, is OK. A response saying, “What you gave me is not STIX” when it is STIX is not OK. That says the implementation is not STIX. That said, what I think we are in violent agreement over is that STIX (1) must require ID’s (per this thread, in STIX 2.0) and (2) the protocol machinery needs to be clear enough to let an implementation signal to a client why it rejects a legal document.


On Apr 3, 2015, at 1:16 PM, Jordan, Bret <[hidden email]> wrote:

Aharon +1..   Right now there is a lot of ways to generate loosey-goosey STIX and its children.  In STIX 2.0 I would like to see the best practices and other items be made requirements, basically tighten things a bit to make sure people generate good STIX.

Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Apr 3, 2015, at 9:30 AM, Aharon Chernin <[hidden email]> wrote:

This is disturbing. If Soltra does not accept a legal STIX document, Soltra is not a STIX processor. As one of my old CEO’s said, “There is nothing worse than almost compatible."

It's not as if we are embracing and extending STIX. We are simply enforcing best practices. It's highly likely that these best practices will be made requirements in future releases of STIX (>2.x). We aren't here to prove that we can build a system that can accept poorly formatted STIX, we are here to help our community. One of the ways we do this is by requiring that producers make good STIX. In fact, this is the first time we have received a complaint due to our enforcement of STIX best practices.

As for our rejection in TAXII, we do create a TAXII message that states why the content was rejected.

Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

From: Eric Burger <[hidden email]>
Sent: Friday, April 3, 2015 10:55 AM
To: [hidden email]
Subject: [STIX] Signaling Local Policies
 
This is disturbing. If Soltra does not accept a legal STIX document, Soltra is not a STIX processor. As one of my old CEO’s said, “There is nothing worse than almost compatible."

We may have found a missing feature (a.k.a. bug) in TAXII. It is fine for a site to implement a policy that rejects what would be legal STIX documents. For example, if that site requires IDs and bars com.example.mumble in a STIX document. However, if the implementation cannot signal why it rejected the document (e.g., “Fails local policy check”), then we do not have interoperability, as shown by the initial exchange in this thread.


On Apr 3, 2015, at 7:16 AM, Aharon Chernin <[hidden email]> wrote:

I am responding back to the list as I think this is information that can help a lot of other folks on here:

* Including IDs in your STIX objects is a documented STIX best practice (http://stixproject.github.io/documentation/suggested-practices/). Which means it will still be valid STIX even if you don't follow the best practices. However, we have made the decision to reject content without IDs. If you add them to your objects the content should import into our product.
* When you do add IDs, make sure you don't use "example" as your namespace prefix. We also reject content that uses the example namespace.
* Whenever possible, provide titles and descriptions for objects. This gives us, and your customers, a way to browse the content you just sent them. Titles and Descriptions are one of the few human readable elements that exist between all the objects.


Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

From: Aharon Chernin <[hidden email]>
Sent: Thursday, April 2, 2015 6:40 PM
To: [hidden email]
Subject: Re: [STIX] attn Soltra
 
Can you email me an example document that fails to load? Please send off list.

Aharon

Sent using OWA for iPhone 
From: Josh Larkins <[hidden email]>
Sent: Thursday, April 2, 2015 5:10:11 PM
To: [hidden email]
Subject: [STIX] attn Soltra
 
Could someone from Soltra contact me? I have a customer who says Soltra Edge is rejecting a STIX doc that my company produced, but the python STIX validator 1.1.1.2 says it’s valid. I’d like to figure out why it’s being rejected.

 

Josh Larkins
Sr. Threat Intelligence Analyst
Malcovery Security



signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Signaling Local Policies

Josh Larkins

I appreciate everyone’s thoughts on this. I didn’t quite mean to start a small war, as I definitely agree with everyone else that the IDs are incredibly important. I don’t know if Soltra returns any more meaningful error than “nope” when our document was inserted, but from the customer’s one line snippet, I had no idea what the reason was. I was a bit disappointed to find out that our valid STIX for its current version (1.1.1) wasn’t “good enough” for Soltra.

 

Now I’ll go fix our STIX.

 

Josh

 

 

From: Jordan, Bret [mailto:[hidden email]]
Sent: Friday, April 03, 2015 2:01 PM
To: [hidden email]
Subject: Re: [STIX] Signaling Local Policies

 

Well said Eric, I agree.  As a TAXII best practice, the error messages coming back for bad STIX should be helpful.  This reminds me of days long ago about Supplicants giving very poor information as to why someone could not connect to the network, even though the supplicant either knew or had a very very good idea as to why.  

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303

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

 

On Apr 3, 2015, at 11:56 AM, Eric Burger <[hidden email]> wrote:

 

I am a firm believer in having MUSTs and MUST NOTs and few or no SHOULDs or MAYs. Moreover, for this particular item, if we do not use the ID, it means we cannot refer to the object independently, which means we are paying an enormous complexity tax with no benefit. I am not arguing about whether or not ID should be there. I think it should (must!). What I am saying is no one should need to ask “What’s up with Soltra?” when it rejects a legal STIX document. TAXII should be clear enough to an implementor that when Soltra rejects the document, it is immediately obvious what they need to do.

 

I’m not sure whether that is something lacking in TAXII or in what Soltra sends back.

 

I will take exception to an implementation “enforcing best practices” if that means a protocol failure. A response saying, “I don’t like that for my own reasons,” presuming the protocol lets you say that, is OK. A response saying, “What you gave me is not STIX” when it is STIX is not OK. That says the implementation is not STIX. That said, what I think we are in violent agreement over is that STIX (1) must require ID’s (per this thread, in STIX 2.0) and (2) the protocol machinery needs to be clear enough to let an implementation signal to a client why it rejects a legal document.

 

On Apr 3, 2015, at 1:16 PM, Jordan, Bret <[hidden email]> wrote:

 

Aharon +1..   Right now there is a lot of ways to generate loosey-goosey STIX and its children.  In STIX 2.0 I would like to see the best practices and other items be made requirements, basically tighten things a bit to make sure people generate good STIX.

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303

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

 

On Apr 3, 2015, at 9:30 AM, Aharon Chernin <[hidden email]> wrote:

 

This is disturbing. If Soltra does not accept a legal STIX document, Soltra is not a STIX processor. As one of my old CEO’s said, “There is nothing worse than almost compatible."


It's not as if we are embracing and extending STIX. We are simply enforcing best practices. It's highly likely that these best practices will be made requirements in future releases of STIX (>2.x). We aren't here to prove that we can build a system that can accept poorly formatted STIX, we are here to help our community. One of the ways we do this is by requiring that producers make good STIX. In fact, this is the first time we have received a complaint due to our enforcement of STIX best practices.

 

As for our rejection in TAXII, we do create a TAXII message that states why the content was rejected.

 

Aharon Chernin
CTO

SOLTRA | An FS-ISAC & DTCC Company

18301 Bermuda green Dr

Tampa, fl 33647

813.470.2173 | [hidden email]


From: Eric Burger <[hidden email]>
Sent: Friday, April 3, 2015 10:55 AM
To: [hidden email]
Subject: [STIX] Signaling Local Policies

 

This is disturbing. If Soltra does not accept a legal STIX document, Soltra is not a STIX processor. As one of my old CEO’s said, “There is nothing worse than almost compatible."

 

We may have found a missing feature (a.k.a. bug) in TAXII. It is fine for a site to implement a policy that rejects what would be legal STIX documents. For example, if that site requires IDs and bars com.example.mumble in a STIX document. However, if the implementation cannot signal why it rejected the document (e.g., “Fails local policy check”), then we do not have interoperability, as shown by the initial exchange in this thread.

 

On Apr 3, 2015, at 7:16 AM, Aharon Chernin <[hidden email]> wrote:

 

I am responding back to the list as I think this is information that can help a lot of other folks on here:

 

* Including IDs in your STIX objects is a documented STIX best practice (http://stixproject.github.io/documentation/suggested-practices/). Which means it will still be valid STIX even if you don't follow the best practices. However, we have made the decision to reject content without IDs. If you add them to your objects the content should import into our product.

* When you do add IDs, make sure you don't use "example" as your namespace prefix. We also reject content that uses the example namespace.

* Whenever possible, provide titles and descriptions for objects. This gives us, and your customers, a way to browse the content you just sent them. Titles and Descriptions are one of the few human readable elements that exist between all the objects.

 

 

Aharon Chernin
CTO

SOLTRA | An FS-ISAC & DTCC Company

18301 Bermuda green Dr

Tampa, fl 33647

813.470.2173 | [hidden email]


From: Aharon Chernin <[hidden email]>
Sent: Thursday, April 2, 2015 6:40 PM
To: [hidden email]
Subject: Re: [STIX] attn Soltra

 

Can you email me an example document that fails to load? Please send off list.

Aharon

Sent using OWA for iPhone 


From: Josh Larkins <[hidden email]>
Sent: Thursday, April 2, 2015 5:10:11 PM
To: [hidden email]
Subject: [STIX] attn Soltra

 

Could someone from Soltra contact me? I have a customer who says Soltra Edge is rejecting a STIX doc that my company produced, but the python STIX validator 1.1.1.2 says it’s valid. I’d like to figure out why it’s being rejected.

 

Josh Larkins

Sr. Threat Intelligence Analyst

Malcovery Security

 

 

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Signaling Local Policies

mdavidson

I’ll chime in from a TAXII point of view here. I’m presuming the context of this discussion is an Inbox Message with STIX content that was rejected.

 

Here are some relevant requirements from the TAXII Services Spec (From the TAXII Services Spec 1.1, Section 3.2):

>  If the Inbox Daemon detects an error that prevents processing of the message (e.g., a malformed message) the Inbox Daemon MUST respond with an appropriate Status Message indicating that the exchange failed.

> The TAXII Daemon MUST send a Status Message in response to the Inbox Message, indicating either the success or failure of the message exchange.

 

And one piece of relevant informational text:

>  Note that a Status Message of type "Success" indicates only that the Inbox Daemon successfully received and parsed the message and that it met TAXII-level requirements (e.g., the content has the right Content Binding ID, is associated with the correct permissions, etc.). The recipient's TAXII Back-end MAY still discard the content for any reason and is not required to inform the sender if this happens

 

In the case that has been described, the reason for rejection was outside the scope of TAXII (e.g., specific requirements at the data level), though TAXII does have facilities for communicating this kind of rejection within a Status Message - custom Status Types, custom Status Details, and a Message field.

 

I will note that there is a mechanism in TAXII to communicate these specific data requirements ahead of time: Content Bindings and Subtypes. Recall that the Content Binding indicates the type of content (e.g., “STIX 1.1.1”) and the Subtype indicates a specific subset of that supported content (e.g., “Only content that meets the best practices”). Note that STIX profiles can be used as Subtypes. As a result, it’s possible for a TAXII Server to say “I accept STIX 1.1.1 that meets the best practices” by using a Content Binding for STIX and a Subtype that indicates a profile that requires the best practices. There is a nicety here where it’s possible to create a standard TAXII Status Message that contains a Status Type of “Unsupported Message Binding” that lists the accepted STIX versions and profiles (using the Content Binding ID and Subtype concept). This does require the creation and use of a STIX profile.

 

I realize I’m going a bit long, so here’s the conclusion. Specific content-level errors (e.g., “You don’t have an ID on your indicator”) are largely out of scope for TAXII, but TAXII does have standardized mechanisms for handling common content-level errors (e.g., “That content was the wrong type”) and includes extension points for specific errors. Please comment if any of my text seems like it could be improved – I am commenting on the current state of TAXII; the future state of TAXII will be defined in part by community discussion.

 

Thank you.

-Mark

 

From: Josh Larkins [mailto:[hidden email]]
Sent: Friday, April 03, 2015 2:26 PM
To: stix-discussion-list Structured Threat Information Expression/ST
Subject: Re: [STIX] Signaling Local Policies

 

I appreciate everyone’s thoughts on this. I didn’t quite mean to start a small war, as I definitely agree with everyone else that the IDs are incredibly important. I don’t know if Soltra returns any more meaningful error than “nope” when our document was inserted, but from the customer’s one line snippet, I had no idea what the reason was. I was a bit disappointed to find out that our valid STIX for its current version (1.1.1) wasn’t “good enough” for Soltra.

 

Now I’ll go fix our STIX.

 

Josh

 

 

From: Jordan, Bret [[hidden email]]
Sent: Friday, April 03, 2015 2:01 PM
To: [hidden email]
Subject: Re: [STIX] Signaling Local Policies

 

Well said Eric, I agree.  As a TAXII best practice, the error messages coming back for bad STIX should be helpful.  This reminds me of days long ago about Supplicants giving very poor information as to why someone could not connect to the network, even though the supplicant either knew or had a very very good idea as to why.  

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303

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

 

On Apr 3, 2015, at 11:56 AM, Eric Burger <[hidden email]> wrote:

 

I am a firm believer in having MUSTs and MUST NOTs and few or no SHOULDs or MAYs. Moreover, for this particular item, if we do not use the ID, it means we cannot refer to the object independently, which means we are paying an enormous complexity tax with no benefit. I am not arguing about whether or not ID should be there. I think it should (must!). What I am saying is no one should need to ask “What’s up with Soltra?” when it rejects a legal STIX document. TAXII should be clear enough to an implementor that when Soltra rejects the document, it is immediately obvious what they need to do.

 

I’m not sure whether that is something lacking in TAXII or in what Soltra sends back.

 

I will take exception to an implementation “enforcing best practices” if that means a protocol failure. A response saying, “I don’t like that for my own reasons,” presuming the protocol lets you say that, is OK. A response saying, “What you gave me is not STIX” when it is STIX is not OK. That says the implementation is not STIX. That said, what I think we are in violent agreement over is that STIX (1) must require ID’s (per this thread, in STIX 2.0) and (2) the protocol machinery needs to be clear enough to let an implementation signal to a client why it rejects a legal document.

 

On Apr 3, 2015, at 1:16 PM, Jordan, Bret <[hidden email]> wrote:

 

Aharon +1..   Right now there is a lot of ways to generate loosey-goosey STIX and its children.  In STIX 2.0 I would like to see the best practices and other items be made requirements, basically tighten things a bit to make sure people generate good STIX.

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303

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

 

On Apr 3, 2015, at 9:30 AM, Aharon Chernin <[hidden email]> wrote:

 

This is disturbing. If Soltra does not accept a legal STIX document, Soltra is not a STIX processor. As one of my old CEO’s said, “There is nothing worse than almost compatible."


It's not as if we are embracing and extending STIX. We are simply enforcing best practices. It's highly likely that these best practices will be made requirements in future releases of STIX (>2.x). We aren't here to prove that we can build a system that can accept poorly formatted STIX, we are here to help our community. One of the ways we do this is by requiring that producers make good STIX. In fact, this is the first time we have received a complaint due to our enforcement of STIX best practices.

 

As for our rejection in TAXII, we do create a TAXII message that states why the content was rejected.

 

Aharon Chernin
CTO

SOLTRA | An FS-ISAC & DTCC Company

18301 Bermuda green Dr

Tampa, fl 33647

813.470.2173 | [hidden email]


From: Eric Burger <[hidden email]>
Sent: Friday, April 3, 2015 10:55 AM
To: [hidden email]
Subject: [STIX] Signaling Local Policies

 

This is disturbing. If Soltra does not accept a legal STIX document, Soltra is not a STIX processor. As one of my old CEO’s said, “There is nothing worse than almost compatible."

 

We may have found a missing feature (a.k.a. bug) in TAXII. It is fine for a site to implement a policy that rejects what would be legal STIX documents. For example, if that site requires IDs and bars com.example.mumble in a STIX document. However, if the implementation cannot signal why it rejected the document (e.g., “Fails local policy check”), then we do not have interoperability, as shown by the initial exchange in this thread.

 

On Apr 3, 2015, at 7:16 AM, Aharon Chernin <[hidden email]> wrote:

 

I am responding back to the list as I think this is information that can help a lot of other folks on here:

 

* Including IDs in your STIX objects is a documented STIX best practice (http://stixproject.github.io/documentation/suggested-practices/). Which means it will still be valid STIX even if you don't follow the best practices. However, we have made the decision to reject content without IDs. If you add them to your objects the content should import into our product.

* When you do add IDs, make sure you don't use "example" as your namespace prefix. We also reject content that uses the example namespace.

* Whenever possible, provide titles and descriptions for objects. This gives us, and your customers, a way to browse the content you just sent them. Titles and Descriptions are one of the few human readable elements that exist between all the objects.

 

 

Aharon Chernin
CTO

SOLTRA | An FS-ISAC & DTCC Company

18301 Bermuda green Dr

Tampa, fl 33647

813.470.2173 | [hidden email]


From: Aharon Chernin <[hidden email]>
Sent: Thursday, April 2, 2015 6:40 PM
To: [hidden email]
Subject: Re: [STIX] attn Soltra

 

Can you email me an example document that fails to load? Please send off list.

Aharon

Sent using OWA for iPhone 


From: Josh Larkins <[hidden email]>
Sent: Thursday, April 2, 2015 5:10:11 PM
To: [hidden email]
Subject: [STIX] attn Soltra

 

Could someone from Soltra contact me? I have a customer who says Soltra Edge is rejecting a STIX doc that my company produced, but the python STIX validator 1.1.1.2 says it’s valid. I’d like to figure out why it’s being rejected.

 

Josh Larkins

Sr. Threat Intelligence Analyst

Malcovery Security