Quantcast

ALERT: potentially impactful change in XCCDF

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ALERT: potentially impactful change in XCCDF

Charles Schmidt (MITRE)
Administrator
Hello all,

As many of you may be aware, the XCCDF community previously decided to
deprecate the Group "abstract" and "extends" properties, as well as the Rule
"impact-metric" and "role" properties. Rationales for this deprecation and
impacts appear at the bottom of this message.

Unless you have been eagerly reading all the attachments on the XCCDF-dev
list, you may not know that in the recent XCCDF development telecon the
decision was made to actually REMOVE these properties from the XML schema
instead of deprecating them. The justification for this was that, since
there was going to be a mild break in backwards compatibility between XCCDF
1.1.4 and XCCDF 1.2, that this clean-up was justifiable, especially since
all the removed properties had alternative implementations, but primarily
because no one knew of anyone using these fields in content.

It was recognized that suddenly removing fields would be disruptive to
anyone using these fields in their content. As such, the group asked for an
explicit call (this email) to the affected communities to see if anyone
would be harmed by removing rather than simply deprecating these fields.
Please respond if you will be affected by this. (Objections based on
principled objections to summary removal of fields without first deprecating
them will be considered, but greater weight will be given to objections
based on demonstrable impact to content and tools.) If there is an
indication that this latest decision is going to cause hardship, it will be
reversed and the fields will go back to simply being deprecated.

Thank you for your interest. I hope that with your input we can publish a
draft that works best for all users.

Charles
XCCDF Moderator

================ Rationales for deprecation (or removal) of XCCDF properties
========================

- Group "abstract" and "extends" properties are used in Group extensions
where one group can inherit the content of another group. This capability
proved to be problematic since it could result in the generation of new
major XCCDF elements (Groups, Rules, and Values) that were difficult to
tailor and report using existing mechanisms. Equivalent functionality is
achieved by explicitly creating all Groups and their content rather than
allowing Groups to be generated at runtime through extension.
- The Rule "impact-metric" property was used to document additional metadata
about a Rule's impact on a system. Nominally, this would be something like a
CVSS vector. This field was duplicative with other mechanisms, such as a
Rule's "weight" and "severity" properties and was found to be virtually
unused in practice. Any group desiring to store a CVSS vector with a rule
could place it in the Rule's metadata.
- The Rule "role" property allowed a Rule to be checked but unscored,
unchecked, or run as normal. One primary use case was to support debugging
of content. It was found to be duplicative of existing mechanisms (setting
weight to 0, use of an unsupported check system, or normal use,
respectively), and virtually unused.

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: ALERT: potentially impactful change in XCCDF

Richard_Whitehurst

Charles,

We are not currently using the role property, but we believe it can be a way to provide support for enumeration, using the "informational" role value.  The idea is that a script could retrieve a set of information the user is interested in and then displaying the benchmark results would display the contents of the script's output without requiring a pass/fail value to be assigned to it.  We are also considering using the informational role in conjunction with our findings to use OVAL to provide a similar enumeration capability.

In short, we would like to keep the role attribute and preferably not deprecate it.  
Thanks,
Dick

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Schmidt, Charles M.
Sent: Wednesday, July 20, 2011 10:16 AM
To: Multiple recipients of list
Subject: ALERT: potentially impactful change in XCCDF

Hello all,

As many of you may be aware, the XCCDF community previously decided to
deprecate the Group "abstract" and "extends" properties, as well as the Rule
"impact-metric" and "role" properties. Rationales for this deprecation and
impacts appear at the bottom of this message.

Unless you have been eagerly reading all the attachments on the XCCDF-dev
list, you may not know that in the recent XCCDF development telecon the
decision was made to actually REMOVE these properties from the XML schema
instead of deprecating them. The justification for this was that, since
there was going to be a mild break in backwards compatibility between XCCDF
1.1.4 and XCCDF 1.2, that this clean-up was justifiable, especially since
all the removed properties had alternative implementations, but primarily
because no one knew of anyone using these fields in content.

It was recognized that suddenly removing fields would be disruptive to
anyone using these fields in their content. As such, the group asked for an
explicit call (this email) to the affected communities to see if anyone
would be harmed by removing rather than simply deprecating these fields.
Please respond if you will be affected by this. (Objections based on
principled objections to summary removal of fields without first deprecating
them will be considered, but greater weight will be given to objections
based on demonstrable impact to content and tools.) If there is an
indication that this latest decision is going to cause hardship, it will be
reversed and the fields will go back to simply being deprecated.

Thank you for your interest. I hope that with your input we can publish a
draft that works best for all users.

Charles
XCCDF Moderator

================ Rationales for deprecation (or removal) of XCCDF properties
========================

- Group "abstract" and "extends" properties are used in Group extensions
where one group can inherit the content of another group. This capability
proved to be problematic since it could result in the generation of new
major XCCDF elements (Groups, Rules, and Values) that were difficult to
tailor and report using existing mechanisms. Equivalent functionality is
achieved by explicitly creating all Groups and their content rather than
allowing Groups to be generated at runtime through extension.
- The Rule "impact-metric" property was used to document additional metadata
about a Rule's impact on a system. Nominally, this would be something like a
CVSS vector. This field was duplicative with other mechanisms, such as a
Rule's "weight" and "severity" properties and was found to be virtually
unused in practice. Any group desiring to store a CVSS vector with a rule
could place it in the Rule's metadata.
- The Rule "role" property allowed a Rule to be checked but unscored,
unchecked, or run as normal. One primary use case was to support debugging
of content. It was found to be duplicative of existing mechanisms (setting
weight to 0, use of an unsupported check system, or normal use,
respectively), and virtually unused.


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

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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: ALERT: potentially impactful change in XCCDF

Charles Schmidt (MITRE)
Administrator
I just want to make a quick follow up to Dick's email:

In the "alternative implementation" to the role property that I describe at
the bottom of my original email, I describe a procedure that would allow a
Rule's check to be executed (so the results could be included in the
benchmark results) without affecting the benchmark score. HOWEVER, that Rule
would still display with a PASS, FAIL, or other result rather than the
INFORMATIONAL result, which would be the result value if a Rule role
property was set to "unscored". As such, I want to emphasize that, while the
alternative implementation of role outlined in this email is close, it is
not a 100% match for the behavior of the XCCDF 1.1.4 role property which
Dick is noting might be of future interest.

The bottom line is that, for Dick's use case, deprecation or removal of
"role" would, in fact, be a step backwards rather than a sidestep to
alternative implementations.

Are there any other parties also interested in the functionality Dick
describes?

Charles

>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]] On Behalf Of
>[hidden email]
>Sent: Wednesday, July 20, 2011 2:35 PM
>To: Multiple recipients of list
>Subject: RE: ALERT: potentially impactful change in XCCDF
>
>
>Charles,
>
>We are not currently using the role property, but we believe it can be a
way

>to provide support for enumeration, using the "informational" role value.
>The idea is that a script could retrieve a set of information the user is
>interested in and then displaying the benchmark results would display the
>contents of the script's output without requiring a pass/fail value to be
>assigned to it.  We are also considering using the informational role in
>conjunction with our findings to use OVAL to provide a similar enumeration
>capability.
>
>In short, we would like to keep the role attribute and preferably not
>deprecate it.
>Thanks,
>Dick
>
>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]] On Behalf Of
>Schmidt, Charles M.
>Sent: Wednesday, July 20, 2011 10:16 AM
>To: Multiple recipients of list
>Subject: ALERT: potentially impactful change in XCCDF
>
>Hello all,
>
>As many of you may be aware, the XCCDF community previously decided to
>deprecate the Group "abstract" and "extends" properties, as well as the
Rule

>"impact-metric" and "role" properties. Rationales for this deprecation and
>impacts appear at the bottom of this message.
>
>Unless you have been eagerly reading all the attachments on the XCCDF-dev
>list, you may not know that in the recent XCCDF development telecon the
>decision was made to actually REMOVE these properties from the XML
>schema
>instead of deprecating them. The justification for this was that, since
>there was going to be a mild break in backwards compatibility between
>XCCDF
>1.1.4 and XCCDF 1.2, that this clean-up was justifiable, especially since
>all the removed properties had alternative implementations, but primarily
>because no one knew of anyone using these fields in content.
>
>It was recognized that suddenly removing fields would be disruptive to
>anyone using these fields in their content. As such, the group asked for an
>explicit call (this email) to the affected communities to see if anyone
>would be harmed by removing rather than simply deprecating these fields.
>Please respond if you will be affected by this. (Objections based on
>principled objections to summary removal of fields without first
deprecating

>them will be considered, but greater weight will be given to objections
>based on demonstrable impact to content and tools.) If there is an
>indication that this latest decision is going to cause hardship, it will be
>reversed and the fields will go back to simply being deprecated.
>
>Thank you for your interest. I hope that with your input we can publish a
>draft that works best for all users.
>
>Charles
>XCCDF Moderator
>
>================ Rationales for deprecation (or removal) of XCCDF
>properties
>========================
>
>- Group "abstract" and "extends" properties are used in Group extensions
>where one group can inherit the content of another group. This capability
>proved to be problematic since it could result in the generation of new
>major XCCDF elements (Groups, Rules, and Values) that were difficult to
>tailor and report using existing mechanisms. Equivalent functionality is
>achieved by explicitly creating all Groups and their content rather than
>allowing Groups to be generated at runtime through extension.
>- The Rule "impact-metric" property was used to document additional
>metadata
>about a Rule's impact on a system. Nominally, this would be something like
a

>CVSS vector. This field was duplicative with other mechanisms, such as a
>Rule's "weight" and "severity" properties and was found to be virtually
>unused in practice. Any group desiring to store a CVSS vector with a rule
>could place it in the Rule's metadata.
>- The Rule "role" property allowed a Rule to be checked but unscored,
>unchecked, or run as normal. One primary use case was to support debugging
>of content. It was found to be duplicative of existing mechanisms (setting
>weight to 0, use of an unsupported check system, or normal use,
>respectively), and virtually unused.
>
>
>---------------------------------------------------------------
>
>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.


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: ALERT: potentially impactful change in XCCDF

Harrison, Tim

Charles,

I see benefit in the functionality Dick described.

As far as the removal of "extends" from Groups I think we'd be putting the cart before the horse.  While it does not break anything I am doing today I am still not in favor of this until we have an appropriate replacement.  Doing so prevents the logical grouping of Rules for similar settings if the expectation is to extend these rules.  When writing SCAP 1.2 content intended to be extended it would require that authors specify the "platform" for each Rule even if it would be preferable to group these Rules together and simply specify the platform for the Group. Removal of "extends" may impact creation, evaluation, maintenance, and size of content written to allow the extending of Rules.

Thanks,
Tim Harrison
(717)561-2923
[hidden email]
________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Schmidt, Charles M. [[hidden email]]
Sent: Thursday, July 21, 2011 10:48 AM
To: XCCDF-DEV
Subject: RE: ALERT: potentially impactful change in XCCDF

I just want to make a quick follow up to Dick's email:

In the "alternative implementation" to the role property that I describe at
the bottom of my original email, I describe a procedure that would allow a
Rule's check to be executed (so the results could be included in the
benchmark results) without affecting the benchmark score. HOWEVER, that Rule
would still display with a PASS, FAIL, or other result rather than the
INFORMATIONAL result, which would be the result value if a Rule role
property was set to "unscored". As such, I want to emphasize that, while the
alternative implementation of role outlined in this email is close, it is
not a 100% match for the behavior of the XCCDF 1.1.4 role property which
Dick is noting might be of future interest.

The bottom line is that, for Dick's use case, deprecation or removal of
"role" would, in fact, be a step backwards rather than a sidestep to
alternative implementations.

Are there any other parties also interested in the functionality Dick
describes?

Charles

>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]] On Behalf Of
>[hidden email]
>Sent: Wednesday, July 20, 2011 2:35 PM
>To: Multiple recipients of list
>Subject: RE: ALERT: potentially impactful change in XCCDF
>
>
>Charles,
>
>We are not currently using the role property, but we believe it can be a
way

>to provide support for enumeration, using the "informational" role value.
>The idea is that a script could retrieve a set of information the user is
>interested in and then displaying the benchmark results would display the
>contents of the script's output without requiring a pass/fail value to be
>assigned to it.  We are also considering using the informational role in
>conjunction with our findings to use OVAL to provide a similar enumeration
>capability.
>
>In short, we would like to keep the role attribute and preferably not
>deprecate it.
>Thanks,
>Dick
>
>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]] On Behalf Of
>Schmidt, Charles M.
>Sent: Wednesday, July 20, 2011 10:16 AM
>To: Multiple recipients of list
>Subject: ALERT: potentially impactful change in XCCDF
>
>Hello all,
>
>As many of you may be aware, the XCCDF community previously decided to
>deprecate the Group "abstract" and "extends" properties, as well as the
Rule

>"impact-metric" and "role" properties. Rationales for this deprecation and
>impacts appear at the bottom of this message.
>
>Unless you have been eagerly reading all the attachments on the XCCDF-dev
>list, you may not know that in the recent XCCDF development telecon the
>decision was made to actually REMOVE these properties from the XML
>schema
>instead of deprecating them. The justification for this was that, since
>there was going to be a mild break in backwards compatibility between
>XCCDF
>1.1.4 and XCCDF 1.2, that this clean-up was justifiable, especially since
>all the removed properties had alternative implementations, but primarily
>because no one knew of anyone using these fields in content.
>
>It was recognized that suddenly removing fields would be disruptive to
>anyone using these fields in their content. As such, the group asked for an
>explicit call (this email) to the affected communities to see if anyone
>would be harmed by removing rather than simply deprecating these fields.
>Please respond if you will be affected by this. (Objections based on
>principled objections to summary removal of fields without first
deprecating

>them will be considered, but greater weight will be given to objections
>based on demonstrable impact to content and tools.) If there is an
>indication that this latest decision is going to cause hardship, it will be
>reversed and the fields will go back to simply being deprecated.
>
>Thank you for your interest. I hope that with your input we can publish a
>draft that works best for all users.
>
>Charles
>XCCDF Moderator
>
>================ Rationales for deprecation (or removal) of XCCDF
>properties
>========================
>
>- Group "abstract" and "extends" properties are used in Group extensions
>where one group can inherit the content of another group. This capability
>proved to be problematic since it could result in the generation of new
>major XCCDF elements (Groups, Rules, and Values) that were difficult to
>tailor and report using existing mechanisms. Equivalent functionality is
>achieved by explicitly creating all Groups and their content rather than
>allowing Groups to be generated at runtime through extension.
>- The Rule "impact-metric" property was used to document additional
>metadata
>about a Rule's impact on a system. Nominally, this would be something like
a

>CVSS vector. This field was duplicative with other mechanisms, such as a
>Rule's "weight" and "severity" properties and was found to be virtually
>unused in practice. Any group desiring to store a CVSS vector with a rule
>could place it in the Rule's metadata.
>- The Rule "role" property allowed a Rule to be checked but unscored,
>unchecked, or run as normal. One primary use case was to support debugging
>of content. It was found to be duplicative of existing mechanisms (setting
>weight to 0, use of an unsupported check system, or normal use,
>respectively), and virtually unused.
>
>
>---------------------------------------------------------------
>
>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.


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

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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: ALERT: potentially impactful change in XCCDF

Charles Schmidt (MITRE)
Administrator
In reply to this post by Charles Schmidt (MITRE)
Hello all,

There have been a number of concerns raised about the summary removal of the
fields described in the previous email. As a result, in accordance with the
plan set out in the July 13 community telecon, that decision is being
reversed in all cases (including the impact-metric property, which no one
defended). The listed fields will still be deprecated, as per the earlier
community consensus decisions, but they will remain in the schema and
specification. To those who made arguments against deprecation - I am adding
issues to the XCCDF issue tracker to discuss de-deprecating (or would that
just be "precating") those properties in the next series of revisions.

Thanks to everyone who responded to this thread.

Charles

>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]] On Behalf Of
>Schmidt, Charles M.
>Sent: Wednesday, July 20, 2011 10:16 AM
>To: Multiple recipients of list
>Subject: ALERT: potentially impactful change in XCCDF
>
>Hello all,
>
>As many of you may be aware, the XCCDF community previously decided to
>deprecate the Group "abstract" and "extends" properties, as well as the
Rule

>"impact-metric" and "role" properties. Rationales for this deprecation and
>impacts appear at the bottom of this message.
>
>Unless you have been eagerly reading all the attachments on the XCCDF-dev
>list, you may not know that in the recent XCCDF development telecon the
>decision was made to actually REMOVE these properties from the XML
>schema
>instead of deprecating them. The justification for this was that, since
>there was going to be a mild break in backwards compatibility between
>XCCDF
>1.1.4 and XCCDF 1.2, that this clean-up was justifiable, especially since
>all the removed properties had alternative implementations, but primarily
>because no one knew of anyone using these fields in content.
>
>It was recognized that suddenly removing fields would be disruptive to
>anyone using these fields in their content. As such, the group asked for an
>explicit call (this email) to the affected communities to see if anyone
>would be harmed by removing rather than simply deprecating these fields.
>Please respond if you will be affected by this. (Objections based on
>principled objections to summary removal of fields without first
deprecating

>them will be considered, but greater weight will be given to objections
>based on demonstrable impact to content and tools.) If there is an
>indication that this latest decision is going to cause hardship, it will be
>reversed and the fields will go back to simply being deprecated.
>
>Thank you for your interest. I hope that with your input we can publish a
>draft that works best for all users.
>
>Charles
>XCCDF Moderator
>
>================ Rationales for deprecation (or removal) of XCCDF
>properties
>========================
>
>- Group "abstract" and "extends" properties are used in Group extensions
>where one group can inherit the content of another group. This capability
>proved to be problematic since it could result in the generation of new
>major XCCDF elements (Groups, Rules, and Values) that were difficult to
>tailor and report using existing mechanisms. Equivalent functionality is
>achieved by explicitly creating all Groups and their content rather than
>allowing Groups to be generated at runtime through extension.
>- The Rule "impact-metric" property was used to document additional
>metadata
>about a Rule's impact on a system. Nominally, this would be something like
a
>CVSS vector. This field was duplicative with other mechanisms, such as a
>Rule's "weight" and "severity" properties and was found to be virtually
>unused in practice. Any group desiring to store a CVSS vector with a rule
>could place it in the Rule's metadata.
>- The Rule "role" property allowed a Rule to be checked but unscored,
>unchecked, or run as normal. One primary use case was to support debugging
>of content. It was found to be duplicative of existing mechanisms (setting
>weight to 0, use of an unsupported check system, or normal use,
>respectively), and virtually unused.

smime.p7s (4K) Download Attachment
Loading...