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 1 st 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.