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.
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/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.
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.
[1] http://isimluk.livejournal.com/3573.html
_______________________________________________
scap-security-guide mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
