Re: [cti-stix] Sighting + Observation in STIX

All:

In studying Bret's Observation/Indicator diagram it occurred to me that we need to remember the origin of the Observation/Sighting distinction. It was to facilitate the Trust Circle Sharing Use Case.

Here is my understanding of how it would work for this Use Case:

Organization A makes an Observation that is Evidence-of a "Campaign and/or Attack Pattern and/or Malware and/or Tool and/or Threat Actor and/or Identity" that Indicates an Indicator. That Indicator and related data is shared out to the Trust Circle ISAO or ISAC.

Organization B receives the Indicator and related Observation (including any CybOX Objects contained in the ArgleBargle) and using its handy-dandy big data analytics as applied to its net flow and end-point logs finds the same Indicator/Observation/(fill in the black with any of the above TLOs) tuple. So, Organization B decides to issue a Sighting confirming that it, too, has seen evidence of the same.

Organization C sees that Org A & Org B have seen the same Indicator/Observation/(fill in the blank) tuple and issues another Sighting - And on and on and on with Org D, E & F...... Presto! Crowd Sourcing has just occurred. But it takes the 'Sighting' object to be separate from Observation for this Use Case to unfold.

Crowd Sourcing can then be factored into our Admiralty Code measure for Confidence/Reliability of source(s) using some weighting factor that the broader Community should construct.

Does this make sense?

Jane

On 7/3/2016 7:06 PM, Jordan, Bret wrote:

We ARE using the power of relationships and graph models...

The sighting object is really just a relationship object that is special, in that it has a few extra meta data fields. Those fields make NO sense on the general purpose relationship object, thus the "named" relationship object called "Sighting" was created. But the Sighting object is in the same family as the general purpose Relationship object.

Further, since the Sighting object is just a relationship object you can sight everything with it. Kind of the point.

Bret

Sent from my Commodore 64

On Jul 3, 2016, at 3:53 PM, Terry MacDonald <terry.macdonald@cosive.com> wrote:

So we're now going to sight everything? It sounds like a sighting object has become an observation summary object now. I'm not sure I like this suggestion.

It sounds like we are just adding in levels of indirection everywhere rather than just leveraging the power of relationships and graph models...

Cheers
Terry MacDonald
Cosive

On 4/07/2016 06:44, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:

Thanks for doing these John.... Originally I thought that Option 1 would be a good solution, this was back at the F2F in DC... But over the past month or so, I have really being questioning that design. Something just felt "wrong" about it.. So I started leaning to Option 2 as a compromise between them, because I still could not figure out what was "wrong" with the design.

This weekend, as you all know, I cleaned up all of the relationship tables (verified with John that we had all known relationships listed), reworded all of the descriptions, and then built visual diagrams to help us see more clearly what it was we are building. Then it hit me, the thing that has been festering just out of reach... We have broken one of our main design principles, that is "one-way" of doing this with Observations and Sightings...

We have created a solution that allows you to "sight" something by either linking an Observation with something else via an external relationships of "evidence-of" or "sighting" something via the Sighting object that links an Observation with something else. Two ways to do the same thing.

I am now of the opinion that we should remove all of the "evidence-of" external relationships from the Observation object and just use the Sighting object to "sight" things. This will guarantee that we have one semantic way of doing it.

Now, once we do this, it really does not make sense to have the "count" field on the Observation.... It really does not fit there anymore. So the only logical place for it, would be the Sighting object. So in summary I would propose:

1) We remove all external relationships FROM the Observation object with a type of "evidence-of"

2) We move the Count field from Observation to Sighting

This should fix the problems we have all been seeing and talking around, but have not fully put our finger on.

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 Jul 3, 2016, at 13:00, Wunder, John A. <jwunder@mitre.org> wrote:

Alright folks, here’s the diagram and examples I promised. We should talk through these on the call Tuesday. If you get a chance, it might be good to read through the Sighting/Observation portion of Jane’s notes from the DC3 meeting so you have that extra context. You can find them here: https://www.oasis-open.org/apps/org/workgroup/cti/download.php/58009/OASIS-CTI-TC_BaltimoreF2F_April2016.pdf

Option 1: Consensus approach at DC3, with count/start/end only on Observation
Option 2: Alternative approach, with count/start/end both on Observation and Sighting
Option 3: Merge Observation and Sighting
Option 4: Count/start/end on Sighting, not on Observation

John

<Sightings and Observations.pptx>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

-- 
_________________________

R. Jane Ginn, MSIA, MRP
Cyber Threat Intelligence Network, Inc.
jg@ctin.us
(928) 399-0509

cti-stix message