OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-cybox message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti-cybox] CybOX 3.0: File Object Refactoring


No need for apologies :) I’ve been trying to think of a better term than “extension" so that we can avoid this confusion, but it’s been a struggle. Maybe something like “add-on”?

Regards,
Ivan 

From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Tuesday, December 22, 2015 at 7:51 AM
To: Ivan Kirillov <ikirillov@mitre.org>
Cc: Mark Davidson <mdavidson@soltra.com>, John Wunder <jwunder@mitre.org>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: Re: [cti-cybox] CybOX 3.0: File Object Refactoring

Oh drat - I apologize. Yes, it is confusing :)

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Inactive hide details for "Kirillov, Ivan A." ---12/22/2015 10:47:03 AM---Jason – I think there is again some confusion regard"Kirillov, Ivan A." ---12/22/2015 10:47:03 AM---Jason – I think there is again some confusion regarding our use of the term “extension” :) What we’r

From: "Kirillov, Ivan A." <ikirillov@mitre.org>
To: Jason Keirstead/CanEast/IBM@IBMCA, Mark Davidson <mdavidson@soltra.com>
Cc: "Wunder, John A." <jwunder@mitre.org>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Date: 12/22/2015 10:47 AM
Subject: Re: [cti-cybox] CybOX 3.0: File Object Refactoring
Sent by: <cti-cybox@lists.oasis-open.org>





Jason – I think there is again some confusion regarding our use of the term “extension” :) What we’re referring to here are the actual File Object (and other Object) extensions that we’ve proposed, such as FileMetadataExtension and EXT3FileExtension. Thus, “type” would be used to specify the name of the extension that is being used, e.g., “type” = “FileMetadataExtension”:

{
"hashes" : [{"type":"md5",
"hash_value":"3773a88f65a5e780c8dff9cdc3a056f3"}],
"size" : 25537,
"file_system_properties":{"is_directory":false,
"file_name": "foo.exe",
"file_path": {"delimiter":"/",
"components":["usr","tmp"]}},
"extensions": [{"type":"FileMetadataExtension",
"mime_type":"vnd.microsoft.portable-executable"}]
}


This doesn’t have anything to do with extensions that are found in file names, which would still be captured in the “file_name” property (as in the example above). Maybe we need to call this something else for clarity - “extension point” perhaps?

Regards,
Ivan

From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date:
Tuesday, December 22, 2015 at 7:40 AM
To:
Mark Davidson <mdavidson@soltra.com>
Cc:
Ivan Kirillov <ikirillov@mitre.org>, John Wunder <jwunder@mitre.org>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject:
Re: [cti-cybox] CybOX 3.0: File Object Refactoring

The problem with using "type" to refer to the file extension type to me, is it is removing important information from the serialization.

IE - why is the file extension the determiner of "type" of a file? I would think the file magic would be the ultimate authority, if any. The file extension is totally irrelevant in any operating system but windows.

I would rather keep it "extension_type" for clarity on what we are referring to. If people feel that is too ambiguous, how about "file_extension_type".

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Inactive hide details for Mark Davidson ---12/22/2015 10:26:49 AM---Personally I like the idea that certain keywords are reservMark Davidson ---12/22/2015 10:26:49 AM---Personally I like the idea that certain keywords are reserved. Forcing implementers to remember whi

From:
Mark Davidson <mdavidson@soltra.com>
To:
"Kirillov, Ivan A." <ikirillov@mitre.org>, "Wunder, John A." <jwunder@mitre.org>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Date:
12/22/2015 10:26 AM
Subject:
Re: [cti-cybox] CybOX 3.0: File Object Refactoring
Sent by:
<cti-cybox@lists.oasis-open.org>





Personally I like the idea that certain keywords are reserved. Forcing implementers to remember which “type” fields indicate the object type and which “type” fields indicate some other type (e.g., PE binary type, as in the referenced example) would expand the cognitive load required to “grok” CybOX 3.0 significantly.

Thank you.
-Mark

From:
<cti-cybox@lists.oasis-open.org> on behalf of "Kirillov, Ivan A." <ikirillov@mitre.org>
Date:
Tuesday, December 22, 2015 at 9:18 AM
To:
"Wunder, John A." <jwunder@mitre.org>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject:
Re: [cti-cybox] CybOX 3.0: File Object Refactoring

“Extension_type” is just the required property on all extensions that defines the name of the object extension (which unfortunately collides with the concept of file extensions); I agree with Jason that “metadata_type” is rather abstract and so it may not be better. I’m fine with just “type” if we feel that it would be a better, standardized approach (it’s actually what we originally had) - the only issue there is that there are other places where “type” is used (e.g., [1]), so they would have to be changed since “type” would effectively become a reserved keyword.

I also concur with Mark’s points on MIMEType and Magic Number.

[1]
http://stixproject.github.io/data-model/1.2/WinExecutableFileObj/WindowsExecutableFileObjectType/

Regards,
Ivan

From:
<cti-cybox@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org>
Date:
Tuesday, December 22, 2015 at 7:10 AM
To:
"cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject:
Re: [cti-cybox] CybOX 3.0: File Object Refactoring

I agree w/ all of Mark’s comments.

Regarding #1, would this be a good place to use the “type” field that EclecticIQ has added to their JSON? It seems to serve the same purpose and if we standardize on that name across STIX, CybOX, and TAXII we’ll make things much easier for users.

John

From:
<cti-cybox@lists.oasis-open.org> on behalf of Mark Davidson <mdavidson@soltra.com>
Date:
Tuesday, December 22, 2015 at 7:13 AM
To:
Ivan Kirillov <ikirillov@mitre.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc:
"Wunder, John A." <jwunder@mitre.org>, Jerome Athias <athiasjerome@gmail.com>, Patrick Maroney <Pmaroney@specere.org>, Sean Barnum <sbarnum@mitre.org>, John Anderson <janderson@soltra.com>, Paul Patrick <ppatrick@isightpartners.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, Terry MacDonald <terry@soltra.com>
Subject:
Re: [cti-cybox] CybOX 3.0: File Object Refactoring

Overall I like the proposal.

I have a few comments:
        1. For ‘extension_type’, I had a slight bit of confusion upon opening the email that this was the “file extension type” (e.g., exe). If others had the same confusion, maybe updating the field name to something like “metadata_type” or “metadata_class” and/or updating the description to read along the lines of “Specifies the type (/class) of this metadata extension”. If nobody else had the same confusion, this comment can be disregarded (I just wanted to have a concrete suggestion rather than “it confused me”).
        2. For MIME type, maybe SHOULD be from the IANA MIME Type registry; MAY be any valid MIME Type production? I believe there are and will be MIME types that are not officially registered with IANA, as the registry permits custom extensions
        3. For magic number, I’d recommend requiring the hexadecimal representation (vs using the terminology ‘typically…’). To make my suggestion concrete I’ll offer the text: “The magic number [1] for the file represented by this CybOX object. The magic number MUST be a hex string” (the reference would be to some web site or appendix that lists magic numbers)
        4. I like requiring mismatch_type when has_mismatch is set to true
Thank you.
-Mark

From:
<cti-cybox@lists.oasis-open.org> on behalf of "Kirillov, Ivan A." <ikirillov@mitre.org>
Date:
Monday, December 21, 2015 at 3:03 PM
To:
Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc:
"Wunder, John A." <jwunder@mitre.org>, Jerome Athias <athiasjerome@gmail.com>, Patrick Maroney <Pmaroney@specere.org>, "Barnum, Sean D." <sbarnum@mitre.org>, John Anderson <janderson@soltra.com>, Paul Patrick <ppatrick@isightpartners.com>, "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, Terry MacDonald <terry@soltra.com>
Subject:
Re: [cti-cybox] CybOX 3.0: File Object Refactoring

Just a heads up that we’ve updated the File Object Refactoring proposal [1] to take into account some of the great points brought up around file metadata and masquerading discussion during our last SC call. Let us know what you think.

FileMetadataExtension
A default extension point for capturing general classes of file metadata. A sub-class of the
FileExtension class.
Field
Type
Multiplicity
Description
extension_type string 1 Specifies the type of this extension; required and MUST be set to 'FileMetadataExtension'
mime_type string 0-1 The MIME type name from the IANA media type registry (http://www.iana.org/assignments/media-types/media-types.xhtml) specified for the file, e.g., "msword".
magic_number string 0-1 The particular magic number (typically a hexadecimal constant used to identify a file format) corresponding to the file, if applicable.
has_mismatch boolean 0-1 Indicates that there is a mismatch between one or more stated and reported properties of the file. For example, a mismatch between the MIME type of the file its file extension.
mismatch_type FileMismatchEnum 0-N Specifies the specific type of file mismatch that was found. This field is required if the has_mismatch property is set to true.
FileMismatchEnum
Value
Description
extension/type A mismatch between the MIME type reported for the file and its file extension. For example, if the reported MIME type (as captured in the mime_type property) for the file is 'vnd.microsoft.portable-executable' and the file extension (as captured in the file_name property) is 'txt'.
magic/extension A mismatch between the magic number reported for the file and its file extension. For example, if the reported magic number (as captured in the magic_number property) for the file is '25504446', indicating a PDF file, and the file extension (as captured in the file_name property) is 'txt'.
magic/type A mismatch between the reported MIME type and magic number for the file. For example, if the reported MIME type (as captured in the mime_type property) for the file is 'JPEG' and the reported magic number is '424D' (as captured in the magic_number property, indicating a bitmap file).


[1]
https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-File-Object-Refactoring#filemetadataextension

Regards,
Ivan


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
[attachment "graycol.gif" deleted by Jason Keirstead/CanEast/IBM]



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]