[cti-users] Fwd: [cti] Thoughts on STIX and some of the other threads on this list

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

[cti-users] Fwd: [cti] Thoughts on STIX and some of the other threads on this list

Jordan, Bret
Cross posting to the broader community..


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." 

Begin forwarded message:

From: Bret Jordan <[hidden email]>
Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list
Date: August 28, 2015 at 16:22:35 MDT
To: Mark Clancy <[hidden email]>

Format impacts adoption, plain and simple.  Why do you think Facebook went off and did their solution in JSON?  Why does Soltra do JSON on the back end?  Why does Intelworks do JSON? Why are other threat intel solutions doing JSON?  Why are other yet to be released solutions similar to Soltra Edge that have not yet been announced also doing JSON?

As I have said before, all of the code that has been written and that will be written by this group, in the end, will account for probably only 5% of the total code that needs to be written.  If those web developers, app developers, and open source developers that are going to write the other 95% hate the format, and refuse to work with it, then they will not write code for it.  The Python libraries only go so far.  We need libraries in C, C++, Objective-C, SWIFT, PHP, Ruby, Andoriod-Java, C#, etc etc etc..   

Everyone that does not think this is an issue, please write some C code using existing STIX in XML..  Then lets talk....


Let me copy in some of my thoughts from another thread and down grade my own TLP as well.

Most vendors I talk too, ones that we would want to be on board with STIX and TAXII, always complain about XML.  I did not start this effort with a bias against XML, as I too was an academic.  But everything I hear, and ever vendor I talk to says the same thing....  So we should just do it and be done with it. 

The religious debate is one-sides for sure.  Meaning, people will avoid using STIX because of XML.  But I doubt anyone at the end of the day would care if we stopped using XML.  There is no one out there that is pushing for XML and will refuse to use STIX if it is NOT in XML.

Lets solve this problem and be done with it.  


Thanks,

Bret



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

On Aug 28, 2015, at 15:29, Mark Clancy <[hidden email]> wrote:

I posted this to another threat intel list and it probably makes sense to have y'all see my comments.I can't copy the whole thread from the other list due to their rules (everyone else's comments are TLP amber, but I can downgrade my own TLP. ). It is a group of people who live and breath CTI on the defending things from badness side. I bet there is a good amount of overlap


-SNIP-


1.      Structure and Context are what we need.  Format is just that format.  XML vs. JSON etc don’t matter in the end. Heck CSV file had the same problem.  If the data is flat than the human puncher has to build the context so miscreants get a free lunch again. If every spreadsheet, JSON, or XML  source has different columns or definitions we have a bloody mess. (Oh wait we did have that mess already and the approach was to say lets create a standard to fight that out... )  I still have not seen notepad die as an essential tool to defend a network as cut & paste is still state of the art in transporting threat data to security tools in most shops…


2.      STIX regardless if over XML/JSON should not be manufactured/consumed by a human but a machine. 


3.      If you are hand crafting STIX then stop and go back to spreadsheets for your cut, paste, share, & consume fix.  If spreadsheets in to JSON is your thing then do that too, but don’t confuse those home brew formats as being “structured”


4.      If you are writing code to do it then STIX vs. JSON probably doesn’t really matter as each has their plus minus and there are libraries to make STIX go between XML and JSON anyway. I view this fundamentally as a Coke vs. Pepsi kind of debate as to which cola you like best. Both have plenty of sugar and caffeine, but in the end they do the same thing…


5.      STIX Complexity – yeah this is a mixed blessing. Lots of way to do related things. The real problem is there is no implementation guidance and most implementations are just dealing with IOCs (indicators/observables) and all the interesting and useful context doesn’t show up in STIX output today and then plenty of people trying do that wrong.  


a.      A federal law enforcement group for example confused “indicator” and instead published everything as “incidents” in their STIX package

b.      An ISAC published a really decent description of a Threat Actor, but did it as an Indicator

c.      Lots  groups publish one Observable per Indicator instead of linking them

d.      Almost none of the OSINT has anything other than Observables, Indicators, or TTPs today.

e.      Simple conventions like what should I put in the “Short Description” vs. “Description” fields.  Should these overlap or be unique?


6.      One thing I am going to try to do with OASIS is on the “implementation and usage” side vs. schema or format issue.  Plenty of passionate technical folks beating that drum, but I am looking at the practitioner usage and finding all we need today if we just agree on HOW we do it within the spec.


7.      I am working on getting OSINT into properly composed STIX objects linking Observable, to Indicator, to Campaign, to TTP, to Threat Actor etc.  IMHO this is a most excellent use of university programs under fair use provisions or open source licenses. I’ll put some Soltra money and my own personal funds towards that objective. So happy to help coordinate others interest on this too.




Mark Clancy
Chief Executive Officer
SOLTRA | An FS-ISAC and DTCC Company
+1.813.470.2400 office | +1.610.659.6671 US mobile |  +44 7823 626 535  UK mobile
 
One organization's incident becomes everyone's defense.
 



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

[cti-users] RE: [cti] Thoughts on STIX and some of the other threads on this list

Ben Johnson

Bret,

 

Nice post.  I will say that in the 30+ Technology integrations/connectors/feeds that we have, our STIX/TAXII connector is the only code that requires XML (and it mostly just converts from XML to a JSON format we natively import).  All the other threat feed and API integrations we have built leverage JSON as the data format.

 

We heavily support an initiative to replace XML with JSON or at least to add JSON as an alternative for STIX.  We’re happy to help.

 

Cheers,

Ben

 

 

Ben Johnson | Chief Security Strategist

Bit9 + Carbon Black

Endpoint Threat Prevention | Detection and Response in Seconds

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Jordan, Bret
Sent: Friday, August 28, 2015 5:31 PM
To: [hidden email]
Subject: [cti-users] Fwd: [cti] Thoughts on STIX and some of the other threads on this list

 

Cross posting to the broader community..

 

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." 



Begin forwarded message:

 

From: Bret Jordan <[hidden email]>

Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list

Date: August 28, 2015 at 16:22:35 MDT

To: Mark Clancy <[hidden email]>

 

Format impacts adoption, plain and simple.  Why do you think Facebook went off and did their solution in JSON?  Why does Soltra do JSON on the back end?  Why does Intelworks do JSON? Why are other threat intel solutions doing JSON?  Why are other yet to be released solutions similar to Soltra Edge that have not yet been announced also doing JSON?

 

As I have said before, all of the code that has been written and that will be written by this group, in the end, will account for probably only 5% of the total code that needs to be written.  If those web developers, app developers, and open source developers that are going to write the other 95% hate the format, and refuse to work with it, then they will not write code for it.  The Python libraries only go so far.  We need libraries in C, C++, Objective-C, SWIFT, PHP, Ruby, Andoriod-Java, C#, etc etc etc..   

 

Everyone that does not think this is an issue, please write some C code using existing STIX in XML..  Then lets talk....

 

 

Let me copy in some of my thoughts from another thread and down grade my own TLP as well.

 

Most vendors I talk too, ones that we would want to be on board with STIX and TAXII, always complain about XML.  I did not start this effort with a bias against XML, as I too was an academic.  But everything I hear, and ever vendor I talk to says the same thing....  So we should just do it and be done with it. 

 

The religious debate is one-sides for sure.  Meaning, people will avoid using STIX because of XML.  But I doubt anyone at the end of the day would care if we stopped using XML.  There is no one out there that is pushing for XML and will refuse to use STIX if it is NOT in XML.

 

Lets solve this problem and be done with it.  

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

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

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

 

On Aug 28, 2015, at 15:29, Mark Clancy <[hidden email]> wrote:

 

I posted this to another threat intel list and it probably makes sense to have y'all see my comments.I can't copy the whole thread from the other list due to their rules (everyone else's comments are TLP amber, but I can downgrade my own TLP. ). It is a group of people who live and breath CTI on the defending things from badness side. I bet there is a good amount of overlap

 

-SNIP-

 

1.      Structure and Context are what we need.  Format is just that format.  XML vs. JSON etc don’t matter in the end. Heck CSV file had the same problem.  If the data is flat than the human puncher has to build the context so miscreants get a free lunch again. If every spreadsheet, JSON, or XML  source has different columns or definitions we have a bloody mess. (Oh wait we did have that mess already and the approach was to say lets create a standard to fight that out... )  I still have not seen notepad die as an essential tool to defend a network as cut & paste is still state of the art in transporting threat data to security tools in most shops…

 

2.      STIX regardless if over XML/JSON should not be manufactured/consumed by a human but a machine. 

 

3.      If you are hand crafting STIX then stop and go back to spreadsheets for your cut, paste, share, & consume fix.  If spreadsheets in to JSON is your thing then do that too, but don’t confuse those home brew formats as being “structured”

 

4.      If you are writing code to do it then STIX vs. JSON probably doesn’t really matter as each has their plus minus and there are libraries to make STIX go between XML and JSON anyway. I view this fundamentally as a Coke vs. Pepsi kind of debate as to which cola you like best. Both have plenty of sugar and caffeine, but in the end they do the same thing…

 

5.      STIX Complexity – yeah this is a mixed blessing. Lots of way to do related things. The real problem is there is no implementation guidance and most implementations are just dealing with IOCs (indicators/observables) and all the interesting and useful context doesn’t show up in STIX output today and then plenty of people trying do that wrong.  

 

a.      A federal law enforcement group for example confused “indicator” and instead published everything as “incidents” in their STIX package

b.      An ISAC published a really decent description of a Threat Actor, but did it as an Indicator

c.      Lots  groups publish one Observable per Indicator instead of linking them

d.      Almost none of the OSINT has anything other than Observables, Indicators, or TTPs today.

e.      Simple conventions like what should I put in the “Short Description” vs. “Description” fields.  Should these overlap or be unique?

 

6.      One thing I am going to try to do with OASIS is on the “implementation and usage” side vs. schema or format issue.  Plenty of passionate technical folks beating that drum, but I am looking at the practitioner usage and finding all we need today if we just agree on HOW we do it within the spec.

 

7.      I am working on getting OSINT into properly composed STIX objects linking Observable, to Indicator, to Campaign, to TTP, to Threat Actor etc.  IMHO this is a most excellent use of university programs under fair use provisions or open source licenses. I’ll put some Soltra money and my own personal funds towards that objective. So happy to help coordinate others interest on this too.

 

 

 

Mark Clancy

Chief Executive Officer

SOLTRA | An FS-ISAC and DTCC Company

+1.813.470.2400 office | +1.610.659.6671 US mobile |  +44 7823 626 535  UK mobile

 

One organization's incident becomes everyone's defense.
 

 

 


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

[cti-users] RE: [cti] Thoughts on STIX and some of the other threads on this list

Sharfuddin, Ateeq
In reply to this post by Jordan, Bret

Why not write C libraries implementing STIX, TAXII, MAEC, etc. and simply write wrappers for these C libraries in other languages vs implementing them anew in each language?

 

With respect to XML vs JSON, how are you or the community proposing schema validation be performed on JSON?

 

Also, are you able to clarify what you mean by “please write some code in C using existing STIX in XML”? I did not follow what was meant by existing STIX in XML? Did you want some code in C that will output STIX using the available schemata?

 

“Why do you think Facebook went off and did their solution in JSON?  Why does Soltra do JSON on the back end?  Why does Intelworks do JSON? Why are other threat intel solutions doing JSON?  Why are other yet to be released solutions similar to Soltra Edge that have not yet been announced also doing JSON?”


The previous is actually a fallacy in argument—argumentum ad populum. Just because many do it does not necessarily make it an appropriate solution in all settings or even this particular setting.

 

I remember there were some considerations that went in (particularly validation) when XML was initially chosen for these.

 

I am not in a pro-XML or pro-JSON camp yet, so convince me.

 

 

 

Ateeq Sharfuddin

Director, R&D

ManTech International Corporation

 

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Jordan, Bret
Sent: Friday, August 28, 2015 6:31 PM
To: [hidden email]
Subject: [cti-users] Fwd: [cti] Thoughts on STIX and some of the other threads on this list

 

Cross posting to the broader community..

 

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." 



Begin forwarded message:

 

From: Bret Jordan <[hidden email]>

Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list

Date: August 28, 2015 at 16:22:35 MDT

To: Mark Clancy <[hidden email]>

 

Format impacts adoption, plain and simple.  Why do you think Facebook went off and did their solution in JSON?  Why does Soltra do JSON on the back end?  Why does Intelworks do JSON? Why are other threat intel solutions doing JSON?  Why are other yet to be released solutions similar to Soltra Edge that have not yet been announced also doing JSON?

 

As I have said before, all of the code that has been written and that will be written by this group, in the end, will account for probably only 5% of the total code that needs to be written.  If those web developers, app developers, and open source developers that are going to write the other 95% hate the format, and refuse to work with it, then they will not write code for it.  The Python libraries only go so far.  We need libraries in C, C++, Objective-C, SWIFT, PHP, Ruby, Andoriod-Java, C#, etc etc etc..   

 

Everyone that does not think this is an issue, please write some C code using existing STIX in XML..  Then lets talk....

 

 

Let me copy in some of my thoughts from another thread and down grade my own TLP as well.

 

Most vendors I talk too, ones that we would want to be on board with STIX and TAXII, always complain about XML.  I did not start this effort with a bias against XML, as I too was an academic.  But everything I hear, and ever vendor I talk to says the same thing....  So we should just do it and be done with it. 

 

The religious debate is one-sides for sure.  Meaning, people will avoid using STIX because of XML.  But I doubt anyone at the end of the day would care if we stopped using XML.  There is no one out there that is pushing for XML and will refuse to use STIX if it is NOT in XML.

 

Lets solve this problem and be done with it.  

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

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

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

 

On Aug 28, 2015, at 15:29, Mark Clancy <[hidden email]> wrote:

 

I posted this to another threat intel list and it probably makes sense to have y'all see my comments.I can't copy the whole thread from the other list due to their rules (everyone else's comments are TLP amber, but I can downgrade my own TLP. ). It is a group of people who live and breath CTI on the defending things from badness side. I bet there is a good amount of overlap

 

-SNIP-

 

1.      Structure and Context are what we need.  Format is just that format.  XML vs. JSON etc don’t matter in the end. Heck CSV file had the same problem.  If the data is flat than the human puncher has to build the context so miscreants get a free lunch again. If every spreadsheet, JSON, or XML  source has different columns or definitions we have a bloody mess. (Oh wait we did have that mess already and the approach was to say lets create a standard to fight that out... )  I still have not seen notepad die as an essential tool to defend a network as cut & paste is still state of the art in transporting threat data to security tools in most shops…

 

2.      STIX regardless if over XML/JSON should not be manufactured/consumed by a human but a machine. 

 

3.      If you are hand crafting STIX then stop and go back to spreadsheets for your cut, paste, share, & consume fix.  If spreadsheets in to JSON is your thing then do that too, but don’t confuse those home brew formats as being “structured”

 

4.      If you are writing code to do it then STIX vs. JSON probably doesn’t really matter as each has their plus minus and there are libraries to make STIX go between XML and JSON anyway. I view this fundamentally as a Coke vs. Pepsi kind of debate as to which cola you like best. Both have plenty of sugar and caffeine, but in the end they do the same thing…

 

5.      STIX Complexity – yeah this is a mixed blessing. Lots of way to do related things. The real problem is there is no implementation guidance and most implementations are just dealing with IOCs (indicators/observables) and all the interesting and useful context doesn’t show up in STIX output today and then plenty of people trying do that wrong.  

 

a.      A federal law enforcement group for example confused “indicator” and instead published everything as “incidents” in their STIX package

b.      An ISAC published a really decent description of a Threat Actor, but did it as an Indicator

c.      Lots  groups publish one Observable per Indicator instead of linking them

d.      Almost none of the OSINT has anything other than Observables, Indicators, or TTPs today.

e.      Simple conventions like what should I put in the “Short Description” vs. “Description” fields.  Should these overlap or be unique?

 

6.      One thing I am going to try to do with OASIS is on the “implementation and usage” side vs. schema or format issue.  Plenty of passionate technical folks beating that drum, but I am looking at the practitioner usage and finding all we need today if we just agree on HOW we do it within the spec.

 

7.      I am working on getting OSINT into properly composed STIX objects linking Observable, to Indicator, to Campaign, to TTP, to Threat Actor etc.  IMHO this is a most excellent use of university programs under fair use provisions or open source licenses. I’ll put some Soltra money and my own personal funds towards that objective. So happy to help coordinate others interest on this too.

 

 

 

Mark Clancy

Chief Executive Officer

SOLTRA | An FS-ISAC and DTCC Company

+1.813.470.2400 office | +1.610.659.6671 US mobile |  +44 7823 626 535  UK mobile

 

One organization's incident becomes everyone's defense.
 

 

 




This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
Reply | Threaded
Open this post in threaded view
|

[cti-users] RE: [cti] Thoughts on STIX and some of the other threads on this list

Cory Casanave

Or, generate the API in multiple languages that can bind to multiple physical formats (XMJ, JSON, RDF, Whatever), thus avoiding a separate layer and having additional flexibility to make it easy for each language’s developers.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Sharfuddin, Ateeq
Sent: Tuesday, September 08, 2015 10:48 PM
To: [hidden email]
Subject: [cti-users] RE: [cti] Thoughts on STIX and some of the other threads on this list

 

Why not write C libraries implementing STIX, TAXII, MAEC, etc. and simply write wrappers for these C libraries in other languages vs implementing them anew in each language?

 

With respect to XML vs JSON, how are you or the community proposing schema validation be performed on JSON?

 

Also, are you able to clarify what you mean by “please write some code in C using existing STIX in XML”? I did not follow what was meant by existing STIX in XML? Did you want some code in C that will output STIX using the available schemata?

 

“Why do you think Facebook went off and did their solution in JSON?  Why does Soltra do JSON on the back end?  Why does Intelworks do JSON? Why are other threat intel solutions doing JSON?  Why are other yet to be released solutions similar to Soltra Edge that have not yet been announced also doing JSON?”


The previous is actually a fallacy in argument—argumentum ad populum. Just because many do it does not necessarily make it an appropriate solution in all settings or even this particular setting.

 

I remember there were some considerations that went in (particularly validation) when XML was initially chosen for these.

 

I am not in a pro-XML or pro-JSON camp yet, so convince me.

 

 

 

Ateeq Sharfuddin

Director, R&D

ManTech International Corporation

 

 

 

From: [hidden email] [[hidden email]] On Behalf Of Jordan, Bret
Sent: Friday, August 28, 2015 6:31 PM
To: [hidden email]
Subject: [cti-users] Fwd: [cti] Thoughts on STIX and some of the other threads on this list

 

Cross posting to the broader community..

 

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." 

 

Begin forwarded message:

 

From: Bret Jordan <[hidden email]>

Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list

Date: August 28, 2015 at 16:22:35 MDT

To: Mark Clancy <[hidden email]>

 

Format impacts adoption, plain and simple.  Why do you think Facebook went off and did their solution in JSON?  Why does Soltra do JSON on the back end?  Why does Intelworks do JSON? Why are other threat intel solutions doing JSON?  Why are other yet to be released solutions similar to Soltra Edge that have not yet been announced also doing JSON?

 

As I have said before, all of the code that has been written and that will be written by this group, in the end, will account for probably only 5% of the total code that needs to be written.  If those web developers, app developers, and open source developers that are going to write the other 95% hate the format, and refuse to work with it, then they will not write code for it.  The Python libraries only go so far.  We need libraries in C, C++, Objective-C, SWIFT, PHP, Ruby, Andoriod-Java, C#, etc etc etc..   

 

Everyone that does not think this is an issue, please write some C code using existing STIX in XML..  Then lets talk....

 

 

Let me copy in some of my thoughts from another thread and down grade my own TLP as well.

 

Most vendors I talk too, ones that we would want to be on board with STIX and TAXII, always complain about XML.  I did not start this effort with a bias against XML, as I too was an academic.  But everything I hear, and ever vendor I talk to says the same thing....  So we should just do it and be done with it. 

 

The religious debate is one-sides for sure.  Meaning, people will avoid using STIX because of XML.  But I doubt anyone at the end of the day would care if we stopped using XML.  There is no one out there that is pushing for XML and will refuse to use STIX if it is NOT in XML.

 

Lets solve this problem and be done with it.  

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

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

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

 

On Aug 28, 2015, at 15:29, Mark Clancy <[hidden email]> wrote:

 

I posted this to another threat intel list and it probably makes sense to have y'all see my comments.I can't copy the whole thread from the other list due to their rules (everyone else's comments are TLP amber, but I can downgrade my own TLP. ). It is a group of people who live and breath CTI on the defending things from badness side. I bet there is a good amount of overlap

 

-SNIP-

 

1.      Structure and Context are what we need.  Format is just that format.  XML vs. JSON etc don’t matter in the end. Heck CSV file had the same problem.  If the data is flat than the human puncher has to build the context so miscreants get a free lunch again. If every spreadsheet, JSON, or XML  source has different columns or definitions we have a bloody mess. (Oh wait we did have that mess already and the approach was to say lets create a standard to fight that out... )  I still have not seen notepad die as an essential tool to defend a network as cut & paste is still state of the art in transporting threat data to security tools in most shops…

 

2.      STIX regardless if over XML/JSON should not be manufactured/consumed by a human but a machine. 

 

3.      If you are hand crafting STIX then stop and go back to spreadsheets for your cut, paste, share, & consume fix.  If spreadsheets in to JSON is your thing then do that too, but don’t confuse those home brew formats as being “structured”

 

4.      If you are writing code to do it then STIX vs. JSON probably doesn’t really matter as each has their plus minus and there are libraries to make STIX go between XML and JSON anyway. I view this fundamentally as a Coke vs. Pepsi kind of debate as to which cola you like best. Both have plenty of sugar and caffeine, but in the end they do the same thing…

 

5.      STIX Complexity – yeah this is a mixed blessing. Lots of way to do related things. The real problem is there is no implementation guidance and most implementations are just dealing with IOCs (indicators/observables) and all the interesting and useful context doesn’t show up in STIX output today and then plenty of people trying do that wrong.  

 

a.      A federal law enforcement group for example confused “indicator” and instead published everything as “incidents” in their STIX package

b.      An ISAC published a really decent description of a Threat Actor, but did it as an Indicator

c.      Lots  groups publish one Observable per Indicator instead of linking them

d.      Almost none of the OSINT has anything other than Observables, Indicators, or TTPs today.

e.      Simple conventions like what should I put in the “Short Description” vs. “Description” fields.  Should these overlap or be unique?

 

6.      One thing I am going to try to do with OASIS is on the “implementation and usage” side vs. schema or format issue.  Plenty of passionate technical folks beating that drum, but I am looking at the practitioner usage and finding all we need today if we just agree on HOW we do it within the spec.

 

7.      I am working on getting OSINT into properly composed STIX objects linking Observable, to Indicator, to Campaign, to TTP, to Threat Actor etc.  IMHO this is a most excellent use of university programs under fair use provisions or open source licenses. I’ll put some Soltra money and my own personal funds towards that objective. So happy to help coordinate others interest on this too.

 

 

 

Mark Clancy

Chief Executive Officer

SOLTRA | An FS-ISAC and DTCC Company

+1.813.470.2400 office | +1.610.659.6671 US mobile |  +44 7823 626 535  UK mobile

 

One organization's incident becomes everyone's defense.
 

 

 

 



This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.