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

classic Classic list List threaded Threaded
1 message 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 bring the wider community up to speed on the very vibrant discussion going on about the implementation of the CTI standard on the standards only list.  

You can review the discussion in the archives.  But to comment on it, if you are not part of OASIS, please comment here on the community cti-users list.


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 31, 2015 at 09:11:32 MDT
To: Mark Clancy <[hidden email]>
Cc: Ivan Kirillov <[hidden email]>, "Jonathan Bush (DTCC)" <[hidden email]>, Jason Keirstead <[hidden email]>, Aharon Chernin <[hidden email]>, "[hidden email]" <[hidden email]>

This is a really good point Mark...

Part of the problem as I see it, is we do not have good tools to make use of the data.  We do not have good BigData solutions, we do not have easy to use analytic solutions, we do not have good UIs that allow you to correlate and do something with the data. There are no tools for the investigators to use that allow them to easily correlate their findings with specific people inside of their world of trust and compare that data against data they actually see on their network.

Once we get tools and APPs built to use the data, and collaborate on the data, then we will be able to move beyond just IOCs (lists of hashes, filenames, IP addresses, and URLs).  

This means we need a TON of code written and lots of API toolkits for this stuff in every language out there.  This is why I have been pushing so hard for this for so long.  We need developers wanting to write apps to use this technology.  Without the tools and apps, it is just yet-another-cti-standard.  


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 31, 2015, at 08:58, Mark Clancy <[hidden email]> wrote:

There is a more fundamental issue than the technology stack. I'll phrase this in terms of economics.  Is the CTI working group managing to Supply or Demand or hopefully some of both?*

This debate while productive to a point is largely about how to increase the Supply of signalling technology on the wire, not the Demand to manage complex threats by people trying to avoid being victimized.  The former is about what is put into products by suppliers to make their life easier and the later is what customer will pay for to solve their problems. 

Yes they both matter but by volume the vast amount of electrons on the list have been dealing with Supply side needs not Demand needs.  I am all about the Demand...

Lets have some discussion on how to address the needs for Demand side of the story too. 

 *IF* we took what existed now, tweaked, and JSON'd it we don't solve the problem of IOCs still being the bulk of the CTI story. This does not help our CTI standards tackle how we leave on the table ways into increase adversary costs by making their methodology not the IOCs the thing the miscreants can't reuse because the ecosystem knows how to counter it via sharing.

-Mark

 * I am not an economist and I did not stay at whatever hotel makes you an expert on everything so take the metaphor with several grains of salt..

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.
 



From: Jordan, Bret <[hidden email]>
Sent: Monday, August 31, 2015 10:34 AM
To: Ivan Kirillov
Cc: Jonathan Bush (DTCC); Jason Keirstead; Aharon Chernin; Mark Clancy; [hidden email]
Subject: Re: [cti] Thoughts on STIX and some of the other threads on this list
 
I agree 100%...  Lets define a set of core values for this group that include things like simplicity and one-way-of-doing-things... 

Just the act of moving to JSON will cause a lot of simplification to happen, we learned this when we moved TAXII from XML to JSON. Now JSON TAXII is so MUCH easier to understand and use.

Lets start today, let commit today, let move this group forward.  Lets make it so easy for the community to adopt our standards that there is no reason for them not to.   

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 31, 2015, at 08:19, Kirillov, Ivan A. <[hidden email]> wrote:

What about having just python-stix/cybox serve as the reference implementation? I guess I just don’t see why we must have an equivalent implementation for every mainstream language, especially if we make implementation easier by eliminating some of the existing ambiguities in complexities in the language. 

On that note, while all of the talk around JSON is great (and I'm personally for it), it really needs to happen in tandem with reduction in complexity/ambiguity, as otherwise we’re just pushing around the same flawed data structures but in a different serialization. Accordingly, if can come to an agreement that this (JSON/other serializations + simplification) is one of the CTI’s priorities for the next release of STIX and CybOX, it would likely go a long way towards alleviating some of the broader community’s concerns around our efforts.

-Ivan

From: <[hidden email]> on behalf of "Bush, Jonathan"
Date: Monday, August 31, 2015 at 9:55 AM
To: 'Jason Keirstead'
Cc: Bret Jordan, Aharon Chernin, Mark Clancy, "[hidden email]"
Subject: RE: [cti] Thoughts on STIX and some of the other threads on this list

Very fair point Jason – Do we have anyone like Mitre contracted who can maintain a set of libraries?  That could be a heavy lift.
 
If we have that, I would suggest we work with them to build out the full functionality we need, not just skeleton libraries like we have now.
If we don’t have that, I would go back to the thought that our scope should be limited to a conceptual model only.  We have to make a choice here, and it has big implications.
 
From: [hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent: Monday, August 31, 2015 9:22 AM
To: Bush, Jonathan
Cc: 'Jordan, Bret'; Aharon Chernin; Mark Clancy; [hidden email]
Subject: RE: [cti] Thoughts on STIX and some of the other threads on this list
 
/ If we abstract out the complexity what we have to ‘learn’ is a set of API calls. This is how modern software is built – Not on data formats but on API formats. /

This sounds good in principle, but in order for this to work in practice the OASIS CTI would have to be responsible not just for the STIX standard, but also reference bindings and documentation for STIX in several mainstream languages, I would say Python, Java, and C++ at a minimum. This would be a very large body of work to undertake and maintain... even the current reference Python bindings by MITRE are pretty bare-bones (they don't "make anything simple", it's really just a data binding - not really what is required for a widely used reference library) and I don't think the Java ones were ever completed. If you don't have an easy to use library set for everyone to use, then the format of the data is very important.

I will give an example to the list from my own experience. I had to add some STIX support to a system in Python that was running Python 2.6, which I do not have any control over, and did not ship with a C++ compiler. As a result, the MITRE reference libraries have a dependancy chain that ends up with something needing C++ linking to libraries to build - so I could not use them at all. I ended up having to write my own STIX parser in Python from the XML... which was quite eye-opening as to how convoluted STIX can be to work with, and I had all of Python to help me. I can't even imagine the job of someone writing a STIX XML parser in C++ based on the 1.1 specification alone.

/ I honestly hate them all, even the XML format. /

Well I know few data formats I have any particular "love" for :) My main beef with the XML format has nothing to do with how it looks, it has to do with markup verboseness and efficiency on the wire. 

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

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


<image001.gif>"Bush, Jonathan" ---2015/08/28 09:06:30 PM---Bret - I think my point still remains - Why should I have to learn ANY specific implementation forma

From: "Bush, Jonathan" <[hidden email]>
To: "'Jordan, Bret'" <[hidden email]>, Aharon Chernin <[hidden email]>
Cc: Mark Clancy <[hidden email]>, "[hidden email]" <[hidden email]>
Date: 2015/08/28 09:06 PM
Subject: RE: [cti] Thoughts on STIX and some of the other threads on this list
Sent by: <[hidden email]>




Bret – I think my point still remains – Why should I have to learn ANY specific implementation format? I honestly hate them all, even the XML format.
If we abstract out the complexity what we have to ‘learn’ is a set of API calls. This is how modern software is built – Not on data formats but on API formats.

From:[hidden email] [[hidden email]] On Behalf Of Jordan, Bret
Sent:
 Friday, August 28, 2015 7:38 PM
To:
 Aharon Chernin
Cc:
 Mark Clancy; [hidden email]
Subject:
 Re: [cti] Thoughts on STIX and some of the other threads on this list


Consumers use tools, hopefully they never see the format. Vendors, web developers, app developers, and open source developers write the tools. They are the ones that have to pay the XML tax. 

Given the progress that Facebook is making I can begin to see a need for vendors even Soltra Edge to start supporting their threat exchange format. 

My question still stands.. Will anyone not use STIX if we stopped doing XML? Follow on, how many more vendors and developers will we gain if we adopted JSON? 

Let's just use Intelworks' JSON STIX format and be done with it.

Bret 



Sent from my Commodore 64

<trimmed>

 


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.
<image001.gif>



signature.asc (859 bytes) Download Attachment