cti-cybox message

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

From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
To: Mark Davidson <mdavidson@soltra.com>
Date: Tue, 22 Dec 2015 09:12:27 -0400

I would find the term "metadata_type" confusing because I would assume this was referring to a mismatch in the filesystem and/or file metadata layer(s), not in the name of the file...

-
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

Mark Davidson ---12/22/2015 08:14:18 AM---Overall I like the proposal. I have a few comments:

From: Mark Davidson <mdavidson@soltra.com>
To: "Kirillov, Ivan A." <ikirillov@mitre.org>, Jason Keirstead/CanEast/IBM@IBMCA
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>
Date: 12/22/2015 08:14 AM
Subject: Re: [cti-cybox] CybOX 3.0: File Object Refactoring
Sent by: <cti-cybox@lists.oasis-open.org>

Overall I like the proposal.

I have a few comments:

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”).
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
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)
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

From: <cti-cybox@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Tuesday, December 15, 2015 at 11:16 AM
To: Ivan Kirillov <ikirillov@mitre.org>
Cc: John Wunder <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>, Bret Jordan <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

I tend to agree.. I am trying to figure out who is setting "is masqueraded" and under what circumstances and what the use case is for this field.

Say I use stenography to encode an executable inside of an image. Is that a "masqueraded" file that should not have a image/png mime type? It is actually a valid image. I argue that is the correct mime type, because *that* is the indicator.

Say I embed an executable into a word document using built in features. Is that a "masqueraded" file that should have a mime type of word? Again, it is a valid word document and IMO it is still an indicator. You do not want to lose the fact that it is a word document.

-
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

"Kirillov, Ivan A." ---12/15/2015 12:52:48 PM---I think “is_packed” will likely be included in the next release, perhaps as part of the metadata ext

From: "Kirillov, Ivan A." <ikirillov@mitre.org>
To: "Wunder, John A." <jwunder@mitre.org>, Jerome Athias <athiasjerome@gmail.com>
Cc: Patrick Maroney <Pmaroney@specere.org>, Jason Keirstead/CanEast/IBM@IBMCA, "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>
Date: 12/15/2015 12:52 PM
Subject: Re: [cti-cybox] CybOX 3.0: File Object Refactoring
Sent by: <cti-cybox@lists.oasis-open.org>

I think “is_packed” will likely be included in the next release, perhaps as part of the metadata extension.

I’m on the fence as far as explicitly capturing that a file is masqueraded – as John pointed out below, this can already be done implicitly by capturing the file name/extension and MIME type. If the two do not match, then it is likely a case of masquerading.

I know that we have this property in the existing File Object, but I’ve always considered it a product of analysis rather than pure observation. IMO, we should leave analytical findings to other places where they make more sense (probably STIX), and leave CybOX to “just the facts”.

Regards,
Ivan

From: John Wunder <jwunder@mitre.org>
Date: Tuesday, December 15, 2015 at 9:48 AM
To: Jerome Athias <athiasjerome@gmail.com>
Cc: Patrick Maroney <Pmaroney@specere.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Sean Barnum <sbarnum@mitre.org>, Ivan Kirillov <ikirillov@mitre.org>, John Anderson <janderson@soltra.com>, Paul Patrick <ppatrick@isightpartners.com>, Bret Jordan <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

Yep, that’s one mechanism. Are there others?

I’m just suggesting that we should be precise and encode these specific mechanisms rather than some generic field. In the case of a mis-named file, I think we’re all set (the content type will not match the extension in the file name) so maybe there’s nothing to add.

From: Jerome Athias <athiasjerome@gmail.com>
Date: Tuesday, December 15, 2015 at 11:44 AM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: Patrick Maroney <Pmaroney@specere.org>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Sean Barnum <sbarnum@mitre.org>, Ivan Kirillov <ikirillov@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

e.g. (maybe not applicable use case):
I am uploading a nicepic.jpg file to a website via an upload form accepting only the extension .jpg
But, I renamed webshell.php to picture.jpg just before uploading

My .php pretended to be a .jpg

2015-12-15 19:41 GMT+03:00 Wunder, John A. <jwunder@mitre.org>:

What do you mean by what it claims to be? Claims via what mechanisms?

It seems like we should capture those specific mechanisms rather than a general-purpose field for “this file claims to be X”. I would guess the majority are via the extension, which is already covered in the name.

From:

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.

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).

Field	Datatype	Description
delimiter	string	The delimiter used in the file name/path string.
components	list	A list of strings that represent the components of the file name/path string, when split using the delimiter specified in the 'delimiter' field. A value of 'null' at the end of the list specifies a directory.