Proposal for an open and deterministic endpoint process UUID

[mlmitch]

In Cisco's Endpoint Security organization, we've developed and implemented a specification for deterministically calculating an identifier that uniquely identifies an endpoint process across an organisation.
This writeup proposes open-sourcing this technology under OCSF.

Endpoint security products supplement operating system process identifiers (PIDs) with unique process identifiers.
This is necessary as operating system PIDs are frequently reused, making them poor identifiers across time.
The need for unique process identification is also realized within OCSF by the process.uid field that exists in addition to the process.pid field.

Unfortunately, each endpoint product uses its own scheme for unique process identification.
These schemes are opaque/proprietary or a random identifier is generated by the product.
This means that unique process identifiers do not match when a security practitioner looks across multiple endpoint datasets.

We encountered this problem within Cisco when trying to analyze dataset from two different products that use endpoint data.
Instead of having these products communicate on the endpoint, we decided to pursue a rigorous specification for creating a unique identifier from operating system provided information.
This enables the different products to deterministically arrive at the same unique identifier without implementing any synchronization.

We realized this approach would generalize well to any endpoint security tooling.
OCSF is a good fit for this technology given that it seeks to enable working with "... a common language for threat detection and investigation".
Our identifier specification can extend this common language to include effective identification of endpoint processes.

If this proposal is friendly to the community, we propose the following plan of action:

1. A repository is created in https://github.com/ocsf that can host the specification and platform-specific reference implementations.
2. Cisco contributes the specification to this repository where it can be reviewed by the community and changes can be proposed. Note that breaking changes would need to be carefully considered. Part of the specification's value is its current deployment footprint in Cisco products.
3. The specification is "ratified" in some manner by the community.
4. Cisco and interested community participants contribute platform-specific reference implementations that can be used directly in endpoint software or used to gauge the correctness of custom implementations.
5. Consider the creation of a dedicated field for this identifier in the process object. We would likely need to represent both the new identifier and the existing proprietary identifiers implemented by endpoint software.

[mavam]

This idea reminds me of the endpoint dual to the Community ID.

[mlmitch]

Definitely a reasonable way to look at it.

[zschmerber]

These all seem like fingerprints, similar to the JA4+ fingerprint.

https://schema.ocsf.io/1.3.0/objects/ja4_fingerprint?extensions=

[mikeradka]

Somewhat along the lines of @zschmerber's note, it seems either like a fingerprint or maybe even a uuid. For the sake of simplicity, I wonder whether this use case could be tackled by introducing a new attribute.

[mlmitch]

Aye - these are also fair interpretations.

maybe even a uuid

It is an RFC-compliant UUID that is produced.

wonder whether this use case could be tackled by introducing a new attribute

I do mention this possibility in point 5 above.

These all seem like fingerprints, similar to the JA4+ fingerprint.

Something to keep in mind with community_id, j4a and others: they have pre-existing specs that exist elsewhere.
There is no pre-existing public spec here, so there is an opportunity for OCSF to be the home for the spec.

[JasonKeirstead]

The way this was done in STIX was by prescribing which object attributes were to be included when the RFC 4122 v5 UUID was generated.

For example, for a process, you could say that one should include the process ID, the creation timestamp, and the machine host. That should be sufficient to create a globally unique process ID that is common among products.

That is really all that needs to be perscribed. You don't need to describe how to make a UUID, this is defined in the RFC.

[mlmitch]

Suggestions from the community call today were to:

1. Write a https://github.com/ocsf/ocsf-docs pull request with the identifier specification
2. Create a schema PR that ensures all identifier hash inputs have a home in OCSF.

The schema PR might not turn out great due to some timestamp resolution differences as well as the identifier hash inputs being different on Windows/MacOS/Linux. I'll still make a draft PR so these issues can be highlighted at the very least.

[mlmitch]

Docs PR: ocsf/ocsf-docs#45

[mlmitch]

spec going here now: ocsf/common-process-id#1

[mlmitch]

Shema PR: #1246