Two follow-on ideas for versioning

8 messages

Two follow-on ideas for versioning

Reply Threaded

Hello all,

Two suggestions have been received beyond those covered in the developers meeting:

- The meeting focused on specifying the version of check structures (e.g. OVAL definitions). However, the proposal also noted that, in OVAL, external_variables also have a version. Since OVAL external_variables contain structures that can restrict the allowed values the variable is permitted to assume, changes to an OVAL external_variable could indeed affect the results of a check. Given this, it seems consistent with the other decisions of the meeting for check-export elements also to be modified to optionally specify the version of the destination variable and that this version information be recorded in a similar way in rule-result structures if it is not explicitly specified in the check-ref.

- The meeting noted that it would be useful to be able to specify ideas such as "any version greater than X" in a check ref, but decided not to implement this given the requirement this imposed that all check interpreters have a consistent understanding of ordering within their own checking languages. However, it was noted that if a regular expression was permitted in the version identifier, that this could support a way of saying "any version greater than X" in a way that all checking engines could agree.

If you have any thoughts on these additional proposals, please provide feedback to the list.

Thanks,
Charles

---------------------------------------------------------------

To unsubscribe from this mailing list, please send an e-mail to
[hidden email] with the words "unsubscribe xccdf-dev" in the
body. You will need to send this from the email account that you
used to initially subscribe to xccdf-dev.

Waltermire, David

RE: Two follow-on ideas for versioning

Reply Threaded

Community members,

It might be best if we can find a way forward that doesn't require special processing by an XCCDF-based tool to determine which check system specific version to use. By requiring additional processing logic, we risk greater implementation complexity and potentially some drift in application logic.

Instead we should consider the approach that the W3C uses to reference document revisions. I believe this was mentioned on the call. For a given document, they use two "flavors" of URLs: 1) a URL that references a specific revision, and 2) a URL that references the most current revision. This will essentially allow the content author to choose the correct behavior by way of making the appropriate reference.

For example:

XML Schema:

Latest: http://www.w3.org/TR/xmlschema-1/
Current: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
Previous: http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/

In the case of OVAL we could use the following syntax:

Latest:

<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-export value-id="xyz_var"
export-name="oval:foo.net:var:123" />
<check-content-ref href="..."
name="oval:foo.net:def:456" />
</check>

Building on the example that Gary provided on the call, a specific version reference might look like:

<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
<check-export value-id="xyz_var"
export-name="oval:foo.net:var:123#2" />
<check-content-ref href="..."
name="oval:foo.net:def:456#3" />
</check>

This example references revision 2 of the OVAL variable oval:foo.net:var:123 and revision 3 of the OVAL definition oval:foo.net:def:456.

The advantage of this approach is that an XCCDF tool does not need to know how a check system or content repository handles revisions. Instead this processing is delegated to the check system. I agree completely with what was discussed on the call regarding recording the specific version used in the results. This can be done in either the XCCDF or check system results or both. I am not sure at this time where would be the best place to put it.

Thoughts?

Sincerely,

David Waltermire
SCAP Architect
National Institute of Standards and Technology
(301) 975-3390
[hidden email]

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Schmidt,
> Charles M.
> Sent: Friday, October 09, 2009 12:29 PM
> To: Multiple recipients of list
> Subject: Two follow-on ideas for versioning
>
>
> Hello all,
>
> Two suggestions have been received beyond those covered in the developers
> meeting:
>
> - The meeting focused on specifying the version of check structures (e.g.
> OVAL definitions). However, the proposal also noted that, in OVAL,
> external_variables also have a version. Since OVAL external_variables
> contain structures that can restrict the allowed values the variable is
> permitted to assume, changes to an OVAL external_variable could indeed
> affect the results of a check. Given this, it seems consistent with the
> other decisions of the meeting for check-export elements also to be
> modified to optionally specify the version of the destination variable and
> that this version information be recorded in a similar way in rule-result
> structures if it is not explicitly specified in the check-ref.
>
> - The meeting noted that it would be useful to be able to specify ideas
> such as "any version greater than X" in a check ref, but decided not to
> implement this given the requirement this imposed that all check
> interpreters have a consistent understanding of ordering within their own
> checking languages. However, it was noted that if a regular expression was
> permitted in the version identifier, that this could support a way of
> saying "any version greater than X" in a way that all checking engines
> could agree.

---------------------------------------------------------------

To unsubscribe from this mailing list, please send an e-mail to
[hidden email] with the words "unsubscribe xccdf-dev" in the
body. You will need to send this from the email account that you
used to initially subscribe to xccdf-dev.

bakerj

RE: Two follow-on ideas for versioning

Reply Threaded

>
>The advantage of this approach is that an XCCDF tool does not need to know
>how a check system or content repository handles revisions. Instead this
>processing is delegated to the check system. I agree completely with what
>was discussed on the call regarding recording the specific version used in
>the results. This can be done in either the XCCDF or check system results
>or both. I am not sure at this time where would be the best place to put
>it.
>
>Thoughts?
>

I like the sound of this approach, but wonder if we can safely delegate the version handling to the check system? For OVAL this is pretty simple. I would expect that the same is also true for OCIL. However, is it reasonable for all check systems to have some way of supporting this versioning processing?

My question of course leads to another question. What other check systems are being used? Knowing this would help us make sure that we are putting reasonable expectations on check systems.

Jon

============================================
Jonathan O. Baker
G022 - IA Industry Collaboration
The MITRE Corporation
Email: [hidden email]

---------------------------------------------------------------

To unsubscribe from this mailing list, please send an e-mail to
[hidden email] with the words "unsubscribe xccdf-dev" in the
body. You will need to send this from the email account that you
used to initially subscribe to xccdf-dev.

Charles Schmidt (MITRE)

RE: Two follow-on ideas for versioning

Reply Threaded

Hi David & Jon,

I think the proposal I just set out follows your overall suggestion. A couple differences:

- In check-content-refs, the anchor markings (used for both version and name) are all in the href, not in the name field. Putting this all in one location seemed reasonable to me.
- In check-export, version remains a separate field.
- In both cases, I still created a separate version field so authors could break out information into separate fields (as is currently done) instead of using a single URI. Given that we don't want to incur an unnecessary major release by actually removing the "name" field in check-content-refs, allowing people to continue to break things apart if they wished would introduce no additional overhead.
- In the proposal, version info must be recorded in the check blocks of rule-results, but only if the version is not explicit within the check-ref and/or check-export itself. I felt there is benefit to having the rule-results record the highest level of information while also having the checking language construct a more detailed processing log that could be used upon request.

I mention these reasons to explain my thoughts when putting the proposal together but don't feel particularly adamant about them. What are your thoughts?

> The advantage of this approach is that an XCCDF tool does not need to know how a check
> system or content repository handles revisions.

While I am personally in favor of moving towards a more standardized, URI-based reference scheme, I don't see how the above statement is true. Why would a tool need to understand checking system versions for a non-URI based scheme? Specifying check versions, in any format, requires no more processing for an XCCDF tool than do the processing of component names, which also lack standardization across languages. I see the major argument in favor of using URIs is simply that it makes the references themselves standards based rather than dependent on the language making the reference (but not necessarily on the language being referenced).

On that note, what would people say about standardizing the format of references to URIs with anchors? That is, when XCCDF (or anyone) is requesting a particular component of an OVAL (or other format) file, the file + component would be identified via a URI rather than via multiple, potentially implementation-specific, fields. This strikes me as something that would need to be dictated at the SCAP level, rather than via XCCDF.

Charles

>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]] On Behalf Of Baker,
>Jon
>Sent: Thursday, October 15, 2009 6:12 AM
>To: Multiple recipients of list
>Subject: RE: Two follow-on ideas for versioning
>
>
>>
>>The advantage of this approach is that an XCCDF tool does not need to
>know
>>how a check system or content repository handles revisions. Instead
>this
>>processing is delegated to the check system. I agree completely with
>what
>>was discussed on the call regarding recording the specific version used
>in
>>the results. This can be done in either the XCCDF or check system
>results
>>or both. I am not sure at this time where would be the best place to
>put
>>it.
>>
>>Thoughts?
>>
>
>I like the sound of this approach, but wonder if we can safely delegate
>the version handling to the check system? For OVAL this is pretty
>simple. I would expect that the same is also true for OCIL. However, is
>it reasonable for all check systems to have some way of supporting this
>versioning processing?
>
>My question of course leads to another question. What other check
>systems are being used? Knowing this would help us make sure that we are
>putting reasonable expectations on check systems.
>
>
>Jon
>
>============================================
>Jonathan O. Baker
>G022 - IA Industry Collaboration
>The MITRE Corporation
>Email: [hidden email]
>
>
>
>
>
>
>
>---------------------------------------------------------------
>
>To unsubscribe from this mailing list, please send an e-mail to
>[hidden email] with the words "unsubscribe xccdf-dev" in the
>body. You will need to send this from the email account that you
>used to initially subscribe to xccdf-dev.

Charles Schmidt (MITRE)

RE: Two follow-on ideas for versioning

Reply Threaded

In reply to this post by Charles Schmidt (MITRE)

Due to problems with the mailing list, I am forwarding this message from Dick Whitehurst:

Charles

----------------

Community members,

Unfortunately, I was unable to participate in the call discussing the versioning proposal. However, I have a couple of serious reservations about the proposal, primarily because I believe that simply specifying a version for the OVAL definition element fails to *fully* and *uniquely* define the contents of the check. In particular, I know of no rule that states that a definition's version should change other than when the definition element itself changes. There is no published rule (that I have been able to find) that defines that the changing an oval element's version should result in the change of the version of any element referring to it, either directly or indirectly.

An example would be for a local variable that retrieves the path for %systemroot% from the registry. If this local variable, or the registry_object it refers to, changes, there is nothing to indicate that the definition element referring to it should have a new version number.

Secondly, from a practical point of view, this would imply that the repository system (the oval_definitions xml file or other) would need to change to support the notion that the unique identifier of an oval element is not simply the id, but rather the combination of id *and* version.

I apologize if this was covered in the discussion, but I didn't see any discussion of it in the summary document.

Thanks,

Dick Whitehurst

---------------------------------------------------------------

To unsubscribe from this mailing list, please send an e-mail to
[hidden email] with the words "unsubscribe xccdf-dev" in the
body. You will need to send this from the email account that you
used to initially subscribe to xccdf-dev.

Richard_Whitehurst

comments on the usefulness of versioning and an additional consideration

Reply Threaded

In reply to this post by Charles Schmidt (MITRE)

Community members,

Unfortunately, I was unable to participate in the call discussing the versioning proposal. However, I have a couple of serious reservations about the proposal, primarily because I believe that simply specifying a version for the OVAL definition element fails to *fully* and *uniquely* define the contents of the check. In particular, I know of no rule that states that a definition's version should change other than when the definition element itself changes. There is no published rule (that I have been able to find) that defines that the changing an oval element's version should result in the change of the version of any element referring to it, either directly or indirectly.

An example would be for a local variable that retrieves the path for %systemroot% from the registry. If this local variable, or the registry_object it refers to, changes, there is nothing to indicate that the definition element referring to it should have a new version number.

Secondly, from a practical point of view, this would imply that the repository system a tool vendor uses (the oval_definitions xml file or other) would need to change to support the notion that the unique identifier of an oval element is not simply the id, but rather the combination of id *and* version.

I apologize if this was covered in the discussion, but I didn't see any discussion of it in the summary document.

Thanks,
Dick Whitehurst

PS If versioning must be supported, I think the approach of including the version in the uri would be a better approach than adding additional attributes to convey that information.

---------------------------------------------------------------

To unsubscribe from this mailing list, please send an e-mail to
[hidden email] with the words "unsubscribe xccdf-dev" in the
body. You will need to send this from the email account that you
used to initially subscribe to xccdf-dev.

Charles Schmidt (MITRE)

RE: comments on the usefulness of versioning and an additional consideration

Reply Threaded

Hello,

The proposal that I sent out recently does contain a section that states that changes to the behavior of a check item (e.g. an OVAL Definition) should be accompanied by some marking that can be selected against from XCCDF (namely, a change in name or version). Since the change of a local variable would do that, according to the procedure outlined, any OVAL definition that eventually made use of that changed variable would need to have an updated version.

Clearly there are many issues with this proposal, most revolving around the fact that it relies on content producers making the effort to follow it and correctly and completely tracing reference trees. A single local variable might trace a path through many dozen OVAL elements and tracking this without good tools is hard.

Because of OVAL's highly modular structure, fully specifying a trace of a check in the check-reference itself runs into the same problem noted above - one would need to document a complex tree of names and versions to be completely specific. This would not be an issue if OVAL components themselves were specific about the versions of items they reference, but that isn't the case and the OVAL team has reasons for this choice.

An ineffective change is worse than no change at all, so we should only go forward with this if it is going to actually provide benefit.

Idea #1 - what if OVAL added a new optional structure that I'll call a definition-manifest. It would be tied to a definition and would simply enumerate the name and version of every OVAL structure touched in the processing of that definition. Definition manifests would also be versioned. If XCCDF referenced a particular version of a definition manifest it would be like saying "run this definition, and make sure that the name and version of everything that is called can be found in the manifest". That would pin down a single version of everything without forcing a variable change to version everything that touched it. Only parties who wished to be particular about the version of everything referenced in a definition would need to create a manifest. In particular, the OVAL Repository probably would not need manifests for all entries. Updating content would be simple - if I update a local-variable then I only need to change that variable's version in the manifests where it appe!
ars and to version the manifest itself. It becomes unnecessary to re-trace and version everything in the same tree as that variable.
My thought is that such a structure probably belongs in the OVAL language rather than XCCDF. This idea would not significantly change the explicit versioning proposal as set out earlier, except in that it might lessen the requirement on content producers to completely trace the effects of changes.

Idea #2 - scrap the use of versions and instead use digital signatures applied to files. This will do the best job of ensuring that authoritative content isn't replaced. On the other hand, it means that, if an organization wished to tailor a benchmark (either signed or unsigned) and then control further evolution, they would need to apply their own digital signatures to everything every time they update content.

Thoughts?

Charles

>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]] On Behalf Of
>[hidden email]
>Sent: Thursday, October 15, 2009 12:56 PM
>To: Multiple recipients of list
>Subject: comments on the usefulness of versioning and an additional
>consideration
>
>
>Community members,
>
>
>Unfortunately, I was unable to participate in the call discussing the
>versioning proposal. However, I have a couple of serious reservations
>about the proposal, primarily because I believe that simply specifying a
>version for the OVAL definition element fails to *fully* and *uniquely*
>define the contents of the check. In particular, I know of no rule that
>states that a definition's version should change other than when the
>definition element itself changes. There is no published rule (that I
>have been able to find) that defines that the changing an oval element's
>version should result in the change of the version of any element
>referring to it, either directly or indirectly.
>
>An example would be for a local variable that retrieves the path for
>%systemroot% from the registry. If this local variable, or the
>registry_object it refers to, changes, there is nothing to indicate that
>the definition element referring to it should have a new version number.
>
>Secondly, from a practical point of view, this would imply that the
>repository system a tool vendor uses (the oval_definitions xml file or
>other) would need to change to support the notion that the unique
>identifier of an oval element is not simply the id, but rather the
>combination of id *and* version.
>
>I apologize if this was covered in the discussion, but I didn't see any
>discussion of it in the summary document.
>
>Thanks,
>Dick Whitehurst
>
>PS If versioning must be supported, I think the approach of including
>the version in the uri would be a better approach than adding additional
>attributes to convey that information.
>
>
>---------------------------------------------------------------
>
>To unsubscribe from this mailing list, please send an e-mail to
>[hidden email] with the words "unsubscribe xccdf-dev" in the
>body. You will need to send this from the email account that you
>used to initially subscribe to xccdf-dev.

Eric Walker

RE: comments on the usefulness of versioning and an additional consideration

Reply Threaded

During the recent conference we discussed the matter of versioning, as well as the use of digital signatures and SHA1 hashes instead of versioning. I didn't get a clear sense of whether there was consensus on the use of signatures instead of explicit versions, or whether the majority of participants simply did not have an opinion one way or the other. But the point was made that digital signatures will play a useful role later on in establishing a chain of trust, once we start getting into remediation. For good reasons, SHA1 hashes were seen as being inadequate in this regard, even when they have been made available on a Web site such as NIST's. One participant explained that the issue there was that NIST's Web site could be compromised and hashes of malicious XCCDF files published.

As I understand it, what makes SHA1 hashes otherwise preferable to digital signatures is that they are a more lightweight way of handling things, and, I would argue, they are a best practice that has served open source projects well. My understanding is that a certificate or set of certificates is needed in order to verify a digital signature, and that these certificates will need to be obtained somehow. I have no issue with the use of digital signatures in the present context, it just seems like a lot of overhead for a field that is serving in part as a version and could potentially appear in many places in a document.

One thought here is that it would be sufficient to be able to trace SHA1 hashes (or SHA-224 hashes or whatever) back to something that has been digitally signed, for example a MANIFEST document that has been bundled with the content. Wouldn't such an audit trail be sufficient to establish the level of trust we're aiming for here?

Does anyone have experience with the use of digital signatures in content of the kind we're working with? Am I right in thinking that using them all over the place isn't necessarily the best way to go?

Eric Walker

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Schmidt, Charles M. [[hidden email]]
Sent: Friday, October 16, 2009 9:52 AM
To: Multiple recipients of list
Subject: RE: comments on the usefulness of versioning and an additional consideration

Idea #2 - scrap the use of versions and instead use digital signatures applied to files. This will do the best job of ensuring that authoritative content isn't replaced. On the other hand, it means that, if an organization wished to tailor a benchmark (either signed or unsigned) and then control further evolution, they would need to apply their own digital signatures to everything every time they update content.

Thoughts?

Charles

---------------------------------------------------------------

To unsubscribe from this mailing list, please send an e-mail to
[hidden email] with the words "unsubscribe xccdf-dev" in the
body. You will need to send this from the email account that you
used to initially subscribe to xccdf-dev.