[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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> 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> 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> 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.
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]