RE: [cti] Looking for Example Shell

["Mates, Jeffrey CIV DC3/DCCI" <Jeffrey.Mates@dc3.mil>]

I put together something quick based on Paul's excellent example document, but I can hold off on sending it out if there is concern about too much noise on the line.  

That said, you mentioned  that relationships weren't scaling correctly.  Are you referring to how they interact with version changes to base objects causing a relationship to take an unintended meaning, or a more basic computational issue?

Jeffrey Mates, Civ DC3/DCCI
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computer Scientist
Defense Cyber Crime Institute
jeffrey.mates@dc3.mil
410-694-4335

-----Original Message-----
From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Monday, March 21, 2016 4:27 PM
To: Mates, Jeffrey CIV DC3/DCCI
Cc: Paul Patrick; Wunder, John A.; cti@lists.oasis-open.org
Subject: [Non-DoD Source] Re: [cti] Looking for Example Shell

Give us about 2 more weeks to finish fleshing out the ideas needed to support Indicators and Sightings.  We should then have enough of the nuts and bolts working that we can do more sanity checking.  

Once again, everyone, please step back and look at what we are doing with a new set of eyes.  We need sanity checking to make sure what we are designing will work and will work at scale.  I do not want us to build the most beautiful thing ever, only to then find out it can not be implemented.

If you have people in your org that have not yet looked at STIX 2.0, please run some of it by them.  We want to hear examples of where they like the design and especially where they do not like the design.  It is important for us to hear that early on.

For example, one thing we have recently found is that we are overloading the concept of relationships to the point where they will fall apart at scale.



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 Mar 21, 2016, at 14:18, Mates, Jeffrey CIV DC3/DCCI <Jeffrey.Mates@dc3.mil> wrote:

	I agree, being able to go through an example was a huge help.  If no one objects I will see about putting together an example of what some of this might look like using the node link model as well.
	
	Jeffrey Mates, Civ DC3/DCCI
	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	Computer Scientist
	Defense Cyber Crime Institute
	jeffrey.mates@dc3.mil
	410-694-4335
	
	
	-----Original Message-----
	From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Jordan, Bret
	Sent: Monday, March 21, 2016 4:04 PM
	To: Paul Patrick
	Cc: Mates, Jeffrey CIV DC3/DCCI; Wunder, John A.; cti@lists.oasis-open.org
	Subject: [Non-DoD Source] Re: [cti] Looking for Example Shell
	
	Yes, having something we can actually touch and feel and see is CRITICAL...  And we all thank you for doing this Paul.  It is really going to make things come together much faster.  
	
	
	
	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 Mar 21, 2016, at 13:57, Paul Patrick <ppatrick@isightpartners.com> wrote:
	
	Well said Bret.
	
	I’ve been trying to keep the sample updated as consensus is made as I and others have found it useful to see a more complete example as a means to better understand how things fit together.
	
	
	Paul P
	
	
	From: <cti@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
	Date: Monday, March 21, 2016 at 3:53 PM
	To: "Mates, Jeffrey CIV DC3/DCCI" <Jeffrey.Mates@dc3.mil>
	Cc: "Wunder, John A." <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
	Subject: Re: [cti] Looking for Example Shell
	
	
	
	Great points Jeffrey..... 
	
	Please keep in mind the iSight example is just a line in the sand of where we thought we were at, prior to RSA.  We wanted something to show. This does NOT mean, this will be the final look-n-feel.  We are pushing hard to solidify that, but we are not yet there.  
	
	In regards to TAXII, that is yet to be determined.  I can see a use case where you might specify an IP address to query for, and specify certain TLOs you want... I can see a case for sending you a blob (purposefully not using certain nomenclature to avoid assumption) STIX data based on your query.  
	
	We really want to make sure TAXII 2.0 meets peoples needs.  If there are things you MUST have, please let us know so we can work them in to the design.  
	
	
	
	
	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 Mar 21, 2016, at 13:38, Mates, Jeffrey CIV DC3/DCCI <Jeffrey.Mates@dc3.mil> wrote:
	
	Thanks for the clarification and documentation on this.  One thing I noticed in the iSight example is that Observation is that observable to observable relationships seem to break away from the CTI Common implementation of relationship.  Since these aren't being stored with the rest of the relationships at the top of the document and they don't refer to the container name as part of their ID.  So I'm a bit unclear how you would specify that a threat actor was associated with an observable.
	
	Also for your TAXII example would this still return TLOs for related objects?  For example when querying for an IPv4 address would it return every file that beaconed to a domain resolved to that IP?
	
	Jeffrey Mates, Civ DC3/DCCI
	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	Computer Scientist
	Defense Cyber Crime Institute
	jeffrey.mates@dc3.mil
	410-694-4335
	
	
	-----Original Message-----
	From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Jordan, Bret
	Sent: Monday, March 21, 2016 3:29 PM
	To: Wunder, John A.
	Cc: Mates, Jeffrey CIV DC3/DCCI; cti@lists.oasis-open.org
	Subject: [Non-DoD Source] Re: [cti] Looking for Example Shell
	
	Jeffrey,
	
	In TAXII land you also, more than likely be able to just ask for an Indicator or other TLO, without the overhead of the package.  So something like:
	
	{
	 "type": "indicator",
	 ...
	}
	
	
	
	
	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 Mar 21, 2016, at 13:18, Wunder, John A. <jwunder@mitre.org> wrote:
	
	Take a look here for the working definition of a package: https://docs.google.com/document/d/1YcEtyUGdFkJIPdDZ7K-mHbvjFt-5pOL2EIw_ZJuqNpM/edit#heading=h.c9oxowopqs2 <https://docs.google.com/document/d/1YcEtyUGdFkJIPdDZ7K-mHbvjFt-5pOL2EIw_ZJuqNpM/edit#heading=h.c9oxowopqs2> 
	
	As you can probably see, it’s essentially your former suggestion. We’ve had discussions about it though and I’ve argued the latter, mainly for ease of use. Bottom line is that we haven’t really decided, and have gone with the 1.x approach for the time being.
	
	
	
	Also, Paul Patrick from iSight has provided this notional example: http://taxii2-demo.soltra.com/taxii/mygroup/collections/mycollection/packages/package--3b3441de-8bf2-409e-a7e8-8f296f385057 <http://taxii2-demo.soltra.com/taxii/mygroup/collections/mycollection/packages/package--3b3441de-8bf2-409e-a7e8-8f296f385057> 
	
	In terms of validation…because of our `type` keyword it’s actually pretty easy to validate. The challenge is on understanding the validation message, because what you’ll get back is: you didn’t provide an attack pattern OR a malware OR an indicator OR a threat actor, etc. and it’s up to you to figure out which you actually wanted.
	
	John
	
	On 3/21/16, 2:55 PM, "Mates, Jeffrey CIV DC3/DCCI" <cti@lists.oasis-open.org on behalf of Jeffrey.Mates@dc3.mil> wrote:
	
	
	
	I have been trying to make sure I'm up to date on what a STIX 2.0 document
	will look like, and while there is a great deal of information about
	particular object types and common attributes I haven't had much luck
	finding an example of what the shell of a document will look like.  Does
	anyone know if we have a generally agreed upon sample of this somewhere?
	
	So far I have heard two different visions of STIX 2.0 the first more aligns
	to STIX 1.X and roughly maps to a json format of:
	{
	Header: [],
	Observables: [],
	Indicators: [], ...
	Relationships: []
	}
	
	The second moves to a node link model along the lines of:
	
	{
	Header: [],
	Objects: [],
	Relationships: []
	}
	
	I think that the second model makes lookups simpler when resolving
	relationships while also making adding new object types easier, but also may
	introduce additional challenges when attempting to validate the JSON's
	schema.
	
	I haven't found confirmation on what has been generally agreed upon or if a
	consensus has been reached.
	
	Jeffrey Mates, Civ DC3/DCCI
	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	Computer Scientist
	Defense Cyber Crime Institute
	jeffrey.mates@dc3.mil
	410-694-4335

Attachment: smime.p7s
Description: S/MIME cryptographic signature