Network context?
I like the use of “interconnected”, but I would be hesitant to mention any sort of context, especially around threats – this would imply that CybOX can actually capture the nature of the threat itself, which IMO is something that requires a higher form
of analysis and should instead be covered by STIX.
I put together a JSON snippet (also on Github [1]) that demonstrates how a STIX Observation could capture the the details of the example that Eoghan mentioned around an email with a malicious attachment that creates a network connection; additional instances
of this Observation could be captured using a Sightings object. Note that some of the Object fields and relationships here are notional, but this approximates what we currently have in CybOX 3.0. Is there anything that we’re missing here in terms of capability?
{
"type":
"package",
"spec_version":
"stix-2.0",
"observations":
[{
"type":
"observation",
"id":
"observation--1",
"spec_version":
"stix-2.0",
"created_at":
"2016-03-21T01:01:01Z",
"observed_at":
"2016-03-20T12:33:22Z",
"cybox":
{
"actions":
[{
"id":
"action--1",
"type":
"cybox-action",
"name":
"create network connection",
"associated_objects":
[
{
"type":
"associated-object",
"object_ref":
"network-connection--1",
"association":
"output of"
},
{
"type":
"associated-object",
"object_ref":
"process-object--1",
"association":
"initiator of"
}
]
}],
"objects":
[
{
"type":
"network-connection",
"id":
"network-connection--1",
"spec_version":
"cybox-3.0",
"protocols":{"layer7":"http"}
},
{
"type":
"ipv4-addr-object",
"id":
"ip-address--1",
"spec_version":
"cybox-3.0",
"value":
"1.2.3.4"
},
{
"type":
"domain-name-object",
"id":
"domain-name--1",
"spec_version":
"cybox-3.0",
"value":
"http://foo.bar.com"
},
{
"type":
"email-message-object",
"id":
"email-message--1",
"spec_version":
"cybox-3.0",
"from":
"bruce@wayne.com",
"subject":
"Check this out!"
},
{
"type":
"file-object",
"id":
"file-object--1",
"hashes":
{"md5":
"B4D33B0C7306351B9ED96578465C5579"}
},
{
"type":
"file-object",
"id":
"file-object--2",
"hashes":
{"md5":
"FFCCAADC7306351B9ED96578465C5579"}
},
{
"type":
"process-object",
"id":
"process-object--1",
"pid":1234
}
],
"relationships":
[
{
"type":
"object-relationship",
"id":
"object-relationship--1",
"spec_version":
"cybox-3.0",
"source_ref":
"email-message--1",
"target_ref":
"file-object--1",
"kind_of_relationship":
"has-attachment"
},
{
"type":
"object-relationship",
"id":
"object-relationship--2",
"spec_version":
"cybox-3.0",
"source_ref":
"file-object--1",
"target_ref":
"file-object--2",
"kind_of_relationship":
"contains"
},
{
"type":
"object-relationship",
"id":
"object-relationship--3",
"spec_version":
"cybox-3.0",
"source_ref":
"file-object--2",
"target_ref":
"proces-object--1",
"kind_of_relationship":
"image-of"
},
{
"type":
"object-relationship",
"id":
"object-relationship--4",
"spec_version":
"cybox-3.0",
"source_ref":
"domain-name--1",
"target_ref":
"network-connection--1",
"kind_of_relationship":
"destination-of"
},
{
"type":
"object-relationship",
"id":
"object-relationship--5",
"spec_version":
"cybox-3.0",
"source_ref":
"domain-name--1",
"target_ref":
"ip-address--1",
"kind_of_relationship":
"resolves-to"
}
]
}
}]
}
Regards,
Ivan
I would agree with Eoghan that all context not just meta data is relevant to threat detection.
I see why you would want a shorter definition though and suggest the following based on the proposal:
"CybOX is a library of standard type definitions for the representation
and interchange of network threat context related to artifacts of
interconnected
systems, used by STIX and other standards.”
I’m also fine with the version that Eoghan referred to but if the group wants a shorter version please consider the above changes.
allan
On Apr 15, 2016, at 7:57 AM, Kirillov, Ivan A. <ikirillov@MITRE.ORG> wrote:
Eoghan,
I hear what you’re saying. However, Actions, Objects, and Relationships in CybOX are not going away, so I think the heart of this debate lies around the notion of context.
IMO, this statement from the previous description lies at the heart of the matter:
“[CybOX offers] a common solution for all cyber security use cases requiring the ability to deal with cyber observables”
In my belief, this is untenable and unreasonable because 1) we do not and never will understand all cyber security use cases around observables 2) it is naïve to state that we can support all such cases, especially in terms of characterizing the context around
them. Thus, it doesn’t make sense to have a generic Observable.
Accordingly, with the mission statement put forth, one can still characterize and capture observables using the types defined in CybOX. However, it’s up to the language doing so to define the context around this; in STIX this is done with the Observation (which
can be versioned, marked, etc.), in MAEC it is done primarily through the Analysis type and its corresponding entities, and so forth. If DFAX or a language around digital forensics needs to capture observables, it can create its own type for doing so, which
defines the context around forensics-specific observables; at the core of such an observable, CybOX Objects, Actions, and Relationships could still be leveraged. Thus, while it may appear on the outset that we’re losing out on a generic observable structure,
I think forcing the context around observations to be defined by the user of CybOX leads to clearer semantics whilst still building upon the key concepts (Objects, et. Al) that made CybOX so useful to start with.
Regards,
Ivan
On 4/15/16, 8:07 AM, "cti-cybox@lists.oasis-open.org on behalf of Casey, Eoghan CIV DC3/DCCI" <cti-cybox@lists.oasis-open.org on behalf
of Eoghan.Casey@dc3.mil> wrote:
Trey,
I have major issues with the language of the proposed CybOX missions statement.
The usefulness of CybOX is contingent on the ability to represent/express the context and relationship of items, not just metadata.
As an example, we need CybOX to represent a message that has an attachment that contains a malicious payload that installs an executable that opens a network connection to a domain that resolves to an IP address. In addition to representing the associated objects
and relationships, we need to capture each time this observable occurs.
I see Observables, Relationships and Actions as integral parts of CybOX that make it useful across cyber domains.
The proposed mission statement would require a renaming of CybOX from Cyber Observable _expression_ to Cyber Object _expression_.
Be aware that CybOX has been well-described previously:
Standardizing Cyber Threat Intelligence Information with the Structured Threat Information _expression_ (STIX™)
http://stixproject.github.io/getting-started/whitepaper/
"CybOX is a language for encoding and communicating standardized high-fidelity information about cyber observables, whether dynamic events or stateful measures properties that are observable in the operational cyber domain. CybOX, like STIX, is not targeted
at a single cyber security use case but rather is intended to be flexible enough to offer a common solution for all cyber security use cases requiring the ability to deal with cyber observables. It is also intended to be flexible enough to allow both the high-fidelity
description of instances of cyber observables that have been measured in an operational context as well as more abstract patterns for potential observables that may be targets for observation and analysis apriori."
Eoghan
-----Original Message-----
From: cti-cybox@lists.oasis-open.org [mailto:cti-cybox@lists.oasis-open.org] On Behalf Of Trey Darley
Sent: Friday, April 15, 2016 5:04 AM
To: OASIS CTI TC CybOX SC list
Subject: [Non-DoD Source] [cti-cybox] Draft mission statement for the CybOX standard - please comment by COB Friday 15 April
Hi, all -
There's been an enormous amount of discussion over the past several weeks regarding what CybOX should be and where the tearline is with other standards that leverage CybOX. It seems like that old familiar situation we find ourselves in so often, talking past
one another in more-or-less violent agreement.
This week Ivan and I put our heads together and came up with the following mission statement for CybOX:
<snip>
CybOX is a library of standard type definitions for the representation and interchange of metadata related to artifacts of computational systems, used by STIX and other standards.
</snip>
In general, mission statements tend to be touchy-feely BS, but in this case we felt like having a clear mission statement would effectively put a stake in the ground and end a lot of the fruitless circular discussions that have plagued us lately.
We discussed the draft mission statement during yesterday's CybOX SC working call and there appeared to be complete consensus that this was a positive move. Our plan is to open a TC ballot measure to
(hopefully) once and for all nail down a clear definition for what CybOX is.
There were a few comments about the phrase "artifacts of computational systems". Since we already anticipate tackling a diverse set of use cases in future and there are surely many "unknown unknowns" lying ahead as well, we struggled mightily to come up with
that phrasing.
(The obvious and utterly ridiculous alternative we were trying to avoid was "cyber stuff".)
The consensus coming out of yesterday's working call was that the current language is good enough and that we should put it to a TC vote.
If you have major issues with the draft language for the CybOX mission statement, please speak up today. Otherwise, we'll move to open a ballot on Monday 18 April.
--
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 Soltra | An FS-ISAC & DTCC Company www.soltra.com
--
"No matter how hard you push and no matter what the priority, you can't increase the speed of light." --RFC 1925
|