The work done with the STIX COA proposal that connected action to intelligence has several use cases defined.
This proposal was not complete (by far) but did introduce some of the connections that Shawn is suggesting.
(Or at least my understanding of his thoughts).
Allan
From: "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Monday, September 10, 2018 at 1:52 PM
To: Andras Iklody <andras.iklody@gmail.com>, "shawn.p.riley@gmail.com" <shawn.p.riley@gmail.com>
Cc: "Forrest.B.Hare@saic.com" <Forrest.B.Hare@saic.com>, "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org>
Subject: Re: [cti-users] Re: [EXT] [cti-users] trying to understand the "Sighting" object
Yeah I think a few concrete examples would really help everyone understand what we need to be added / changed.
Bret
From: Andras Iklody <andras.iklody@gmail.com>
Sent: Monday, September 10, 2018 2:46:34 PM
To: shawn.p.riley@gmail.com
Cc: Bret Jordan; Forrest.B.Hare@saic.com; cti-users@lists.oasis-open.org
Subject: Re: [cti-users] Re: [EXT] [cti-users] trying to understand the "Sighting" object
With regards to the current state of STIX, could you provide some examples on how this could further advance information sharing?
After reading your messages, I am trying to understand - without of course having the background knowledge about the type of intelligence done by the DoD.
The examples don't have to be very exhaustive, just some teaser to get an idea.
Hi Bret,
It depends on the features and functionality in the user requirements. If you are supporting the automation of the scientific method or intelligence community methodologies like activity-based intelligence that require deductive inference
then you'd need a knowledge model that supports not only the storage and retrieval of information but deductive inference as well. Same way, increased automated reasoning capabilities (discovery, intelligence, question-answering, etc) requires increased metadata
and semantics in the knowledge model.
If you think about the user (the person using threat intelligence) they apply inductive and deductive inference during the scientific method to make sense of the information. If we want to augment or automate the sense-making and decision-making
process to be able to infer predictions and deductions into the investigation we need to support automated inference and that means having knowledge models that support storage, retrieval, and inference.
I think it's a bit to complex topic to discuss via email. If you're out at Integrated Cyber in a few weeks it might be better to discuss in person.
Shawn,
Please help the community understand what would be needed and why for this to work more easily.
Bret
From: Shawn Riley <shawn.p.riley@gmail.com>
Sent: Monday, September 10, 2018 1:49:11 PM
To: Bret Jordan
Cc: Forrest.B.Hare@saic.com; CTI-Stix-User
Subject: Re: [cti-users] Re: [EXT] [cti-users] trying to understand the "Sighting" object
Forrest,
It's worth keeping in mind that STIX graphs are just simple property graphs due to the JSON/JSON Schema (Dictionary) design. If you're used to working with the other intelligence areas in the DoD/IC that have already transitioned to integrated
intelligence using knowledge engineering and object-based production to create knowledge graphs, STIX won't have the metadata or that level detail. This sometimes trips people up if they are used to the more detailed conceptual models and description logic
used in integrated intelligence (objects, attributes, associations, and activities).
Forrest,
Let me give a concrete examples... Say company
example.com created and shared an indicator that identifies beaconing traffic for Malware sample X. That indicators identifies 50 URLs and IPs that the Malware is known to talk to.
You get that indicator and use it in your system / infrastructure. At some point that indicator fires and you get a hit.. You could tell
example.com:
1) You saw the indicator but not tell them what you saw or where you saw it. This would be a one-armed Sighting relationship that point to the Indicator and nothing else.
2) You saw the indicator and the URLs you saw were
badstuff.com and
badactor.com. This would be a Sighting relationship that points to the Indicator and some Observed Data (the cyber observables).
3) You saw the indicator and the URLs you saw were
badstuff.com and
bactor.com. You also saw this in the health sector in France. This would be a Sighting relationship that points to the Indicator, some Observed Data (URLs), an Identity object (health sector), and a Location object (France).
If we were to do item 3 with the general purpose Relationship object, then you would need to send 3 JSON objects. But the Sighting relationship object allows you do include all three edges in a single JSON object.
Does that help?
Bret
Ok, so to avoid creating an additional SDO for what is theoretically the same indicator (I caveat that because there could be a false positive observance), you are creating a new relationship object for what are essentially additional
properties of the previous indicator SDO relating to different observances of the indicator at a different location (âwas also seen by meâ, âwhen,â âwhere,â. Etc).
Then it is up to the analyst how to process that data (e.g., the example you provided below). I think I understand.
Iâm not sure the graphic on the Walk-Thru depicts your explanation, however Iâm not sure how to improve on it to do so. Maybe just the additional âsighting ofâ edge and drop the âsightingâ node?
Thanks!
Forrest
Forrest,
Thank you for the question. A Sighting object in STIX is just a relationship (edge in the graph). The reason we did not use the general purpose Relationship object is we wanted some operational efficiencies for transport. So the
STIX Sighting relationship object has the ability to do the following:
1) Say the indicator is good or more specially "was seen" but without any context. Some organizations can not share other details other than "thumbs up" this indicator is good and I saw it.
2) Say the indicator was seen and here are the exact things I saw. Indicator -> Sighting -> Observed Data
3) Say the indicator was seen and this is where it was seen. Indicator -> Sighting -> Identity / Location
This means you can also say what was seen and where it was seen in a single payload. Thus multiple edges in a single JSON object. This is why the Sighting relationship object is "special".
One of the big problems is in the way we talk about Sighting. We talk about it as if it was a Domain Object. This is because it can sort of act like that in the use case #1 above, effectively a one-armed edge (an edge that is
only connected on one side).
I would expect a system that consumes a STIX Sighting relationship object to decompose it to the various edges that it contains and represent them individually in their graph. We also need to remember that STIX is a transport serialization
for sharing CTI.
Does this help? What other questions do you have ?
Thanks
Bret
This communication (including any attachments) may contain information that is proprietary, confidential or exempt from disclosure. If you are not the intended recipient, please note that further dissemination, distribution, use or copying of this communication
is strictly prohibited. Anyone who received this message in error should notify the sender immediately by telephone or by return email and delete it from his or her computer.
This communication (including any attachments) may contain information that is proprietary, confidential or exempt from disclosure. If you are not the intended recipient, please note that further dissemination, distribution, use or copying of this communication
is strictly prohibited. Anyone who received this message in error should notify the sender immediately by telephone or by return email and delete it from his or her computer.
|