Re: [cti-cybox] File/Artifact Encryption & Archive Properties

[Sean Barnum <sean.barnum@FireEye.com>]

Yes. This specific use case is what led to the is_enrypted boolean property

 

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

 

From: <cti-cybox@lists.oasis-open.org> on behalf of "Back, Greg" <gback@mitre.org>
Date: Monday, September 25, 2017 at 9:46 AM
To: "Kirillov, Ivan A." <ikirillov@mitre.org>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: Re: [cti-cybox] File/Artifact Encryption & Archive Properties

 

> is_encrypted: This property is simply redundant because it’s clear that the file is encrypted if the “encryption_algorithm” property is specified.

 

Is there a need to specify that a file is encrypted, even if it’s not possible or desirable to specify *how* it is encrypted?

 

On 2017-09-22, 19:51 UTC, "cti-cybox@lists.oasis-open.org on behalf of Kirillov, Ivan A." <cti-cybox@lists.oasis-open.org on behalf of ikirillov@mitre.org> wrote:

 

Recently, Trey and I proposed some updates to the STIX 2.1 Artifact Object that came about as a result of the work we’ve been doing on the Malware SDO. Namely, we’ve been trying to support the use case around the exchange of “defanged” malware samples that are commonly stored in password encrypted archive files. Thus, we’ve proposed the addition of the “encryption_algorithm” and “decryption_key” properties to the Artifact Object.

 

However, Paul Patrick and some others rightly pointed out that we have some duplicate properties on the base File Object, including “is_encrypted”, “encryption_algorithm”, and “decryption_key”. This is especially problematic because the File Object can reference an Artifact to describe its binary contents via the “contents_ref” property. After thinking about this some more and discussing it on today’s working call, we’re proposing the following changes in STIX 2.1 to help address this potential duplication:

 

• Deprecate the following properties on the File Object:
  • is_encrypted: This property is simply redundant because it’s clear that the file is encrypted if the “encryption_algorithm” property is specified.
  • decryption_key: It doesn’t seem useful to capture a decryption key as purely metadata and without the corresponding encrypted data that it goes with.
• Add the previously discussed “encryption_algorithm” and “decryption_key” properties to the Artifact Object. We recognize that “encryption_algorithm” is the same property as on the base File Object, but there may be cases where you want to share an encrypted Artifact (such as some data dumped from memory) without a corresponding File Object. Also, we already have the precedent where “hashes” is defined on both the Artifact and File Objects.

 

Anyhow, our thinking is that with these changes you can still capture TTP-related metadata about encrypted files (e.g., those dropped by malware) using the File Object but also retain the ability to provide additional artifact-specific information via the Artifact Object (including decryption key). Similarly, if you wish to characterize the contents of an archive file, you can achieve this via the existing Archive File Extension. 

 

Let us know what you think – maybe there’s something we’re missing or a better way to go about this.

 

Regards,

Ivan

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.