Malware Analysis Needs Sample Refs property

[dc3-tsd]

Malware Analysis Needs Sample
Currently the Malware Analysis object does not have a sample_ref property to indicate what file or artifact the malware analysis was performed against. A sample_refs property is present for the Malware object so I believe that creating this embedded relationship makes sense.

Malware Analysis also included an embedded analysis_sco_refs which links to artifacts produced by the malware analysis, so including the sample as an embedded relationship will allow us to remain consistent.

I believe that this should be added in the following manner:

Name: sample_ref (optional)
Type: identifier
Description: The sample_ref property specifies an identifier for the SCO file, network traffic or artifact object that this malware analysis was performed against.

This field should be optional because Malware Analysis can also refer to generalized results against a family of malware instead of a specific instance of it.

I added the option to link this to Network Traffic, which is not in Malware since there are a number of packet sniffing tools that can identify potentially malicious traffic, which may wish to use Malware Analysis to flag netflow data.

[rpiazza]

@dc3-dcci: I changed the title because coincidently there is issue #206, which is a different topic but a similar title.

[jordan2175]

I agree with this change, we will talk about on the next working call.

[rpiazza]

I'm not sure this is the best way to handle this - since sample_ref could be used to hold the malware instance, instead of using the relationship - which is two ways to do something in STIX.

Maybe, you have a relationship from the malware analysis to the file directly....?

[jordan2175]

That is what we are doing, just using an embedded relationship like what we do with Malware.

[jordan2175]

We talked about this on the 2020-01-28 working call. Ivan will help with some language to make sure producers do things correctly for a malware instance. The consensus on the call is to make this change.

[ikiril01]

Here's some suggested text for the Malware Instance use case. This is a bit wordy but hopefully you can see what I'm getting at:

"Note: when this property is used in conjunction with a Malware SDO that characterizes a malware instance (via an SRO), it SHOULD capture a sample that is associated with the malware instance. That is, one that is either referenced in the Malware SDO's sample_refs property, or one that is not referenced but provides supporting contextual information associated with the malware instance, such as captured network traffic."

[jordan2175]

We added this property per the working call. But we need to talk with Ivan about his text before we add it. Rich P. is going to talk to Ivan.

[rpiazza]

I discussed this with Ivan - and wrote this alternative text:

"If this malware analysis object is related to a malware object via an SRO, the value of this property MUST be a one of the sample_refs of that malware object. Note, this property can also contain a reference to an SCO which is not associated with malware (i.e., some SCO which was scanned and found to be benign)."

[jordan2175]

I do not think that will work because the Malware Analysis object may be created first and then later linked by someone else to some malware object. We can not put a MUST statement here. I think we should re-write this as informational text.

[jordan2175]

We have proposed the following text in the document. If you would like a change or want to word-smith this, please do so.

Caution should be observed when creating an SRO between Malware and Malware Analysis objects when the Malware sample_refs property does not contain the SCO that is included in the Malware Analysis sample_ref property.

Note, this property can also contain a reference to an SCO which is not associated with malware (i.e., some SCO which was scanned and found to be benign.