Can attachments to Email_Message be something besides a file
rpiazza opened this issue · comments
In STIX 2.0, an attachment can be a File or Artifact. The python-cybox allows only a File. The cybox schema implies that what is represented is actually an object reference.
The schema states:
The object_reference field specifies a reference to an file-oriented (i.e., the File Object or one its derivations such as the Windows File Object) Object defined elsewhere in the document, via its id.
I don't necessarily see a problem with allowing references to Artifacts, but I'm curious where this came up? Any reason not to create a File object to act as the intermediary?
The example in the spec has three attachments: a file, an artifact (an image file??) and (inline) string!
I could certainly create a file for the artifact, but it seems wrong - especially since the cybox schema allows any object. Not sure what to do about the string :-)
(Assuming you're talking about the slider)
To match CybOX 2, you should probably create a File object which is linked as the object_reference, and (where needed) create an Artifact object to store the actual contents of the attachment. If you want to be fancy and use an ImageFile, that is great, but not necessary
I'm not sure how to associate the (Image) File object with the Artifact object, since Files in CybOX don't seem to store actual content. So I just included the Artifact as another object_reference. It looks strange because the xml tag is EmailMessageObj:File.
### <stix:STIX_Package
id="example:STIXPackage-a50ebeb7-0fa1-4eb0-b2ff-7d36d5d82369" version="1.2">
<stix:Observables cybox_major_version="2" cybox_minor_version="1" cybox_update_version="0">
<cybox:Observable id="example:observable-9a28189d-2670-4ba6-b968-d3c475b1ec0a">
<cybox:Object id="example:EmailMessage-294bd89a-3ce0-4422-bf77-620ce9197021">
<cybox:Properties xsi:type="EmailMessageObj:EmailMessageObjectType">
<EmailMessageObj:Header>
<EmailMessageObj:Received_Lines>
<EmailMessageObj:Received>
<EmailMessageObj:From>from mail.example.com ([198.51.100.3]) by smtp.gmail.com with ESMTPSA id q23sm23309939wme.17.2016.07.19.07.20.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Jul 2016 07:20:40 -0700 (PDT)</EmailMessageObj:From>
</EmailMessageObj:Received>
</EmailMessageObj:Received_Lines>
<EmailMessageObj:To>
<EmailMessageObj:Recipient xsi:type="AddressObj:AddressObjectType" category="e-mail">
<AddressObj:Address_Value>bob@example.com</AddressObj:Address_Value>
</EmailMessageObj:Recipient>
</EmailMessageObj:To>
<EmailMessageObj:CC>
<EmailMessageObj:Recipient xsi:type="AddressObj:AddressObjectType" category="e-mail">
<AddressObj:Address_Value>mary@example.com</AddressObj:Address_Value>
</EmailMessageObj:Recipient>
</EmailMessageObj:CC>
<EmailMessageObj:From xsi:type="AddressObj:AddressObjectType" category="e-mail">
<AddressObj:Address_Value>jdoe@example.com</AddressObj:Address_Value>
</EmailMessageObj:From>
<EmailMessageObj:Subject>Check out this picture of a cat!</EmailMessageObj:Subject>
<EmailMessageObj:Date>2016-06-19T14:20:40+00:00</EmailMessageObj:Date>
<EmailMessageObj:Content_Type>multipart/mixed</EmailMessageObj:Content_Type>
<EmailMessageObj:X_Mailer>Mutt/1.5.23</EmailMessageObj:X_Mailer>
<EmailMessageObj:X_Originating_IP xsi:type="AddressObj:AddressObjectType">
<AddressObj:Address_Value>198.51.100.3</AddressObj:Address_Value>
</EmailMessageObj:X_Originating_IP>
</EmailMessageObj:Header>
<EmailMessageObj:Raw_Body><![CDATA[Cats are funny!]]></EmailMessageObj:Raw_Body>
<EmailMessageObj:Attachments>
<EmailMessageObj:File object_reference="example:Artifact-0abf9af2-0993-4d28-b239-58a6a6907229"/>
<EmailMessageObj:File object_reference="example:File-5ea0062a-cbca-4db0-94e3-3bc9d1364658"/>
</EmailMessageObj:Attachments>
</cybox:Properties>
<cybox:Related_Objects>
<cybox:Related_Object id="example:Artifact-0abf9af2-0993-4d28-b239-58a6a6907229">
<cybox:Properties xsi:type="ArtifactObj:ArtifactObjectType" content_type="image/jpeg">
<ArtifactObj:Hashes>
<cyboxCommon:Hash>
<cyboxCommon:Type xsi:type="cyboxVocabs:HashNameVocab-1.0">SHA256</cyboxCommon:Type>
<cyboxCommon:Simple_Hash_Value>effb46bba03f6c8aea5c653f9cf984f170dcdd3bbbe2ff6843c3e5da0e698766</cyboxCommon:Simple_Hash_Value>
</cyboxCommon:Hash>
</ArtifactObj:Hashes>
<ArtifactObj:Raw_Artifact><![CDATA[VBORw0KGgoAAAANSUhEUgAAADI== ...]]></ArtifactObj:Raw_Artifact>
</cybox:Properties>
<cybox:Relationship xsi:type="cyboxVocabs:ObjectRelationshipVocab-1.1">Contains</cybox:Relationship>
</cybox:Related_Object>
<cybox:Related_Object id="example:File-5ea0062a-cbca-4db0-94e3-3bc9d1364658">
<cybox:Properties xsi:type="FileObj:FileObjectType">
<FileObj:File_Name>tabby_pics.zip</FileObj:File_Name>
<FileObj:Magic_Number>504B0304</FileObj:Magic_Number>
<FileObj:Hashes>
<cyboxCommon:Hash>
<cyboxCommon:Type xsi:type="cyboxVocabs:HashNameVocab-1.0">SHA256</cyboxCommon:Type>
<cyboxCommon:Simple_Hash_Value>fe90a7e910cb3a4739bed9180e807e93fa70c90f25a8915476f5e4bfbac681db</cyboxCommon:Simple_Hash_Value>
</cyboxCommon:Hash>
</FileObj:Hashes>
</cybox:Properties>
<cybox:Relationship xsi:type="cyboxVocabs:ObjectRelationshipVocab-1.1">Contains</cybox:Relationship>
</cybox:Related_Object>
</cybox:Related_Objects>
</cybox:Object>
</cybox:Observable>
</stix:Observables>
</stix:STIX_Package>I was suggesting that you could make an object_reference relationship from the Email Message to the File, and then the File could itself have a Related_Object that is the Artifact (contents of the file). Similar to what is being done here, except that the outer File Object would itself be a RelatedObject.
But I think what you did is fine, if not 100% in line with the CybOX spec.
"...then the File could itself have a Related_Object that is the Artifact (contents of the file)."
Yes, I could do that but it would be similar to what was discussed for network-traffic. There isn't a File property for content, so it would just be a RelatedObject without a corresponding object_reference
There's nothing wrong in CybOX with having a Related Object without a direct reference inside the object itself. This was a major criticism of CybOX (having both embedded and external relationships)... and is completely fair. But we can use that to our advantage here. Or not. Your call.
For network traffic, I was most concerned that the top-level object correspond to the top-level object in STIX 2 (network traffic corresponds most directly to network connection), regardless of what embedded/referenced objects are required to represent additional information.
Closing this since we are talking about the slider rather than python-cybox. There's nothing we need to change in python-cybox. It's all about choosing the right CybOX structure when the slider converts email message objects.