Preserve Sysmon ProcessGUID whenever possible

[pcoccoli]

Is your feature request related to a problem? Please describe.
Sysmon events include a ProcessGUID field that's needed to correlate events from the same process. It also would give us a way to generate deterministic IDs for process objects in STIX 2.1.

Describe the solution you'd like
Modify all relevant module mappings so the ProcessGUID (or equivalent) is available in STIX output.

Could define a new extension 'process-ext' to hold this ID and other fields common to data sources but not STIX. Or simply x_unique_id like the Carbon Black Response module.

Modules:

• QRadar: Process Guid is available through Sysmon content extension but not available in the mappings yet
• Splunk: process_guid [https://docs.splunk.com/Documentation/CIM/5.0.1/User/Endpoint#Processes]
• Elastic ECS: process.entity_id [https://www.elastic.co/guide/en/ecs/current/ecs-process.html#field-process-entity-id]
• Carbon Black Cloud: process_guid [ https://developer.carbonblack.com/reference/carbon-black-cloud/platform/latest/platform-search-fields/]
• Others: need to determine the proper field (or any equivalent unique ID, not necessarily a GUID)

Describe alternatives you've considered
None

Additional context
https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon#events

@mdazam1942

[subbyte]

This will be an important-yet-practical fix for cross-observation SCO recognition/deduplication, which is critical to any reasoning/hunting that fetch multiple queries back. For most types of SCOs, such as ipv4-addr and email-addr, the value can be used as the identifier. The two challenging SCOs are process and file, which STIX do not have mandatory fields, even pid, not to mention UUID.

I strongly second this ticket, which will benefit any downstream application of stix-shifter for large-scale reasoning besides one query.

[delliott90]

Just so I understand the ask. STIX 2.1 spec recommendation is to use a UUIDv4 for the id on the process object, since all fields are optional. The recommendation in this case is add a new process_guid property or extension to the object and when available, use it as the id contributing property for the generated id. Connectors that don't have a process_guid mapping would still need to fall back to UUIDv4. It's actually a gap we've seen in the 2.1 standard, there are other objects that still list id contributing properties, but they are all optional properties; the user-account object springs to mind.

[pcoccoli]

Yes @delliott90 - that's a good summary.
Whenever possible, we want UUID5 (i.e. "deterministic") IDs. Of the standard SCOs, only process has no ID contributing properties. user-account uses account_type, user_id, account_login though you're correct in that all 3 are optional.