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

[Terry MacDonald <terry.macdonald@cosive.com>]

That all sounds logical to me. We do want to enable people to send either a File Object or an Artifact Object or both, and have each object make sense in all those cases. This seems like a sensible proposal.

Cheers

Terry MacDonald

Cosive

On 23/09/2017 07:50, "Kirillov, Ivan A." <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