[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] CybOX Datatype Refactoring/Deprecation
[sean]So for these I assume you are suggesting that the presence of these fields implicitly means that the field is obfuscated or defanged thereby negating the need for the explicit field. The only potential issue I see with that is when the field
is obfuscated or defanged but no algorithm is provided or available.
[Ivan] Yes, that’s correct – John and I thought that we could likely remove the is_obfuscated/is_defanged fields, since the presence of the _ref fields is enough to state that a field is obfuscated and/or defanged. Do we as the community feel that not
specifying a reference to the obfuscation/defanging algorithm used would be a common occurrence?
My understanding of a common use case is that Party A passes along data to Party B that was not originally produced by Party A where they have determined the data is obfuscated or defanged and wish to convey that to Party B but do not have certainty
on the exact algorithm used.
Either way, I would think you will also need to include refanging
[Ivan] That makes sense, though I do wonder if in such a case Party A will indeed provide refanging information if they do not have certainty about the defanging method used. Also, the refanging field as designed before was meant to be a machine-parseable
transform (e.g, a regex); is there still the expectation that it is actually used in this way (i.e., that consumers would actually machine parse it and apply it to the data) in the wild?
Regards,
Ivan
From: Sean Barnum <sbarnum@mitre.org>
Date: Tuesday, February 16, 2016 at 7:43 AM To: Ivan Kirillov <ikirillov@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: Re: [cti] CybOX Datatype Refactoring/Deprecation Comments inline
From: <cti@lists.oasis-open.org> on behalf of Steve Cell <ikirillov@mitre.org>
Date: Monday, February 15, 2016 at 10:45 AM To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: Re: [cti] CybOX Datatype Refactoring/Deprecation Are there any additional thoughts on this topic? Just trying to see if have any consensus on:
[sean]I have no dog in this hunt but know that this field came from request came from digital forensics use cases where they were fully aware that this was an observation and not a pattern. We should ask Eoghan for his thoughts on this.
[sean]So for these I assume you are suggesting that the presence of these fields implicitly means that the field is obfuscated or defanged thereby negating the need for the explicit field. The only potential issue I see with that is when the field
is obfuscated or defanged but no algorithm is provided or available. My understanding of a common use case is that Party A passes along data to Party B that was not originally produced by Party A where they have determined the data is obfuscated or defanged
and wish to convey that to Party B but do not have certainty on the exact algorithm used.
Either way, I would think you will also need to include refanging
Regards,
Ivan
From: Terry MacDonald <terry@soltra.com>
Date: Tuesday, February 9, 2016 at 4:49 PM To: Ivan Kirillov <ikirillov@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Subject: RE: [cti] CybOX Datatype Refactoring/Deprecation What about using the relationships to handle the levels of obfuscation? That would allow description of obfuscated and encrypted objects within other obfuscated
objects. In other words to describe a PDF containing obfuscated _javascript_ that decodes and extracts a windows executable from within the PDF we could do something
like this: https://docs.google.com/drawings/d/1ozVBXQcFWja5yMAKDRfqkKz_1KfDZwZoVf5IyO7ElRg/pub?w=667&h=560 Would that sort of thing work? BTW the relationship thing seems pretty darn powerful when used like this…. Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA | An FS-ISAC and DTCC Company +61 (407) 203 206 |
terry@soltra.com From:cti@lists.oasis-open.org
[mailto:cti@lists.oasis-open.org]
On Behalf Of Kirillov, Ivan A. >> As much as I would like fields to just be the value, I agree that we probably need this layer of indirection to support these extra properties. I was also hoping for Observations/Objects to just hold the value, but some of these fields do seem to be necessary. I think the only other way to do this
would be via relationships, but then you’d have to assign an ID to each field, and that would just get messy quickly without any real benefit. >> We’ll need to decide what that means for patterning, if anything, by the way. Yup, agreed. My initial thinking is that these properties don’t (or shouldn’t) have any significance for patterning. >>Given that we’re talking about actual observations here (instances), is “appears_random” appropriate? That seems to be a statement about a pattern of behavior
over several observations rather than a single observation. I’ve wondered the same – this does seem to be an assertion that one wouldn’t typically make based on a single data point. Also, it seems like you’d want to
be able to specify some level of confidence and perhaps other properties with this as well, so I’m also wondering if this belongs here or perhaps in some separate structure (which could also be used for related observations such as entropy, etc.)? >>Can we combine the “obfuscation” fields into some single “obfuscation_algorithm”, representing a URI or something? Then if the field is there, it’s obfuscated
using that. If it’s not, then it’s not obfuscated. Yeah, that makes good sense to me. I think having the “is_defanged” boolean isn’t strictly necessary, as you can infer that something is obfuscated if the
corresponding “obfuscation_algorithm” field is populated. Having a URI in there seems reasonable. >> Given that we’re now talking about machine-to-machine transmissions, is defanging still important? Can’t the raw data be exchanged as it is and then let
tools to present it to users defanged however they want? It seems weird to me to transmit it defanged if it’s M2M (vs. a PDF that people might accidentally click). I had the same question when we were first implementing defanging/fanging; it does seem like something that should be done at the data ingest/GUI layer rather
than at the data specification layer. It’s definitely odd to support it if there is no expectation that humans will actually look at the data. >> If we do need to include it, can we similarly collapse these attributes into one “defanging_algorithm” URI? They seem very redundant right now. I’m also onboard with this. So we’d get something like:
Regards, Ivan From:
<cti@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org> As much as I would like fields to just be the value, I agree that we probably need this layer of indirection to support these extra properties. We’ll need
to decide what that means for patterning, if anything, by the way. On the attributes you listed, I just have a few questions:
John From:
<cti@lists.oasis-open.org> on behalf of Ivan Kirillov <ikirillov@mitre.org> Sending this to the broader CTI since it’s part of the STIX/CybOX Indicator tranche. Given that we’ll be splitting out embedded patterning from CybOX, there are changes that we need to make to the base datatypes used currently for specifying
properties in CybOX Objects. At a high level, this involves the following:
More details on these proposed changes can be found here: https://github.com/CybOXProject/schemas/issues/416#issuecomment-181916815 Accordingly, this would result in CybOX instance content that looks like the following; each property is an Object (so that it can specify metadata about refanging/defanging/etc)
and thus the “value” field MUST be included in every property to capture its actual value. {
"size": {"value": 23134}, "file-system-properties" : {"file_name": {"value":"test.dll", "observed_encoding":"utf-8"}} }
Some open questions:
Regards, Ivan |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]