Ivan,
Your timing is perfect as I’m in the middle of mapping OpenIOC 1.1 definitions to STIX Indicators and uncovering several things that are currently missing in STIX 2.0 that are needed to support a complete
mapping. The able to specify the Handles on a Process is one of the most frequent ones I’ve found. So, I think at a minimum we’re going to need a handles-like property on windows-process-ext. I suspect we’re going to also need something like a windows-handle
object since it often critical for detection to specify both the name assigned to the handle and the type of the handle.
Other significant items missing from the windows-pebinary-ext include:
·
Information about exports (DLL Name, number of functions, exported function names)
·
Information about imports (Modules, module name, number of imported functions, imported function names)
On windows-process-ext:
·
Information about processes (Memory sections, section name, handles, handle name, handle type)
On windows-service-ext:
·
Hash on the service DLL
Object types that I’ve found that would needed to be include to complete the OpenIOC mapping include:
·
Windows System Restore
·
Windows Prefetch
·
DNS Record
·
EventLog (something we didn’t have in CybOX)
There is a more complete list of terms at
http://openioc.org/terms/Current.iocterms One other thing that I saw was that often the OpenIOC will have alternate patterns for detection; particularly that of Snort and YARA. I know we’ve talked about this as a group, but here is a concrete use
case in the “wild” that we might want to take into consider as we talk through the ability to express alternate pattern expressions.
For our internal use, I’m going to need to define extensions to address these. But that still leaves me faced with just when we can consider transition to STIX 2 for our external customers and partners.
Hope this helps!
Paul Patrick
From:
<
cti@lists.oasis-open.org> on behalf of Ivan Kirillov <
ikirillov@mitre.org>
Date: Thursday, December 22, 2016 at 2:15 PM
To: Paul Patrick <
Paul.Patrick@FireEye.com>, "cti@lists.oasis-open.org" <
cti@lists.oasis-open.org>
Subject: Re: [cti] STIX 2.1 & Cyber Observables
That’s a good point, Paul. In CybOX 2.x we had a separate Windows Handle Object that was used by other Windows Objects. However, I’m wondering if that approach was overkill – most
use cases that I’ve seen around handles in terms of malware analysis/IR revolve around handles opened by a particular process. Therefore, would it be enough to add the ability to characterize opened handles as part of the existing Windows Process Extension
for the Process Object?
Regards,
Ivan
From:
Paul Patrick <
Paul.Patrick@FireEye.com>
Date: Thursday, December 22, 2016 at 11:55 AM
To: Ivan Kirillov <
ikirillov@mitre.org>, "cti@lists.oasis-open.org" <
cti@lists.oasis-open.org>
Subject: Re: [cti] STIX 2.1 & Cyber Observables
One glaring thing missing from most of the windows specific objects is the concept of Windows Handle.
From:
<
cti@lists.oasis-open.org> on behalf of Ivan Kirillov <
ikirillov@mitre.org>
Date: Thursday, December 22, 2016 at 11:55 AM
To: "cti@lists.oasis-open.org" <
cti@lists.oasis-open.org>
Subject: [cti] STIX 2.1 & Cyber Observables
All,
As we discussed on the call last week, Trey and I have been thinking over some possibilities as far as new additions for Cyber Observables in 2.1. Here’s the list that we’ve put together
– note that this is meant to be a strawman so that we can start having the discussion about what you (the community) wants to see in 2.1 as far as Cyber Observables:
Entity Type
Entity
New Objects
Device
- Mobile Device Ext.
- Mobile Phone Ext.
- Virtualization Ext.
Operating System
WHOIS
SMS
- MMS Ext.
Network Share
New Object Extensions
Android APK (File Object Ext.)
Apple iOS (File Object Ext.)
EXT 3/4 (File Object Ext.)
Document Metadata (File Object Ext.)
HTTP Response (Network Traffic Ext.)
Other Entities
Actions
If you have any thoughts on things you want to see in 2.1 for Cyber Observables, please bring them up – we’re very open to any suggestions and ideas.
Happy Holidays!
Ivan and Trey
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.
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.