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