[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti-cybox] [Non-DoD Source] [cti-cybox] Draft mission statement for the CybOX standard - please comment by COB Friday 15 April
Bret -
The JSON mockup is our attempt to interpret what has been proposed for CybOX 3.0 and putting Observations into STIX. The example JSON demonstrates how difficult it would be to link between STIX and DFAX. In short, the proposed changes will create major problems in your and my day-jobs, so let's work through the details at the F2F.
Eoghan
-----Original Message-----
From: Jordan, Bret [mailto:bret.jordan@bluecoat.com]
Sent: Friday, April 15, 2016 2:16 PM
To: Casey, Eoghan CIV DC3/DCCI
Cc: Kirillov, Ivan A.; Allan Thomson; Trey Darley; OASIS CTI TC CybOX SC list
Subject: Re: [cti-cybox] [Non-DoD Source] [cti-cybox] Draft mission statement for the CybOX standard - please comment by COB Friday 15 April
Eoghan,
Is this JSON mock up what you are proposing? Or is it describing or illustrating an issue? Please clarify.
One super minor technical issue is the cybox label in an Observation is currently defined as an array of type cybox, not just a cybox object.
We, in my day-job, have the need to do exactly what you describe. I am thinking that STIX would somehow, TBD, link to the DFAX or MAEC data. Or if STIX consumed DFAX and MAEC at some point, they would just get embedded in STIX. Not sure, this has yet to be discussed and figured out.
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 Apr 15, 2016, at 11:57, Casey, Eoghan CIV DC3/DCCI <Eoghan.Casey@dc3.mil> wrote:
Ivan,
I appreciate you taking the time to mockup an example. Given the number of issues this raises, I suggest that we put this on the agenda for the F2F.
In advance of the F2F, consider an incident in which suspicious activity is observed in network logs (represented in a CybOX object sent to a SEIM), triggering incident response. My forensic examiner observes information on a compromised host, represented using DFAX, including items that require malware analysis. My reverse engineer observes information in the malware, represented in MAEC. My cyber threat fusion analyst observes information from other sources that correlate with both the DFAX and MAEC observables, and represents these findings in a STIX package to share with others. The proposed changes to STIX and CybOX would require information in DFAX and MAEC to be duplicated into a STIX package rather than referenced by identifiers, and I cannot imagine what would happen with the observable details being translated from DFAX to STIX.
As another example of how the proposal would make it difficult to relate a STIX object to a CybOX object, consider the scenario a threat actor was known to own an IP address that appeared in the attack. You would need to duplicate this part of the information and then add STIX links to tie all of these parts together. This is a quick mockup of what that would look like. The relationship names provided are not the correct STIX names, just for illustration purposes.
{
"type": "package",
"spec_version": "stix-2.0",
"ThreatActors": [
{
"type": "ThreatActor",
"id": "threatactor--1",
"spec_version": "stix-2.0",
"created_at": "2016-03-21T01:01:01Z"
}
]
"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": {
"objects": [
{
"type": "ipv4-addr-object",
"id": "ip-address--1",
"spec_version": "cybox-3.0",
"value": "1.2.3.4"
}
]
}
},
{
"type": "observation",
"id": "observation--2",
"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"
}
]
}
}
],
"Relationships": [
{
"type": "relationship",
"id": "relationship--1",
"spec_version": "stix-2.0",
"source_ref": "threatactor--1",
"target_ref": "observation--1",
"kind_of_relationship": "owns"
},
{
"type": "relationship",
"id": "relationship--2",
"spec_version": "stix-2.0",
"source_ref": "observation--2",
"target_ref": "observation--1",
"kind_of_relationship": "contains"
}
]
}
-----Original Message-----
From: Kirillov, Ivan A. [mailto:ikirillov@mitre.org]
Sent: Friday, April 15, 2016 11:53 AM
To: Allan Thomson
Cc: Casey, Eoghan CIV DC3/DCCI; Trey Darley; OASIS CTI TC CybOX SC list
Subject: Re: [cti-cybox] [Non-DoD Source] [cti-cybox] Draft mission statement for the CybOX standard - please comment by COB Friday 15 April
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"
}
]
}
}]
}
[1] https://gist.github.com/ikiril01/a24c0fabfe96933f051f0920f5589b77
Regards,
Ivan
From: Allan Thomson <athomson@lgscout.com>
Date: Friday, April 15, 2016 at 9:17 AM
To: Ivan Kirillov <ikirillov@MITRE.ORG>
Cc: "Casey, Eoghan CIV DC3/DCCI" <Eoghan.Casey@dc3.mil>, Trey Darley <trey@soltra.com>, OASIS CTI TC CybOX SC list <cti-cybox@lists.oasis-open.org>
Subject: Re: [cti-cybox] [Non-DoD Source] [cti-cybox] Draft mission statement for the CybOX standard - please comment by COB Friday 15 April
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]