OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] STIX Malware SDO Update


Ah, good catch – thanks Paul. I had updated the description but forgot to change the actual property name – it should indeed be “protocol”.

 

Regards,

Ivan

 

From: Paul Patrick <Paul.Patrick@FireEye.com>
Date: Thursday, August 31, 2017 at 12:46 PM
To: Ivan Kirillov <ikirillov@mitre.org>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] STIX Malware SDO Update

 

Ivan,

 

For consistency, you should rename “protocols” to “protocol” since its not a list.

 

 

Paul Patrick

 

 

From: <cti@lists.oasis-open.org> on behalf of Ivan Kirillov <ikirillov@mitre.org>
Date: Thursday, August 31, 2017 at 2:31 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] STIX Malware SDO Update

 

Small update – I just added the Socket Address Object to the STIX 2.1 Cyber Observables Working Concepts doc [1].

 

[1] https://docs.google.com/document/d/1PHRpmizbMGOwAu_TwRj5ofwnUEOIoM__vIDCDZGf4Sk/edit#heading=h.cwmant2zgmyv

 

Regards,

Ivan

 

From: <cti@lists.oasis-open.org> on behalf of Ivan Kirillov <ikirillov@mitre.org>
Date: Friday, August 25, 2017 at 11:03 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] STIX Malware SDO Update

 

All,

 

I just wanted to give you an update on some of the recent discussions we’ve been having around the Malware SDO for STIX 2.1.

 

·         Capturing analysis data: one property for all data (analysis_data) vs. two for specific types of data (static_analysis_data and dynamic_analysis_data):

o   After further discussion, the consensus seems to be towards the latter approach (two properties). The rationale is that current malware analysis processes are generally based on performing static analysis (for initial triage or deep dive analysis) and dynamic analysis (for executing binaries and recording their behavior). Thus, this model aligns well with current practices and makes it easy  to map tool output accordingly, and also permits the capture of only STIX Cyber Observable data for dynamic analysis.

·         Capturing configuration parameters (based on MWCP) in STIX. This has been an ongoing discussion and effort (much thanks to Gary and Anne at DC3 for their assistance and input here!), and Trey and I have put together a mapping of MWCP parameters into STIX, with a focus on trying to map things into STIX Cyber Observable objects much as possible. However, there are some gaps and corner cases that we discussed today:

o   MWCP captures socket addresses and ports, which currently cannot be represented in STIX (the network-traffic Object does not make sense for this semantically). Accordingly, we’ve proposed adding a new STIX Cyber Observable Socket Address object, which would have properties of Address, Port, and Protocols. All properties would be defined as optional though one of Port or Address would be required, which would allow us to use the object for socket addresses and also ports (e.g., listening ports). There was consensus on the call today that this was a reasonable addition, so we’ll put something together and add to the STIX 2.1 Cyber Observables Working Concepts doc.

o   MWCP captures credentials (e.g., default login username/passwords) that malware may try to use in its operations. We have a corresponding User Account Object that would work here, though it currently cannot capture passwords. We discussed this and there was consensus on the call that we could add a password property, with the clarification that it is meant for use cases such as this one and not intended for exchange of PII data in STIX. We’ll work on adding a draft of this property to the User Account object.

o   MWCP captures properties of Windows services as single entries (e.g., service description, service DLLs, etc.). At the moment capturing these as singletons conflicts with our windows-service-ext (an extension for the Process Object) because service_name is a required property on this extension. However, we could make service_name not required and therefore permit this capture, though this would break forwards compatibility with regard to STIX 2.0 -> STIX 2.1. That said, this would likely not have a huge impact on end-users and is something we could address in tools, so it maybe a reasonable change – the consensus was that we should investigate it further to see if it will be feasible.

 

Please let us know if you have any thoughts or input on these topics, as we could certainly use more input. Also, we’ll be continuing our discussions at the next Friday working call (September 1st at 11:00am EDT).

 

As always, you can find the STIX 2.1 Malware SDO here: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.73mue8q00k8

 

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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]