-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Timestamps for metadata in profile resolution #580
Comments
@bradh, this is an important question to discuss. My personal opinion is the The reason for this is even though this profile my not have changed the next time it is resolved, one of the up-stream catalogs or profiles may have. The current intention for all OSCAL files is for tools to use the This is just my opinion. I am interested in hearing what others think.
|
Generally concur on the More generally, maybe there are two slightly different needs here:
The first is important for referencing when the source controls change a lot (mine have about 8 versions this year), to address "are we working off the same version?" and "exactly what are you claiming compliance against?" type questions. The second is more important for traceability, and assessing impacts when changes occur. Perhaps we need to use the |
I don't think we need to copy around the titles if we preserve a link to the source. How about the following:
The same could be said for the profile's last-modified date, allowing this to be omitted in the example above. |
@david-waltermire-nist, I like your example as-is, and think we need to set a last-modified date on the resolved profile catalog that reflects when the resolved profile catalog was created. The resolved profile represents a snapshot in time across all upstream profiles and catalogs used in its creation. Even though the immediate upstream profile may not change, it's sources farther upstream (additional profiles as well as catalogs) may change from one resolution to the next, thus the resulting resolved profile would be different. If we just propagate or link to the profile's last-modified date, we may incorrectly imply there has been no change. |
Currently, Additionally: the timestamp of profile resolution is added as a property ( <prop name="resolution-timestamp" value="2021-04-05T14:46:12.99-04:00"/> If this is as wanted, @david-waltermire-nist this Issue is closable. |
@wendellpiez I live in the world where profiles might change less often than the source content. The Australian ISM (https://www.cyber.gov.au/acsc/view-all-content/ism) is issued monthly. My profiles (e.g. "Essential 8") are much slower to evolve. |
We designed profiles with that use case in mind. In this case the timestamp of the resolved profile could indeed be earlier than the 'last-modified' date of a source catalog. Hm. @david-waltermire-nist this points out to me there is actually a set of dates : the Options include:
Interested in opinions on this as it's somewhat crucial when archiving (caching) profile resolutions as catalogs. |
Discussing with @david-waltermire-nist we decided the simplest approach is to assign the time resolution is performed (creation of the resolution artifact) to |
…s the time of resolution (or production of resolution artifact)
Concur. I could also live with "if the profile was (re-)resolved but nothing changed, keep the old date". That would be valid (and might be useful for caching) in the case where my profile is extracting a simple subset of a large catalog, and some of the catalog changed in this month's update, but nothing I'm extracting has changed. |
That is an awesome idea but I suggest it should be a feature of a resolver, to notify if it finds no change in such a case. (After all, to detect no change entails identifying a copy for comparison.) |
Concur. Just want to make sure it is spec-compliant to do so. It might be annoying for the |
Yes. Also what the value is if no file is serialized. Etc. From the point of view of resolution as a function (mapping a to b), adding a timestamp amounts to providing for an arbitrary value provided at runtime. The timestampiness of it is for us to make of and enforce however we can. Our guideline can say "you won't be lying if you provide the time when the resolution was invoked or its results are serialized" (not the same) but it can also leave it up to the resolver to provide a value that makes sense. (Lexical validity to the dateTime format being a given.) In fact this discussion is making me think that the resolver spec should provide latitude for conformant behavior here. I can imagine ornamenting the metadata of serialized resolution output in several interesting ways, for example (perhaps capturing more of the upstream metadata), without wishing to require this for any resolver. Similarly for a value of Interested in any input from @david-waltermire-nist here. BTW, is there a rule that says a "last-modified" date cannot be in the future? |
…e of resolution (or production of resolution artifact)
…e of resolution (or production of resolution artifact)
…e of resolution (or production of resolution artifact)
This was fixed in PR #882. |
The profile resolution spec for Instance metadata (3.4) includes:
In the examples, we have
<prop name="resolution-timestamp">2019-12-10T15:21:20.62-05:00</prop>
, and use the profilelast-modified
as thelast-modified
in the resolved catalog.Should
last-modified
really be the profile timestamp, or the resolution timestamp?The text was updated successfully, but these errors were encountered: