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