Questions about UCO observable:NTFSFile

[joachimmetz]

From https://ontology.unifiedcyberontology.org/documentation/class-observablentfsfile.html

core:modifiedTime	owl:DatatypeProperty	Specifies the time that this particular version of the object was modified. The object creator can use the time it deems most appropriate as the time this version of the object was modified. The value of the modified property for a given object version MUST be later than or equal to the value of the created property. Object creators MUST update the modified property when creating a new version of an object. The modified timestamp MUST be precise to the nearest millisecond (exactly three digits after the decimal place in seconds).

Shouldn't this be: Specifies the time that this particular version of the object was last modified.

Given other modification could have occurred your data might no longer contain a record of it

The modified timestamp MUST be precise to the nearest millisecond (exactly three digits after the decimal place in seconds).

Where can I find the rationale for this MUST?

[vulnmaster]

Thanks for raising this, Joachim. Good catch on both the wording and the provenance of the MUST.

I created this response with the assistance of the CASE/UCO SDK MCP from https://github.com/vulnmaster/CASE-UCO-SDK, where the MCP is powered by Grok 4.5 High Fast.

1. Which modifiedTime is this?

The property shown on the observable:NTFSFile documentation page as core:modifiedTime is not the NTFS / filesystem last-modified timestamp. It is inherited from core:UcoObject and records when this characterization / object version was modified in the graph (object versioning metadata), not an intrinsic attribute of the file on disk.

For filesystem / artifact last-modified time, UCO already has a separate property:

• observable:modifiedTime - “The date and time at which the Object was last modified.”

That is the property used on facets such as FileFacet for the observed object's modification time. So if the concern is “other modifications may have occurred and your data may no longer contain a record of them,” that is exactly the semantics of the observable property: it conveys the last known modification time present in the evidence, not a complete modification history.

2. Should core:modifiedTime say “last” modified?

I agree that inserting “last” would make the definition clearer and would better match current STIX wording. STIX 2.1 describes modified as the time that “this particular version of the object was last modified.”

That said, even with “last,” core:modifiedTime still means “last modification of this UCO object version / record,” not “last modification of the underlying cyber-observable.” Intermediate filesystem modifications that were overwritten are out of scope for core:modifiedTime; those belong under observable:modifiedTime (and related observable timestamp properties).

Happy to treat a wording clarification on core:modifiedTime as a UCO documentation / definition improvement.

3. Rationale for the millisecond MUST

That sentence was not invented for CASE/NTFS. It was imported into UCO when core:modifiedTime was added for object versioning (ucoProject/UCO#164, split from #158), and the text is essentially the STIX 2.0 Common Properties language for modified:

The modified timestamp MUST be precise to the nearest millisecond (exactly three digits after the decimal place in seconds).

See STIX 2.0 Part 1.

The STIX TC’s rationale (ordering / interoperability for versioned objects; the so-called “Great Timestamp Precision Debate”) is discussed in oasis-tcs/cti-stix2#219. Importantly, STIX 2.1 later relaxed this: minimum precision is milliseconds, but values MAY be more precise. UCO’s comment still reflects the older STIX 2.0 “exactly three digits” wording, so aligning UCO with the STIX 2.1 formulation is a reasonable follow-up.

Next step

This is a UCO core definition / docs issue rather than a CASE one. I can transfer or refile against ucoProject/UCO if that helps track a wording update for core:modifiedTime (and possibly alignment of the precision MUST with STIX 2.1).

[joachimmetz]

This is a UCO core definition / docs issue rather than a CASE one. I can transfer or refile against ucoProject/UCO if that helps track a wording update for core:modifiedTime (and possibly alignment of the precision MUST with STIX 2.1).

Thanks. Be aware that I'm not an expert in CASE/UCO. I described my use case in #197. If you have a CASE/UCO primer somewhere (preferably close to my use case) let me know.

The property shown on the observable:NTFSFile documentation page as core:modifiedTime is not the NTFS / filesystem last-modified timestamp.

Especially the last part of this sentence is useful to know, maybe this should be more clear in the documentation. From my first glance I assumed this was a 1-to-1 mapping.

[joachimmetz]

The STIX TC’s rationale (ordering / interoperability for versioned objects; the so-called “Great Timestamp Precision Debate”) is discussed in oasis-tcs/cti-stix2#219. Importantly, STIX 2.1 later relaxed this: minimum precision is milliseconds, but values MAY be more precise. UCO’s comment still reflects the older STIX 2.0 “exactly three digits” wording, so aligning UCO with the STIX 2.1 formulation is a reasonable follow-up.

Thanks for that link, useful context. I would recommend capturing the crux of this somewhere. Given quite beneficial to people not familiar with the history of the standards.

[vulnmaster]

Agreed on the need to make documentation improvements. We are about to release v1.5.0 of CASE and UCO, but I think that we can prioritize this documentation update for our next release. I find it easiest to use the CASE/UCO SDK MCP to help you with concept mappings, serialization, and graph validation.

https://github.com/vulnmaster/CASE-UCO-SDK

Post any issues or feature requests you have with the SDK to that repository as this is still a work in progress.

[joachimmetz]

Digging a bit deeper here using xsd:string for an NTFS file name will prevent storing specific names. See https://osdfir.blogspot.com/2023/07/whats-in-file-path.html for context and similar issue in dfxml dfxml-working-group/dfxml_schema#34

xsd:string is a built-in primitive XML Schema data type used to define character strings that can contain any Unicode characters allowed by XML

What are the encoding rules for such file names?