+1 to both of these comments.
From:
Ivan Kirillov <
ikirillov@mitre.org>
Date: Tuesday, October 25, 2016 at 4:31 PM
To: "Bret Jordan (CS)" <
Bret_Jordan@symantec.com>, John Wunder <
jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <
cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Observed Data
>> I do think the key definition we need to agree on for 2.0 is that Observed Data represents raw data collected from systems and networks.
>> And if you are trying to characterize the malware or infrastructure you will put that data directly in to properties on the SDOs themselves.
I’m in agreement with both of these points. I just want to make sure that we don’t redefine properties of Cyber Observable Objects in SDOs. For example, if we have a need to associate an
IPv4 Address Object with an SDO, use that Object instead of trying to redefine it inline in the SDO.
Therefore, something along the lines of what Bret suggests below makes good sense to me.
Regards,
Ivan
From:
"Bret Jordan (CS)" <
Bret_Jordan@symantec.com>
Date: Tuesday, October 25, 2016 at 2:18 PM
To: John Wunder <
jwunder@mitre.org>, Ivan Kirillov <
ikirillov@mitre.org>, "cti-stix@lists.oasis-open.org" <
cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Observed Data
And if you are trying to characterize the malware or infrastructure you will put that data directly in to properties on the SDOs themselves.
For example, in the Malware object you might have an array of filenames or a listing of sockets it opens. You would not use Observed Data for this, but rather you would have a series of properties directly on the object to capture
it.
So for example for Infrastructure you might have :
{
"type": "infrastructure",
...,
"ipv4_addresses": [ ... ], # this array would be a list of Cyber Observable IPv4 Address types for example.
...
}
Bret
From:
cti-stix@lists.oasis-open.org <
cti-stix@lists.oasis-open.org> on behalf of Wunder, John A.
<
jwunder@mitre.org>
Sent: Tuesday, October 25, 2016 2:07:54 PM
To: Bret Jordan (CS); Kirillov, Ivan A.;
cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Observed Data
I would say we tackle those fields as we get to them, which is post-2.0.
I do think the key definition we need to agree on for 2.0 is that Observed Data represents raw data collected from systems and networks. So if you’re representing a File that you think
is a piece of malware, you represent it as Observed Data related to that Malware via a Sighting.
From:
<
cti-stix@lists.oasis-open.org> on behalf of "Bret Jordan (CS)" <
Bret_Jordan@symantec.com>
Date: Tuesday, October 25, 2016 at 4:00 PM
To: Ivan Kirillov <
ikirillov@mitre.org>, "cti-stix@lists.oasis-open.org" <
cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Observed Data
Good question.... We need to have this discussion and figure out how things are going to look and feel before we finish STIX 2.0. Once we understand the rules for using Cyber Observables in other SDOs, we can be reasonably confident
that things will not break.
Bret
From: Kirillov, Ivan A. <
ikirillov@mitre.org>
Sent: Tuesday, October 25, 2016 1:53:46 PM
To: Bret Jordan (CS);
cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Observed Data
For the capture of cyber observable properties, why not just embed an Observable Objects dictionary in each SDO as needed? That way you can capture whatever Cyber Observable Objects are
pertinent to the SDO (e.g., IPv4 addresses) without having to redefine their properties in multiple places, which is essentially what this approach is advocating.
Regards,
Ivan
From:
<
cti-stix@lists.oasis-open.org> on behalf of "Bret Jordan (CS)" <
Bret_Jordan@symantec.com>
Date: Tuesday, October 25, 2016 at 1:14 PM
To: "cti-stix@lists.oasis-open.org" <
cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Observed Data
All,
I spoke with John Wunder about how and when to embed Cyber Observable (formerly CybOX) properties directly on a SDO and when you would use Observed Data via a relationship. We were talking about this in context
with the upcoming Infrastructure SDO.. The rules we came up with, that we would like your feedback on are listed below. It is important that we understand these rules now, so as to not cause a breaking change with Observed Data later on. So yes, we are
talking about an SDO that will not be in the next CSD release, but it is important to understand how it will work and this is the best way to illustrate the usages.
Notes about using Observed Data with things like Infrastructure or Malware.
1.
The Infrastructure or Malware object will have Cyber Observable properties directly on them. These fields will allow you to capture the data that characterises these objects.
2.
So say that an Infrastructure is known to exist in S.Korea and it is using Linux based Web Cameras as a delivery point for C-n-C. These IP addresses and the Make/Model of
the Web Cams would all be on the Infrastructure Object itself.
3.
You may need to revision the Infrastructure object multiple times as you find or discover more things. In this case, some fields on the Infrastructure object may need to be
an array to allow for say thousands of IP address.
4.
The way Observed Data fits in, is when you do a Sighting. When you want to say you saw an instance of these things.
You may not want to capture all of the technical details on the object if you feel they’re too transitory. i.e. if a C2 network has a dynamic domain generation algorithm, capturing all of the actual domains it
uses is probably not useful. You would instead (probably in text for now) just capture the algorithm itself
An open question would be how to track things used as part of an infrastructure over time. Meaning, if a threat actor moved from IoT Camera X to IoT DoorBell Y 3 weeks later, how would you record this?
Bret