Hey everyone,
I don’t want to let this thread die, so to sum up the discussion, I’ve seen two separate topics:
1.
Can you sight any STIX TLO, not just indicators?
I’ve heard arguments both ways, but it seemed that the agreement at the DC3 F2F and over the lists/slack was that we do want to support that. So right now, we’ll have the documents reflect that by
allowing sighting_of_ref to point to anything (not just indicators).
2.
Do we need an evidence-of relationship separate from sightings?
I’ve not seen a lot of discussion about evidence-of in general, let alone whether it’s duplicative of sighting. What do people think…do we need to define this extra relationship type? It would go
from Observation to essentially everything other than Observation, and is a full relationship. I’d like to see more agreement on this before we add it to the document, so for the time being we’ll take it out and then add it back when/if we get enough agreement
and a good definition of how it’s different from a sighting.
John
From:
<
cti@lists.oasis-open.org> on behalf of Paul Patrick <
ppatrick@isightpartners.com>
Date: Friday, July 1, 2016 at 8:47 AM
To: "cti@lists.oasis-open.org" <
cti@lists.oasis-open.org>
Subject: Re: [cti] CybOX Containers in STIX
To make sure we’re all talking about the same thing and not just dreaming something up, perhaps someone can put together an example of how you directly sighted or observed a threat actor
vs you observed indicators or evidence of a threat actor. That exercise might help us come to the right answer
From:
<
cti@lists.oasis-open.org> on behalf of "Wunder, John A." <
jwunder@mitre.org>
Date: Friday, July 1, 2016 at 8:22 AM
To: Terry MacDonald <
terry.macdonald@cosive.com>
Cc: Bret Jordan <
bret.jordan@bluecoat.com>, "cti@lists.oasis-open.org" <
cti@lists.oasis-open.org>
Subject: Re: [cti] CybOX Containers in STIX
Resent-From: <
Paul.Patrick@FireEye.com>
That’s a great question…is a Sighting of a Threat Actor different than evidence for a Threat Actor? If so, we should probably keep both. If not, maybe we can remove the evidence-of relationships
and just use sighting?
From:
<
cti@lists.oasis-open.org> on behalf of Terry MacDonald <
terry.macdonald@cosive.com>
Date: Thursday, June 30, 2016 at 5:17 PM
To: "Wunder, John A." <
jwunder@mitre.org>
Cc: Bret Jordan <
bret.jordan@bluecoat.com>, "cti@lists.oasis-open.org" <
cti@lists.oasis-open.org>
Subject: Re: [cti] CybOX Containers in STIX
I agree with John. But I have a question.
Would the threat actor be associated with the relevant observations by a few separate direct 'evidenced-by' relationships with the observations, or would it be all observations identified via one or more sighting objects?
Cheers
Terry MacDonald
Cosive
On 30/06/2016 22:59, "Wunder, John A." <
jwunder@mitre.org > wrote:
I sould say the same for threat actor or any other object. You would want to sight a threat actor with an observation in order
to provide what you actually saw that made you think you had seen the threat actor. You wouldn’t describe the threat actor itself in CybOX, then, you would describe what you saw in cyber that made you create a sighting of it.
From:
"Jordan, Bret" <
bret.jordan@bluecoat.com >
Date: Thursday, June 30, 2016 at 7:29 AM
To: "Wunder, John A." <
jwunder@mitre.org >
Cc: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Subject: Re: [cti] CybOX Containers in STIX
What about a threat actor. ??
Bret
Sent from my Commodore 64
On Jun 29, 2016, at 6:44 PM, Wunder, John A. <
jwunder@mitre.org > wrote:
IIRC the reason count is on Observation rather than Sighting was that people wanted to have a count available on observations
that weren’t tied to sightings. For example, to say that they saw an IP address 100 times without it being a sighting of any particular indicator. So to avoid having two count fields it was put just on observation.
I do agree w/ Terry that the reason you would want to sight a campaign with an observation would be to provide what you actually
saw that made you think you had seen the campaign. You wouldn’t describe the campaign itself in CybOX, then, you would describe what you saw in cyber that made you create a sighting of it.
John
From:
Terry MacDonald <
terry.macdonald@cosive.com >
Date: Wednesday, June 29, 2016 at 5:50 PM
To: Bret Jordan <
bret.jordan@bluecoat.com >
Cc: "Wunder, John A." <
jwunder@mitre.org >, "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Subject: Re: [cti] CybOX Containers in STIX
Hi Bret,
An observation can be attached to the campaign object to describe the evidence that let someone to determine the campaign was attributed to that threat actor. I forsee observations being attached to nearly all the objects to provide the 'raw data' that the
producer used to come up with their assertion.
I am still puzzled at why we need sightings to effectively be a specialised 'summary' relationship, and but I am willing to go with the community opinion on this.
I do wonder why we can have multiple cybox objects within an observation, as well as multiple observations within a sighting. When do we use each one? When should we use the multiple objects within observation compared to when we should use multiple observations
within the sighting? We should either pick one object to house the multiplicity, or at least provide guidance on which data should be put where. E.g. when should an observed cybox object be put in the same observation, or within a different observation? Should
someone do one observation a day with all their cybox objects in there? Same thing for sightings.
Cheers
Terry MacDonald
Cosive
On 30/06/2016 06:01, "Jordan, Bret" <
bret.jordan@bluecoat.com > wrote:
I do not think we need it to be required... But then again, I am in favor of also moving the "count" field from Observation to Sighting. For example, if I want to sight a Threat
Actor or a Campaign, it does not really make sense to include an Observation that uses CybOX, since CybOX can not describe a "person" or an abstract concept like a Campaign.
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 Jun 29, 2016, at 13:01, Wunder, John A. <
jwunder@mitre.org > wrote:
One other question: right now, the Sighting TLO requires at least one Observation, so you can’t have a sighting without an Observation (observation doesn’t require CybOX, however). Is that what we want? As
a reminder, the use cases were:
1. “I saw this Indicator”
2. “I saw this Indicator 12 times between X time and Y time”
3. “I saw this Indicator and here’s the specific observation of what I saw”
4. “I saw this Campaign”
5. (#2 and #3 for campaign)
In theory #1 doesn’t require the observation, but I suppose maybe it should be required for consistency?
John
From: <
cti@lists.oasis-open.org > on behalf of "Wunder, John A." <
jwunder@mitre.org >
Date: Wednesday, June 29, 2016 at 11:25 AM
To: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Subject: Re: [cti] CybOX Containers in STIX
All,
We talked about this topic again on the working call and there seemed to be general agreement there as well that the embedded approach was preferred. Given that, and the fact that discussion has died down, I
move that we open a ballot to confirm the approach to representing CybOX inside an observation as well as the current definitions of Observation and Sighting.
Before opening the ballot, though, can everyone please review the current sections in the Google Docs? I’d like to avoid the problem we’re having with Object Markings, where we get a lot of very good comments
after the ballot has opened. I’d rather work through as much as possible before the ballot. I would call this priority one on STIX right now…if you only have 15 minutes this week to spend on STIX, please spend it reviewing the Observation and Sighting
sections of the STIX TLOs document.
Observation:
https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.b2frlbuolfj Sighting:
https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.k017w16zutw Note that everything in the “cybox” key will be defined by the CybOX specification. In CybOX, that type is currently defined here:
https://docs.google.com/document/d/1PSGv6Uvo3YyrK354cH0cvdn7gGedbhYJkgNVzwW9E6A/edit#heading=h.2p8taumnmgqi John
From: Allan Thomson <
athomson@lookingglasscyber.com >
Date: Friday, June 24, 2016 at 10:16 AM
To: "Jordan, Bret" <
bret.jordan@bluecoat.com >, Jason Keirstead <
Jason.Keirstead@ca.ibm.com >
Cc: Trey Darley <
trey@kingfisherops.com >, John-Mark Gurney <
jmg@newcontext.com >,
"Wunder, John A." <
jwunder@mitre.org >, "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Subject: Re: [cti] CybOX Containers in STIX
+1
From: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
on behalf of "Jordan, Bret" <
bret.jordan@bluecoat.com >
Date: Friday, June 24, 2016 at 5:41 AM
To: Jason Keirstead <
Jason.Keirstead@ca.ibm.com >
Cc: Trey Darley <
trey@kingfisherops.com >, John-Mark Gurney <
jmg@newcontext.com >, "Wunder, John" <
jwunder@mitre.org >,
"
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Subject: Re: [cti] CybOX Containers in STIX
They can do that be referencing the Observations or other TLOs in STIX if they so desire.
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 Jun 24, 2016, at 06:38, Jason Keirstead <
Jason.Keirstead@ca.ibm.com > wrote:
I believe what DFAX's desire here is to be able to reference content previously defined *in STIX* and have valid cross-references to CybOX using the GUIDs.
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown
<graycol.gif> "Jordan, Bret" ---06/24/2016 09:30:33 AM---We understand the problem so much more now than we did back in DC. And the in looking at the struct
From: "Jordan, Bret" <
bret.jordan@bluecoat.com >
To: Trey Darley <
trey@kingfisherops.com >
Cc: John-Mark Gurney <
jmg@newcontext.com >,
"Wunder, John A." <
jwunder@mitre.org >, "
cti@lists.oasis-open.org "
<
cti@lists.oasis-open.org >
Date: 06/24/2016 09:30 AM
Subject: Re: [cti] CybOX Containers in STIX
Sent by: <
cti@lists.oasis-open.org >
We understand the problem so much more now than we did back in DC. And the in looking at the structure it really does not makes sense to have a STIX TLO called cybox-container. In DC it was all a bunch of hand-waving, we never
actually spelled out the contents of the container. But now that we have put pen to paper, it really does not fit or work.
Further, if other standards want to use CybOX they can use it the same way that STIX and MAEC are going to use it. MAEC for example is not going to use STIX objects to use CybOX data. That just does not make sense.
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 Jun 24, 2016, at 03:15, Trey Darley <
trey@kingfisherops.com > wrote:
On 23.06.2016 14:28:33, John-Mark Gurney wrote:
I will say that part of the reason that #2 was chosen at the F2F was
that there are use cases for other standards, like DFAX, where they
want to be able to reference the CybOX object directly. With #2, the
CybOX container now has a unique GUID that can be addressed, but as
was pointed out, this still doesn't prevent referncing the CybOX
data, as an implementation can refer to the GUID of the Observation
TLO.
This was the infamous Arglebargle discussion, which was both heated
and long. Option #2 was a hard-won compromise to support the needs of
DFAX as expressed by Eoghan Casey et al.
Personally, I'm happy to go with option #1 for all the reasons
elucidated by John and Allan but in consideration of the many hours of
debate that went into the option #2 compromise, we should reenter that
discussion with sensitivity.
From a technical perspective it is not clear to me why DFAX couldn't
define its own container for CybOX, much as STIX and MAEC are doing.
If I recall correctly (and please weigh in here, good people of DC3!)
the primary motivation behind having a container object living in
CybOX land was DC3's desire to reuse CybOX observables^Wwhatever we're
calling them now across STIX, DFAX, and MAEC.
It's probably worth devoting the next TC working call to this topic,
since it's a critical question for STIX Indicators, Observations,
Sightings, not to mention the ongoing work of the CybOX SC and our
friends over at DC3.
--
Cheers,
Trey
++--------------------------------------------------------------------------++
Kingfisher Operations, sprl
gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D
++--------------------------------------------------------------------------++
--
"It is easier to move a problem around (for example, by moving the
problem to a different part of the overall network architecture) than
it is to solve it." --RFC 1925
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]