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

[John-Mark Gurney <jmg@newcontext.com>]

Jason Keirstead wrote this message on Mon, Sep 25, 2017 at 10:43 -0300:
> ... But that is the problem I am pointing out.
> 
> Having a blob of bytes and knowing it is encrypted with AES-256 is not 
> sufficient to open it. I have to know that it is encrypted using Zip 
> encryption with AES-256, or 7zip encryption with AES-256, as these are 
> different things.

I agree that the above need to be specified differently...  If you
specify AES-256-CBC, the key and the data needs to be passed to the
AES256-CBC algorithm as specified by NIST and come out w/ the resulting
data.  If 7z or pkzip, etc are the container of the encrypted data, that
needs to be specified via something like 7z-aes256-ecb.  (The reason I
said ECB, is that I cannot find any documentation about what mode 7z uses,
so I will not assume that it's more secure than ECB, i.e. it's unusable
and insecure.)

> From:   "Kirillov, Ivan A." <ikirillov@mitre.org>
> To:     Jason Keirstead <Jason.Keirstead@ca.ibm.com>
> Cc:     "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
> Date:   09/25/2017 10:40 AM
> Subject:        Re: [cti-cybox] File/Artifact Encryption & Archive 
> Properties
> 
> 
> 
> Thanks for the feedback all – I agree with Jane that we need a diagram or 
> description (probably) of when to use the File vs. Artifact Objects. 
>  
> > I like the idea but I wonder if "encryption_algorithm" should be 
> "encryption_method".
>  
> Well, right now this property refers to the actual algorithm (e.g., 
> AES128-CBC, RSA, etc. via the Encryption Algorithm Vocabulary [1]) used to 
> encrypt the data in the file, so I think keeping the original name would 
> be preferable since it doesn’t capture the application method.
>  
> [1] 
> https://docs.google.com/document/d/1fWHWyo9OBOUVDKEs0HsMKIWqR8HTl3P8aDyM5Mz3iSM/edit#heading=h.h5b9uravt8oh
>  
> Regards,
> Ivan
>  
> From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
> Date: Monday, September 25, 2017 at 5:55 AM
> To: Ivan Kirillov <ikirillov@mitre.org>
> Cc: "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
> Subject: Re: [cti-cybox] File/Artifact Encryption & Archive Properties
>  
> I like the idea but I wonder if "encryption_algorithm" should be 
> "encryption_method".
> 
> What do you want someone to put in that field? "AES-256", or something 
> that also describes the application method used to encrypt the file?
> 
> 
> -
> Jason Keirstead
> STSM, Product Architect, Security Intelligence, IBM Security Systems
> www.ibm.com/security
> 
> Without data, all you are is just another person with an opinion - Unknown 
> 
> 
> 
> 
> 
> From:        "Kirillov, Ivan A." <ikirillov@mitre.org>
> To:        "cti-cybox@lists.oasis-open.org" 
> <cti-cybox@lists.oasis-open.org>
> Date:        09/22/2017 04:50 PM
> Subject:        [cti-cybox] File/Artifact Encryption & Archive Properties
> Sent by:        <cti-cybox@lists.oasis-open.org>
> 
> 
> 
> 
> 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.

-- 
John-Mark