[RFE] [RFC] Define way / policy for the expected form of XCCDF rules' names (possible to use interrogative form instead of current's imperative one?)
Hello folks,
as can be seen for example in the scap-workbench demo pictures: [1] https://fedorahosted.org/scap-workbench/attachment/wiki/WikiStart/browsing_r... [2] https://fedorahosted.org/scap-workbench/attachment/wiki/WikiStart/intro_scre...
the current way how XCCDF rules' names are created is in imperative form (e.g. "Set / Ensure / Verify ...") instead of the interrogative one (e.g. "Substantive [Subject of the check] meets feature / criteria").
While this approach is natural for HTML version of the guide, the XCCDF rule names are used also in tools performing the scan / remediation (e.g. scap-workbench: [3] https://fedorahosted.org/scap-workbench/)
And this is where the source of confusion appears / might appear -- consider the following selected cases (there are far more of them than just these though):
Rule Name | Scan Result ---------------------------------------------------------- Set Password Minimum Length in login.defs | fail ---------------------------------------------------------- Set Password Minimum Age | fail ---------------------------------------------------------- Set Password Maximum Age | fail
What the scan is actually doing being comparing if applied system's policy for the expected form of passwords: * doesn't allow passwords shorter than expected minimum length, * if there are minimum / maximum periods how long password (at least / at max) should be considered as valid defined.
But based on the above presented form scap-workbench / scap-security-guide user, unfamiliar with the internals, might obtain an opinion / impressions when seeing the 'fail' result, that the tool actually tried: * to set the minimum length for passwords on the system, * to set minimum and maximum period during that passwords should be considered valid,
and this act failed (IOW the current form migth induce a perception that instead of OVAL check failure [the true reason], the remediation failed [red herring / false positive]).
To avoid this source of confusion we propose to change the way how XCCDF rules are named (use interrogative form instead of imperative one).
To mention examples for above three cases: * 'Set Password Minimum Length in login.defs' would become for example: 'User Passwords In login.defs Meet The Minimum Length Requirement / User Passwords Meet The Minimum Length Requirement / Only Passwords Longer Than Defined Minimum Allowed'
* 'Set Password Minimum Age' could become: 'Minimum Period Between Password Changes Defined'
* 'Set Password Maximum Age' could be: 'Maximum Number of Days a Password Might Be Used Set'
Using this form (we think) the failing scan result wouldn't conduct to impressions, the remediation being what failed.
If we could agree on this proposal, I could come with patch how Fedora rules (or even RHEL6?) names should be changed not to (possibly) lead to this confusion.
Comments / feedback appreciated.
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
P.S.: Prior actually requesting / proposing this change we have been considering if scap-workbench tool couldn't instead of XCCDF rule names display underlying OVAL check titles (and have these titles customized). But this approach has been realized as not possible to perform because: * there might be more than just one OVAL checks for one XCCDF rule (in that case which one to display?), * during parsing the particular XCCDF scap-workbench (some other tools too?) is operating on rule IDs instead of rule names so it would be difficult (if even possible) to modify the code to get it to display OVAL titles instead of XCCDF rule names.
P.S.#2: Another possibility which comes to my mind is instead to have XCCDF rules shared in both, the HTML version of the guide and in the validation tool screen, we could dedicate XCCDF rule names to be displayed just in the validation tools, and generate rule names for HTML version of the guide some other way (like keeping it in some other / yet different XCCDF element and when generating HTML guide use content of that element instead of XCCDF rule name).
On 12/4/13, 11:02 AM, Jan Lieskovsky wrote:
Hello folks,
as can be seen for example in the scap-workbench demo pictures: [1] https://fedorahosted.org/scap-workbench/attachment/wiki/WikiStart/browsing_r... [2] https://fedorahosted.org/scap-workbench/attachment/wiki/WikiStart/intro_scre...
the current way how XCCDF rules' names are created is in imperative form (e.g. "Set / Ensure / Verify ...") instead of the interrogative one (e.g. "Substantive [Subject of the check] meets feature / criteria").
While this approach is natural for HTML version of the guide, the XCCDF rule names are used also in tools performing the scan / remediation (e.g. scap-workbench: [3] https://fedorahosted.org/scap-workbench/)
And this is where the source of confusion appears / might appear -- consider the following selected cases (there are far more of them than just these though):
Rule Name | Scan Result
Set Password Minimum Length in login.defs | fail
Set Password Minimum Age | fail
Set Password Maximum Age | fail
What the scan is actually doing being comparing if applied system's policy for the expected form of passwords:
- doesn't allow passwords shorter than expected minimum length,
- if there are minimum / maximum periods how long password (at least / at max) should be considered as valid defined.
But based on the above presented form scap-workbench / scap-security-guide user, unfamiliar with the internals, might obtain an opinion / impressions when seeing the 'fail' result, that the tool actually tried:
- to set the minimum length for passwords on the system,
- to set minimum and maximum period during that passwords should be considered valid,
and this act failed (IOW the current form migth induce a perception that instead of OVAL check failure [the true reason], the remediation failed [red herring / false positive]).
From the SSG workshops given through N.A., attendees have yet to confuse scanning results with remediation state. Historically this hasn't been a concern.
With that said, remediation capabilities are rapidly maturing. With online remediation becoming available, such as reflected in Šimon Lukašík's blog [1], I could see how users would be confused if the /scan/ failed, or if the /remediation/ did.
If online remediation is attempted, and fails, the end state of the machine is still non-compliance. Perhaps an approach would be to extend SCAP Workbench (and OpenSCAP?) reporting functionality to indicate not only compliance state, but also if remediation was attempted?
To avoid this source of confusion we propose to change the way how XCCDF rules are named (use interrogative form instead of imperative one).
To mention examples for above three cases:
'Set Password Minimum Length in login.defs' would become for example: 'User Passwords In login.defs Meet The Minimum Length Requirement / User Passwords Meet The Minimum Length Requirement / Only Passwords Longer Than Defined Minimum Allowed'
'Set Password Minimum Age' could become: 'Minimum Period Between Password Changes Defined'
'Set Password Maximum Age' could be: 'Maximum Number of Days a Password Might Be Used Set'
Using this form (we think) the failing scan result wouldn't conduct to impressions, the remediation being what failed.
If we could agree on this proposal, I could come with patch how Fedora rules (or even RHEL6?) names should be changed not to (possibly) lead to this confusion.
There's been discussion on this in the past. Classically the use of SSG has enabled (mostly government) users to demonstrate compliance against /requirements/. These requirements are imperative, and thus many XCCDF titles were mostly written in this form.
A few derived profiles, such as the U.S. DoD STIG, mandate even stronger language ("The System shall...", "The system must...."). The ability to extend/rename XCCDF titles was accounted for during the U.S. DoD STIG process, and reflected in the STIG Overlay (note the <title> tags): https://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6/input/a...
If we migrate XCCDF titles to an interrogative form, we'd need to create XCCDF title overlays for not only the STIG, but also USGCB, NIST, FISMA, and almost every profile currently existing. Each overlay is some 1,500 lines long..... which would mean an administrative burden of at least another 6,000 lines of code. I'm not sure the effort + burden would be worth it.
To clarify OVAL result vs remediation result, perhaps the tools could be expanded?
Comments / feedback appreciated.
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
P.S.: Prior actually requesting / proposing this change we have been considering if scap-workbench tool couldn't instead of XCCDF rule names display underlying OVAL check titles (and have these titles customized). But this approach has been realized as not possible to perform because: * there might be more than just one OVAL checks for one XCCDF rule (in that case which one to display?),
Having multiple OVAL mapped to a single XCCDF rule would be... challenging. Every XCCDF rule should reflect a unique configuration change, preferably to the level of having a CCE assigned.
As an idea, perhaps we should renaming the XCCDF groups to be interrogative, with the individual XCCDF rules being imperative?
* during parsing the particular XCCDF scap-workbench (some other tools too?) is operating on rule IDs instead of rule names so it would be difficult (if even possible) to modify the code to get it to display OVAL titles instead of XCCDF rule names.
Side note, which may warrant it's own thread: Should we use XSLT to insert the XCCDF title automatically into the associated OVAL check? This could greatly reduce the maintenance burden if/when any renaming occurs.
P.S.#2: Another possibility which comes to my mind is instead to have XCCDF rules shared in both, the HTML version of the guide and in the validation tool screen, we could dedicate XCCDF rule names to be displayed just in the validation tools, and generate rule names for HTML version of the guide some other way (like keeping it in some other / yet different XCCDF element and when generating HTML guide use content of that element instead of XCCDF rule name).
The maintenance burden of this would be high.
Thanks for starting this thread Jan! It's a very worthwhile conversation.
Thank you for the feedback, Shawn. (Cc-ing Peter and Martin for their opinion yet [as I can say what concrete change could mean for SCAP content, but not what it could mean for the tool]).
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Thursday, December 5, 2013 8:10:32 AM Subject: Re: [RFE] [RFC] Define way / policy for the expected form of XCCDF rules' names (possible to use interrogative form instead of current's imperative one?)
On 12/4/13, 11:02 AM, Jan Lieskovsky wrote:
% % % % Hello folks, % % as can be seen for example in the scap-workbench demo pictures: % [1] https://fedorahosted.org/scap-workbench/attachment/wiki/WikiStart/browsing_r... % [2] https://fedorahosted.org/scap-workbench/attachment/wiki/WikiStart/intro_scre... % the current way how XCCDF rules' names are created is in imperative % form (e.g. "Set / Ensure / Verify ...") instead of the interrogative % one (e.g. "Substantive [Subject of the check] meets feature / criteria"). % % While this approach is natural for HTML version of the guide, the XCCDF % rule names are used also in tools performing the scan / remediation % (e.g. scap-workbench: % [3] https://fedorahosted.org/scap-workbench/ ) % % And this is where the source of confusion appears / might appear -- % consider the following selected cases (there are far more of them % than just these though): % % Rule Name | Scan Result % ---------------------------------------------------------- % Set Password Minimum Length in login.defs | fail % ---------------------------------------------------------- % Set Password Minimum Age | fail % ---------------------------------------------------------- % Set Password Maximum Age | fail % % What the scan is actually doing being comparing if applied system's % policy for the expected form of passwords: % * doesn't allow passwords shorter than expected minimum length, % * if there are minimum / maximum periods how long password % (at least / at max) should be considered as valid defined. % % But based on the above presented form scap-workbench / % scap-security-guide user, unfamiliar with the internals, % might obtain an opinion / impressions when seeing the 'fail' % result, that the tool actually tried: % * to set the minimum length for passwords on the system, % * to set minimum and maximum period during that passwords % should be considered valid, % % and this act failed (IOW the current form migth induce a perception % that instead of OVAL check failure [the true reason], the % remediation failed [red herring / false positive]).
From the SSG workshops given through N.A., attendees have yet to confuse scanning results with remediation state. Historically this hasn't been a concern.
With that said, remediation capabilities are rapidly maturing. With online remediation becoming available, such as reflected in Šimon Lukašík's blog [1], I could see how users would be confused if the scan failed, or if the remediation did.
Yet another way how to look at the existing rule state being the presence of "Set" might induce impression that remediation was attempted, when it actually wasn't (like "Set the feature" the user might think just during the scan the tool tried to "Set the feature", but it failed). Anyway, see below.
If online remediation is attempted, and fails, the end state of the machine is still non-compliance. Perhaps an approach would be to extend SCAP Workbench (and OpenSCAP?) reporting functionality to indicate not only compliance state, but also if remediation was attempted?
Have filed two RFEs to indicate what's actually performed: [2] https://fedorahosted.org/scap-workbench/ticket/141 (display information about actually processed rule in the statusbar, and also information if it's scan or remediation), [3] https://fedorahosted.org/scap-workbench/ticket/142 (do the same but not in the statusbar, but by changing background color of actually processed rule [scan having one color, remediation another one])
Any other opinion how to distinguish these two yet / indicate which of the two was attempted at the moment?
% % To avoid this source of confusion we propose to change the way % how XCCDF rules are named (use interrogative form instead of % imperative one). % % To mention examples for above three cases: % * 'Set Password Minimum Length in login.defs' would become for % example: % 'User Passwords In login.defs Meet The Minimum Length Requirement / % User Passwords Meet The Minimum Length Requirement / % Only Passwords Longer Than Defined Minimum Allowed' % % * 'Set Password Minimum Age' could become: % 'Minimum Period Between Password Changes Defined' % % * 'Set Password Maximum Age' could be: % 'Maximum Number of Days a Password Might Be Used Set' % % Using this form (we think) the failing scan result wouldn't % conduct to impressions, the remediation being what failed. % % If we could agree on this proposal, I could come with patch % how Fedora rules (or even RHEL6?) names should be changed % not to (possibly) lead to this confusion.
There's been discussion on this in the past. Classically the use of SSG has enabled (mostly government) users to demonstrate compliance against requirements . These requirements are imperative, and thus many XCCDF titles were mostly written in this form.
A few derived profiles, such as the U.S. DoD STIG, mandate even stronger language ("The System shall...", "The system must...."). The ability to extend/rename XCCDF titles was accounted for during the U.S. DoD STIG process, and reflected in the STIG Overlay (note the <title> tags): https://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6/input/a...
If we migrate XCCDF titles to an interrogative form, we'd need to create XCCDF title overlays for not only the STIG, but also USGCB, NIST, FISMA, and almost every profile currently existing. Each overlay is some 1,500 lines long..... which would mean an administrative burden of at least another 6,000 lines of code. I'm not sure the effort + burden would be worth it.
Yeah, truly (now when written down) this looks to be not the ideal way to go. Can understand the guide needs to have the rules in imperative form (the standards' requirements). But your mention about overlays provided another idea to me - what to use overlay to modify the rule names post the HTML guide has been generated?
Like when making RPM, we would first generate HTML guide with imperative form in rule names, then when making the content (final XCCDF mainly) we would apply some overlay - I think it would be enough if it would move the first verb from the beginning to the end. Like:
* 'Set Password Minimum Length' => 'Password Minimum Length Set' * 'Set Password Maximum Age' => 'Password Maximum Age Set' ...
From what have looked at overlay definition, this seems to be doable.
The only question now remaining being if rules named different way couldn't introduce additional confusion (the overlay would need not to change them "too much", like just by moving the imperative at the end for example).
Would this be acceptable? Or not a way to go?
To clarify OVAL result vs remediation result, perhaps the tools could be expanded?
For now filed two RFEs (shall I find out more how it could be expanded yet, will file them).
% % % % % % Comments / feedback appreciated. % % Thank you && Regards, Jan. % -- % Jan iankko Lieskovsky / Red Hat Security Technologies Team % % P.S.: Prior actually requesting / proposing this change we % have been considering if scap-workbench tool couldn't % instead of XCCDF rule names display underlying OVAL % check titles (and have these titles customized). But % this approach has been realized as not possible to perform % because: % * there might be more than just one OVAL checks for one % XCCDF rule (in that case which one to display?),
Having multiple OVAL mapped to a single XCCDF rule would be... challenging. Every XCCDF rule should reflect a unique configuration change, preferably to the level of having a CCE assigned.
As an idea, perhaps we should renaming the XCCDF groups to be interrogative, with the individual XCCDF rules being imperative?
Right now scap-workbench doesn't support / display XCCDF group names (just rules' names). Yeah, displaying groups (via clicking on expanding tree fields) might be more appropriate for better organization of the whole benchmark, but I am not sure changing (just) the way XCCDF group names are created would solve our problem.
% % * during parsing the particular XCCDF scap-workbench % (some other tools too?) is operating on rule IDs instead % of rule names so it would be difficult (if even % possible) to modify the code to get it to display
OVAL titles instead of XCCDF rule names.Side note, which may warrant it's own thread: Should we use XSLT to insert the XCCDF title automatically into the associated OVAL check? This could greatly reduce the maintenance burden if/when any renaming occurs.
Not sure. Martin, would this simplify the scap-workbench's parsing somehow?
% P.S.#2: Another possibility which comes to my mind is instead % to have XCCDF rules shared in both, the HTML version of the % guide and in the validation tool screen, we could dedicate % XCCDF rule names to be displayed just in the validation tools, % and generate rule names for HTML version of the guide some % other way (like keeping it in some other / yet different % XCCDF element and when generating HTML guide use content of % that element instead of XCCDF rule name).
The maintenance burden of this would be high.
Yeah, now you described the way how STIG document is overlay-ed, I can see the complexity. What about the vice versa approach (keep HTML rules names intact, but post generating the guide use overlays to [slightly] change rules' names in final XCCDF) above?
Thanks for starting this thread Jan! It's a very worthwhile conversation.
No problem. Just trying common user (not aware of all underlying details) when using the tools not to get confused (or if they should ever get confused, we to notice / fix it yet sooner :)).
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
[1] http://isimluk.livejournal.com/3573.html
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Is there a reason the declarative form for Rule names could not be used? Per Shawn's comment, are they considered too strong?
Thanks, Leland -- Leland Steinke, Security+ DISA FSO Technical Support Contractor tapestry technologies, Inc 717-267-5797 (DSN 570) leland.j.steinke.ctr@mail.mil (gov't) lsteinke@tapestrytech.com (com'l)
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap- security-guide-bounces@lists.fedorahosted.org] On Behalf Of Jan Lieskovsky Sent: Thursday, December 05, 2013 8:54 AM To: scap-security-guide@lists.fedorahosted.org Subject: Re: [RFE] [RFC] Define way / policy for the expected form of XCCDF rules' names (possible to use interrogative form instead of current's imperative one?)
Thank you for the feedback, Shawn. (Cc-ing Peter and Martin for their opinion yet [as I can say what concrete change could mean for SCAP content, but not what it could mean for the tool]).
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Thursday, December 5, 2013 8:10:32 AM Subject: Re: [RFE] [RFC] Define way / policy for the expected form of
XCCDF rules' names (possible to use
interrogative form instead of current's imperative one?)
On 12/4/13, 11:02 AM, Jan Lieskovsky wrote:
% % % % Hello folks, % % as can be seen for example in the scap-workbench demo pictures: % [1] https://fedorahosted.org/scap- workbench/attachment/wiki/WikiStart/browsing_results.png % [2] https://fedorahosted.org/scap- workbench/attachment/wiki/WikiStart/intro_screenshot.png % the current way how XCCDF rules' names are created is in imperative % form (e.g. "Set / Ensure / Verify ...") instead of the interrogative % one (e.g. "Substantive [Subject of the check] meets feature / criteria"). % % While this approach is natural for HTML version of the guide, the XCCDF % rule names are used also in tools performing the scan / remediation % (e.g. scap-workbench: % [3] https://fedorahosted.org/scap-workbench/ ) % % And this is where the source of confusion appears / might appear -- % consider the following selected cases (there are far more of them % than just these though): % % Rule Name | Scan Result % ---------------------------------------------------------- % Set Password Minimum Length in login.defs | fail % ---------------------------------------------------------- % Set Password Minimum Age | fail % ---------------------------------------------------------- % Set Password Maximum Age | fail % % What the scan is actually doing being comparing if applied system's % policy for the expected form of passwords: % * doesn't allow passwords shorter than expected minimum length, % * if there are minimum / maximum periods how long password % (at least / at max) should be considered as valid defined. % % But based on the above presented form scap-workbench / % scap-security-guide user, unfamiliar with the internals, % might obtain an opinion / impressions when seeing the 'fail' % result, that the tool actually tried: % * to set the minimum length for passwords on the system, % * to set minimum and maximum period during that passwords % should be considered valid, % % and this act failed (IOW the current form migth induce a perception % that instead of OVAL check failure [the true reason], the % remediation failed [red herring / false positive]).
From the SSG workshops given through N.A., attendees have yet to
confuse
scanning results with remediation state. Historically this hasn't
been a
concern.
With that said, remediation capabilities are rapidly maturing. With
online
remediation becoming available, such as reflected in Šimon Lukašík's
blog
[1], I could see how users would be confused if the scan failed, or
if the
remediation did.
Yet another way how to look at the existing rule state being the presence of "Set" might induce impression that remediation was attempted, when it actually wasn't (like "Set the feature" the user might think just during the scan the tool tried to "Set the feature", but it failed). Anyway, see below.
If online remediation is attempted, and fails, the end state of the
machine
is still non-compliance. Perhaps an approach would be to extend SCAP Workbench (and OpenSCAP?) reporting functionality to indicate not
only
compliance state, but also if remediation was attempted?
Have filed two RFEs to indicate what's actually performed: [2] https://fedorahosted.org/scap-workbench/ticket/141 (display information about actually processed rule in the statusbar, and also information if it's scan or remediation), [3] https://fedorahosted.org/scap-workbench/ticket/142 (do the same but not in the statusbar, but by changing background color of actually processed rule [scan having one color, remediation another one])
Any other opinion how to distinguish these two yet / indicate which of the two was attempted at the moment?
% % To avoid this source of confusion we propose to change the way % how XCCDF rules are named (use interrogative form instead of % imperative one). % % To mention examples for above three cases: % * 'Set Password Minimum Length in login.defs' would become for % example: % 'User Passwords In login.defs Meet The Minimum Length Requirement / % User Passwords Meet The Minimum Length Requirement / % Only Passwords Longer Than Defined Minimum Allowed' % % * 'Set Password Minimum Age' could become: % 'Minimum Period Between Password Changes Defined' % % * 'Set Password Maximum Age' could be: % 'Maximum Number of Days a Password Might Be Used Set' % % Using this form (we think) the failing scan result wouldn't % conduct to impressions, the remediation being what failed. % % If we could agree on this proposal, I could come with patch % how Fedora rules (or even RHEL6?) names should be changed % not to (possibly) lead to this confusion.
There's been discussion on this in the past. Classically the use of
SSG has
enabled (mostly government) users to demonstrate compliance against requirements . These requirements are imperative, and thus many XCCDF
titles
were mostly written in this form.
A few derived profiles, such as the U.S. DoD STIG, mandate even
stronger
language ("The System shall...", "The system must...."). The ability
to
extend/rename XCCDF titles was accounted for during the U.S. DoD STIG process, and reflected in the STIG Overlay (note the <title> tags): https://git.fedorahosted.org/cgit/scap-security-
guide.git/tree/RHEL6/input/auxiliary/stig_overlay.xml
If we migrate XCCDF titles to an interrogative form, we'd need to
create
XCCDF title overlays for not only the STIG, but also USGCB, NIST,
FISMA, and
almost every profile currently existing. Each overlay is some 1,500
lines
long..... which would mean an administrative burden of at least
another
6,000 lines of code. I'm not sure the effort + burden would be worth
it.
Yeah, truly (now when written down) this looks to be not the ideal way to go. Can understand the guide needs to have the rules in imperative form (the standards' requirements). But your mention about overlays provided another idea to me - what to use overlay to modify the rule names post the HTML guide has been generated?
Like when making RPM, we would first generate HTML guide with imperative form in rule names, then when making the content (final XCCDF mainly) we would apply some overlay - I think it would be enough if it would move the first verb from the beginning to the end. Like:
- 'Set Password Minimum Length' => 'Password Minimum Length Set'
- 'Set Password Maximum Age' => 'Password Maximum Age Set'
...
From what have looked at overlay definition, this seems to be doable. The only question now remaining being if rules named different way couldn't introduce additional confusion (the overlay would need not to change them "too much", like just by moving the imperative at the end for example).
Would this be acceptable? Or not a way to go?
To clarify OVAL result vs remediation result, perhaps the tools could
be
expanded?
For now filed two RFEs (shall I find out more how it could be expanded yet, will file them).
% % % % % % Comments / feedback appreciated. % % Thank you && Regards, Jan. % -- % Jan iankko Lieskovsky / Red Hat Security Technologies Team % % P.S.: Prior actually requesting / proposing this change we % have been considering if scap-workbench tool couldn't % instead of XCCDF rule names display underlying OVAL % check titles (and have these titles customized). But % this approach has been realized as not possible to perform % because: % * there might be more than just one OVAL checks for one % XCCDF rule (in that case which one to display?),
Having multiple OVAL mapped to a single XCCDF rule would be...
challenging.
Every XCCDF rule should reflect a unique configuration change,
preferably to
the level of having a CCE assigned.
As an idea, perhaps we should renaming the XCCDF groups to be
interrogative,
with the individual XCCDF rules being imperative?
Right now scap-workbench doesn't support / display XCCDF group names (just rules' names). Yeah, displaying groups (via clicking on expanding tree fields) might be more appropriate for better organization of the whole benchmark, but I am not sure changing (just) the way XCCDF group names are created would solve our problem.
% % * during parsing the particular XCCDF scap-workbench % (some other tools too?) is operating on rule IDs instead % of rule names so it would be difficult (if even % possible) to modify the code to get it to display
OVAL titles instead of XCCDF rule names.Side note, which may warrant it's own thread: Should we use XSLT to
insert
the XCCDF title automatically into the associated OVAL check? This
could
greatly reduce the maintenance burden if/when any renaming occurs.
Not sure. Martin, would this simplify the scap-workbench's parsing somehow?
% P.S.#2: Another possibility which comes to my mind is instead % to have XCCDF rules shared in both, the HTML version of the % guide and in the validation tool screen, we could dedicate % XCCDF rule names to be displayed just in the validation tools, % and generate rule names for HTML version of the guide some % other way (like keeping it in some other / yet different % XCCDF element and when generating HTML guide use content of % that element instead of XCCDF rule name).
The maintenance burden of this would be high.
Yeah, now you described the way how STIG document is overlay-ed, I can see the complexity. What about the vice versa approach (keep HTML rules names intact, but post generating the guide use overlays to [slightly] change rules' names in final XCCDF) above?
Thanks for starting this thread Jan! It's a very worthwhile
conversation.
No problem. Just trying common user (not aware of all underlying details) when using the tools not to get confused (or if they should ever get confused, we to notice / fix it yet sooner :)).
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
[1] http://isimluk.livejournal.com/3573.html
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Hello Leland,
----- Original Message -----
From: "Leland J Sr CTR DISA FSO Steinke (US)" leland.j.steinke.ctr@mail.mil To: scap-security-guide@lists.fedorahosted.org Sent: Thursday, December 5, 2013 5:36:59 PM Subject: RE: [RFE] [RFC] Define way / policy for the expected form of XCCDF rules' names (possible to use interrogative form instead of current's imperative one?)
Is there a reason the declarative form for Rule names could not be used? Per Shawn's comment, are they considered too strong?
There's nothing wrong with the declarative form for the Rule names, when it's used in form of a guide document (it's actually expected there).
But besides in the guide (HTML form) they might / are be used by scanning tools to identify rule names during scan too - have a look at images in: https://fedorahosted.org/scap-workbench/
In this context rule name in the form of 'Set Minimum Password Length' might induce the impression in the user that the scanning tool is actually always attempting to set something, which is not the case, when performing the scan.
So rule name in form 'Set something' and having result fail might lead to confusion the OS feature / property was attempted to be properly set / configured and that attempt failed (which is not the case) instead of that the property was just scanned for match / compliance with the expected state and didn't meet the requirement (true result).
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
Thanks, Leland -- Leland Steinke, Security+ DISA FSO Technical Support Contractor tapestry technologies, Inc 717-267-5797 (DSN 570) leland.j.steinke.ctr@mail.mil (gov't) lsteinke@tapestrytech.com (com'l)
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap- security-guide-bounces@lists.fedorahosted.org] On Behalf Of Jan Lieskovsky Sent: Thursday, December 05, 2013 8:54 AM To: scap-security-guide@lists.fedorahosted.org Subject: Re: [RFE] [RFC] Define way / policy for the expected form of XCCDF rules' names (possible to use interrogative form instead of current's imperative one?)
Thank you for the feedback, Shawn. (Cc-ing Peter and Martin for their opinion yet [as I can say what concrete change could mean for SCAP content, but not what it could mean for the tool]).
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Thursday, December 5, 2013 8:10:32 AM Subject: Re: [RFE] [RFC] Define way / policy for the expected form of
XCCDF rules' names (possible to use
interrogative form instead of current's imperative one?)
On 12/4/13, 11:02 AM, Jan Lieskovsky wrote:
% % % % Hello folks, % % as can be seen for example in the scap-workbench demo pictures: % [1] https://fedorahosted.org/scap- workbench/attachment/wiki/WikiStart/browsing_results.png % [2] https://fedorahosted.org/scap- workbench/attachment/wiki/WikiStart/intro_screenshot.png % the current way how XCCDF rules' names are created is in imperative % form (e.g. "Set / Ensure / Verify ...") instead of the interrogative % one (e.g. "Substantive [Subject of the check] meets feature / criteria"). % % While this approach is natural for HTML version of the guide, the XCCDF % rule names are used also in tools performing the scan / remediation % (e.g. scap-workbench: % [3] https://fedorahosted.org/scap-workbench/ ) % % And this is where the source of confusion appears / might appear -- % consider the following selected cases (there are far more of them % than just these though): % % Rule Name | Scan Result % ---------------------------------------------------------- % Set Password Minimum Length in login.defs | fail % ---------------------------------------------------------- % Set Password Minimum Age | fail % ---------------------------------------------------------- % Set Password Maximum Age | fail % % What the scan is actually doing being comparing if applied system's % policy for the expected form of passwords: % * doesn't allow passwords shorter than expected minimum length, % * if there are minimum / maximum periods how long password % (at least / at max) should be considered as valid defined. % % But based on the above presented form scap-workbench / % scap-security-guide user, unfamiliar with the internals, % might obtain an opinion / impressions when seeing the 'fail' % result, that the tool actually tried: % * to set the minimum length for passwords on the system, % * to set minimum and maximum period during that passwords % should be considered valid, % % and this act failed (IOW the current form migth induce a perception % that instead of OVAL check failure [the true reason], the % remediation failed [red herring / false positive]).
From the SSG workshops given through N.A., attendees have yet to
confuse
scanning results with remediation state. Historically this hasn't
been a
concern.
With that said, remediation capabilities are rapidly maturing. With
online
remediation becoming available, such as reflected in Šimon Lukašík's
blog
[1], I could see how users would be confused if the scan failed, or
if the
remediation did.
Yet another way how to look at the existing rule state being the presence of "Set" might induce impression that remediation was attempted, when it actually wasn't (like "Set the feature" the user might think just during the scan the tool tried to "Set the feature", but it failed). Anyway, see below.
If online remediation is attempted, and fails, the end state of the
machine
is still non-compliance. Perhaps an approach would be to extend SCAP Workbench (and OpenSCAP?) reporting functionality to indicate not
only
compliance state, but also if remediation was attempted?
Have filed two RFEs to indicate what's actually performed: [2] https://fedorahosted.org/scap-workbench/ticket/141 (display information about actually processed rule in the statusbar, and also information if it's scan or remediation), [3] https://fedorahosted.org/scap-workbench/ticket/142 (do the same but not in the statusbar, but by changing background color of actually processed rule [scan having one color, remediation another one])
Any other opinion how to distinguish these two yet / indicate which of the two was attempted at the moment?
% % To avoid this source of confusion we propose to change the way % how XCCDF rules are named (use interrogative form instead of % imperative one). % % To mention examples for above three cases: % * 'Set Password Minimum Length in login.defs' would become for % example: % 'User Passwords In login.defs Meet The Minimum Length Requirement / % User Passwords Meet The Minimum Length Requirement / % Only Passwords Longer Than Defined Minimum Allowed' % % * 'Set Password Minimum Age' could become: % 'Minimum Period Between Password Changes Defined' % % * 'Set Password Maximum Age' could be: % 'Maximum Number of Days a Password Might Be Used Set' % % Using this form (we think) the failing scan result wouldn't % conduct to impressions, the remediation being what failed. % % If we could agree on this proposal, I could come with patch % how Fedora rules (or even RHEL6?) names should be changed % not to (possibly) lead to this confusion.
There's been discussion on this in the past. Classically the use of
SSG has
enabled (mostly government) users to demonstrate compliance against requirements . These requirements are imperative, and thus many XCCDF
titles
were mostly written in this form.
A few derived profiles, such as the U.S. DoD STIG, mandate even
stronger
language ("The System shall...", "The system must...."). The ability
to
extend/rename XCCDF titles was accounted for during the U.S. DoD STIG process, and reflected in the STIG Overlay (note the <title> tags): https://git.fedorahosted.org/cgit/scap-security-
guide.git/tree/RHEL6/input/auxiliary/stig_overlay.xml
If we migrate XCCDF titles to an interrogative form, we'd need to
create
XCCDF title overlays for not only the STIG, but also USGCB, NIST,
FISMA, and
almost every profile currently existing. Each overlay is some 1,500
lines
long..... which would mean an administrative burden of at least
another
6,000 lines of code. I'm not sure the effort + burden would be worth
it.
Yeah, truly (now when written down) this looks to be not the ideal way to go. Can understand the guide needs to have the rules in imperative form (the standards' requirements). But your mention about overlays provided another idea to me - what to use overlay to modify the rule names post the HTML guide has been generated?
Like when making RPM, we would first generate HTML guide with imperative form in rule names, then when making the content (final XCCDF mainly) we would apply some overlay - I think it would be enough if it would move the first verb from the beginning to the end. Like:
- 'Set Password Minimum Length' => 'Password Minimum Length Set'
- 'Set Password Maximum Age' => 'Password Maximum Age Set'
...
From what have looked at overlay definition, this seems to be doable. The only question now remaining being if rules named different way couldn't introduce additional confusion (the overlay would need not to change them "too much", like just by moving the imperative at the end for example).
Would this be acceptable? Or not a way to go?
To clarify OVAL result vs remediation result, perhaps the tools could
be
expanded?
For now filed two RFEs (shall I find out more how it could be expanded yet, will file them).
% % % % % % Comments / feedback appreciated. % % Thank you && Regards, Jan. % -- % Jan iankko Lieskovsky / Red Hat Security Technologies Team % % P.S.: Prior actually requesting / proposing this change we % have been considering if scap-workbench tool couldn't % instead of XCCDF rule names display underlying OVAL % check titles (and have these titles customized). But % this approach has been realized as not possible to perform % because: % * there might be more than just one OVAL checks for one % XCCDF rule (in that case which one to display?),
Having multiple OVAL mapped to a single XCCDF rule would be...
challenging.
Every XCCDF rule should reflect a unique configuration change,
preferably to
the level of having a CCE assigned.
As an idea, perhaps we should renaming the XCCDF groups to be
interrogative,
with the individual XCCDF rules being imperative?
Right now scap-workbench doesn't support / display XCCDF group names (just rules' names). Yeah, displaying groups (via clicking on expanding tree fields) might be more appropriate for better organization of the whole benchmark, but I am not sure changing (just) the way XCCDF group names are created would solve our problem.
% % * during parsing the particular XCCDF scap-workbench % (some other tools too?) is operating on rule IDs instead % of rule names so it would be difficult (if even % possible) to modify the code to get it to display
OVAL titles instead of XCCDF rule names.Side note, which may warrant it's own thread: Should we use XSLT to
insert
the XCCDF title automatically into the associated OVAL check? This
could
greatly reduce the maintenance burden if/when any renaming occurs.
Not sure. Martin, would this simplify the scap-workbench's parsing somehow?
% P.S.#2: Another possibility which comes to my mind is instead % to have XCCDF rules shared in both, the HTML version of the % guide and in the validation tool screen, we could dedicate % XCCDF rule names to be displayed just in the validation tools, % and generate rule names for HTML version of the guide some % other way (like keeping it in some other / yet different % XCCDF element and when generating HTML guide use content of % that element instead of XCCDF rule name).
The maintenance burden of this would be high.
Yeah, now you described the way how STIG document is overlay-ed, I can see the complexity. What about the vice versa approach (keep HTML rules names intact, but post generating the guide use overlays to [slightly] change rules' names in final XCCDF) above?
Thanks for starting this thread Jan! It's a very worthwhile
conversation.
No problem. Just trying common user (not aware of all underlying details) when using the tools not to get confused (or if they should ever get confused, we to notice / fix it yet sooner :)).
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
[1] http://isimluk.livejournal.com/3573.html
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Hi,
On 12/05/2013 08:08 PM, Jan Lieskovsky wrote:
Hello Leland,
----- Original Message -----
From: "Leland J Sr CTR DISA FSO Steinke (US)" leland.j.steinke.ctr@mail.mil To: scap-security-guide@lists.fedorahosted.org Sent: Thursday, December 5, 2013 5:36:59 PM Subject: RE: [RFE] [RFC] Define way / policy for the expected form of XCCDF rules' names (possible to use interrogative form instead of current's imperative one?)
Is there a reason the declarative form for Rule names could not be used? Per Shawn's comment, are they considered too strong?
There's nothing wrong with the declarative form for the Rule names, when it's used in form of a guide document (it's actually expected there).
But besides in the guide (HTML form) they might / are be used by scanning tools to identify rule names during scan too - have a look at images in: https://fedorahosted.org/scap-workbench/
Would be possible to rename a rule into a form that would make sense for both use cases? I mean guide and scanner.
Example: "Set Password Minimum Age" -> "Password Minimum Age" "Verify No netrc Files Exist" -> "netrc Files Do Not Exist"
In this context rule name in the form of 'Set Minimum Password Length' might induce the impression in the user that the scanning tool is actually always attempting to set something, which is not the case, when performing the scan.
I agree with Jan that seeing "Set Password Minimum Age - Fail" in a scanner is misleading and from user experience perspective undesirable.
So rule name in form 'Set something' and having result fail might lead to confusion the OS feature / property was attempted to be properly set / configured and that attempt failed (which is not the case) instead of that the property was just scanned for match / compliance with the expected state and didn't meet the requirement (true result).
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
Peter.
Thanks, Leland -- Leland Steinke, Security+ DISA FSO Technical Support Contractor tapestry technologies, Inc 717-267-5797 (DSN 570) leland.j.steinke.ctr@mail.mil (gov't) lsteinke@tapestrytech.com (com'l)
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap- security-guide-bounces@lists.fedorahosted.org] On Behalf Of Jan Lieskovsky Sent: Thursday, December 05, 2013 8:54 AM To: scap-security-guide@lists.fedorahosted.org Subject: Re: [RFE] [RFC] Define way / policy for the expected form of XCCDF rules' names (possible to use interrogative form instead of current's imperative one?)
Thank you for the feedback, Shawn. (Cc-ing Peter and Martin for their opinion yet [as I can say what concrete change could mean for SCAP content, but not what it could mean for the tool]).
----- Original Message -----
From: "Shawn Wells" shawn@redhat.com To: scap-security-guide@lists.fedorahosted.org Sent: Thursday, December 5, 2013 8:10:32 AM Subject: Re: [RFE] [RFC] Define way / policy for the expected form of
XCCDF rules' names (possible to use
interrogative form instead of current's imperative one?)
On 12/4/13, 11:02 AM, Jan Lieskovsky wrote:
% % % % Hello folks, % % as can be seen for example in the scap-workbench demo pictures: % [1] https://fedorahosted.org/scap- workbench/attachment/wiki/WikiStart/browsing_results.png % [2] https://fedorahosted.org/scap- workbench/attachment/wiki/WikiStart/intro_screenshot.png % the current way how XCCDF rules' names are created is in imperative % form (e.g. "Set / Ensure / Verify ...") instead of the interrogative % one (e.g. "Substantive [Subject of the check] meets feature / criteria"). % % While this approach is natural for HTML version of the guide, the XCCDF % rule names are used also in tools performing the scan / remediation % (e.g. scap-workbench: % [3] https://fedorahosted.org/scap-workbench/ ) % % And this is where the source of confusion appears / might appear -- % consider the following selected cases (there are far more of them % than just these though): % % Rule Name | Scan Result % ---------------------------------------------------------- % Set Password Minimum Length in login.defs | fail % ---------------------------------------------------------- % Set Password Minimum Age | fail % ---------------------------------------------------------- % Set Password Maximum Age | fail % % What the scan is actually doing being comparing if applied system's % policy for the expected form of passwords: % * doesn't allow passwords shorter than expected minimum length, % * if there are minimum / maximum periods how long password % (at least / at max) should be considered as valid defined. % % But based on the above presented form scap-workbench / % scap-security-guide user, unfamiliar with the internals, % might obtain an opinion / impressions when seeing the 'fail' % result, that the tool actually tried: % * to set the minimum length for passwords on the system, % * to set minimum and maximum period during that passwords % should be considered valid, % % and this act failed (IOW the current form migth induce a perception % that instead of OVAL check failure [the true reason], the % remediation failed [red herring / false positive]).
From the SSG workshops given through N.A., attendees have yet to
confuse
scanning results with remediation state. Historically this hasn't
been a
concern.
With that said, remediation capabilities are rapidly maturing. With
online
remediation becoming available, such as reflected in Šimon Lukašík's
blog
[1], I could see how users would be confused if the scan failed, or
if the
remediation did.
Yet another way how to look at the existing rule state being the presence of "Set" might induce impression that remediation was attempted, when it actually wasn't (like "Set the feature" the user might think just during the scan the tool tried to "Set the feature", but it failed). Anyway, see below.
If online remediation is attempted, and fails, the end state of the
machine
is still non-compliance. Perhaps an approach would be to extend SCAP Workbench (and OpenSCAP?) reporting functionality to indicate not
only
compliance state, but also if remediation was attempted?
Have filed two RFEs to indicate what's actually performed: [2] https://fedorahosted.org/scap-workbench/ticket/141 (display information about actually processed rule in the statusbar, and also information if it's scan or remediation), [3] https://fedorahosted.org/scap-workbench/ticket/142 (do the same but not in the statusbar, but by changing background color of actually processed rule [scan having one color, remediation another one])
Any other opinion how to distinguish these two yet / indicate which of the two was attempted at the moment?
% % To avoid this source of confusion we propose to change the way % how XCCDF rules are named (use interrogative form instead of % imperative one). % % To mention examples for above three cases: % * 'Set Password Minimum Length in login.defs' would become for % example: % 'User Passwords In login.defs Meet The Minimum Length Requirement / % User Passwords Meet The Minimum Length Requirement / % Only Passwords Longer Than Defined Minimum Allowed' % % * 'Set Password Minimum Age' could become: % 'Minimum Period Between Password Changes Defined' % % * 'Set Password Maximum Age' could be: % 'Maximum Number of Days a Password Might Be Used Set' % % Using this form (we think) the failing scan result wouldn't % conduct to impressions, the remediation being what failed. % % If we could agree on this proposal, I could come with patch % how Fedora rules (or even RHEL6?) names should be changed % not to (possibly) lead to this confusion.
There's been discussion on this in the past. Classically the use of
SSG has
enabled (mostly government) users to demonstrate compliance against requirements . These requirements are imperative, and thus many XCCDF
titles
were mostly written in this form.
A few derived profiles, such as the U.S. DoD STIG, mandate even
stronger
language ("The System shall...", "The system must...."). The ability
to
extend/rename XCCDF titles was accounted for during the U.S. DoD STIG process, and reflected in the STIG Overlay (note the <title> tags): https://git.fedorahosted.org/cgit/scap-security-
guide.git/tree/RHEL6/input/auxiliary/stig_overlay.xml
If we migrate XCCDF titles to an interrogative form, we'd need to
create
XCCDF title overlays for not only the STIG, but also USGCB, NIST,
FISMA, and
almost every profile currently existing. Each overlay is some 1,500
lines
long..... which would mean an administrative burden of at least
another
6,000 lines of code. I'm not sure the effort + burden would be worth
it.
Yeah, truly (now when written down) this looks to be not the ideal way to go. Can understand the guide needs to have the rules in imperative form (the standards' requirements). But your mention about overlays provided another idea to me - what to use overlay to modify the rule names post the HTML guide has been generated?
Like when making RPM, we would first generate HTML guide with imperative form in rule names, then when making the content (final XCCDF mainly) we would apply some overlay - I think it would be enough if it would move the first verb from the beginning to the end. Like:
- 'Set Password Minimum Length' => 'Password Minimum Length Set'
- 'Set Password Maximum Age' => 'Password Maximum Age Set'
...
From what have looked at overlay definition, this seems to be doable. The only question now remaining being if rules named different way couldn't introduce additional confusion (the overlay would need not to change them "too much", like just by moving the imperative at the end for example).
Would this be acceptable? Or not a way to go?
To clarify OVAL result vs remediation result, perhaps the tools could
be
expanded?
For now filed two RFEs (shall I find out more how it could be expanded yet, will file them).
% % % % % % Comments / feedback appreciated. % % Thank you && Regards, Jan. % -- % Jan iankko Lieskovsky / Red Hat Security Technologies Team % % P.S.: Prior actually requesting / proposing this change we % have been considering if scap-workbench tool couldn't % instead of XCCDF rule names display underlying OVAL % check titles (and have these titles customized). But % this approach has been realized as not possible to perform % because: % * there might be more than just one OVAL checks for one % XCCDF rule (in that case which one to display?),
Having multiple OVAL mapped to a single XCCDF rule would be...
challenging.
Every XCCDF rule should reflect a unique configuration change,
preferably to
the level of having a CCE assigned.
As an idea, perhaps we should renaming the XCCDF groups to be
interrogative,
with the individual XCCDF rules being imperative?
Right now scap-workbench doesn't support / display XCCDF group names (just rules' names). Yeah, displaying groups (via clicking on expanding tree fields) might be more appropriate for better organization of the whole benchmark, but I am not sure changing (just) the way XCCDF group names are created would solve our problem.
% % * during parsing the particular XCCDF scap-workbench % (some other tools too?) is operating on rule IDs instead % of rule names so it would be difficult (if even % possible) to modify the code to get it to display
OVAL titles instead of XCCDF rule names.Side note, which may warrant it's own thread: Should we use XSLT to
insert
the XCCDF title automatically into the associated OVAL check? This
could
greatly reduce the maintenance burden if/when any renaming occurs.
Not sure. Martin, would this simplify the scap-workbench's parsing somehow?
% P.S.#2: Another possibility which comes to my mind is instead % to have XCCDF rules shared in both, the HTML version of the % guide and in the validation tool screen, we could dedicate % XCCDF rule names to be displayed just in the validation tools, % and generate rule names for HTML version of the guide some % other way (like keeping it in some other / yet different % XCCDF element and when generating HTML guide use content of % that element instead of XCCDF rule name).
The maintenance burden of this would be high.
Yeah, now you described the way how STIG document is overlay-ed, I can see the complexity. What about the vice versa approach (keep HTML rules names intact, but post generating the guide use overlays to [slightly] change rules' names in final XCCDF) above?
Thanks for starting this thread Jan! It's a very worthwhile
conversation.
No problem. Just trying common user (not aware of all underlying details) when using the tools not to get confused (or if they should ever get confused, we to notice / fix it yet sooner :)).
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
[1] http://isimluk.livejournal.com/3573.html
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 12/6/13, 8:50 AM, Peter Vrabec wrote:
Hi,
On 12/05/2013 08:08 PM, Jan Lieskovsky wrote:
Hello Leland,
----- Original Message -----
From: "Leland J Sr CTR DISA FSO Steinke (US)" leland.j.steinke.ctr@mail.mil To: scap-security-guide@lists.fedorahosted.org Sent: Thursday, December 5, 2013 5:36:59 PM Subject: RE: [RFE] [RFC] Define way / policy for the expected form of XCCDF rules' names (possible to use interrogative form instead of current's imperative one?)
Is there a reason the declarative form for Rule names could not be used? Per Shawn's comment, are they considered too strong?
There's nothing wrong with the declarative form for the Rule names, when it's used in form of a guide document (it's actually expected there).
But besides in the guide (HTML form) they might / are be used by scanning tools to identify rule names during scan too - have a look at images in: https://fedorahosted.org/scap-workbench/
Would be possible to rename a rule into a form that would make sense for both use cases? I mean guide and scanner.
Example: "Set Password Minimum Age" -> "Password Minimum Age" "Verify No netrc Files Exist" -> "netrc Files Do Not Exist"
In this context rule name in the form of 'Set Minimum Password Length' might induce the impression in the user that the scanning tool is actually always attempting to set something, which is not the case, when performing the scan.
I agree with Jan that seeing "Set Password Minimum Age - Fail" in a scanner is misleading and from user experience perspective undesirable.
So then, any volunteers to go through the ~400 XCCDF rules and update their titles?
So rule name in form 'Set something' and having result fail might lead to confusion the OS feature / property was attempted to be properly set / configured and that attempt failed (which is not the case) instead of that the property was just scanned for match / compliance with the expected state and didn't meet the requirement (true result).
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
Peter.
scap-security-guide@lists.fedorahosted.org
-
Jan Lieskovsky -
Peter Vrabec -
Shawn Wells -
Steinke, Leland J Sr CTR DISA DD (US)