[RFE] [RFC] Define way / policy for the expected form of XCCDF rules' names (possible to use interrogative form instead of current's imperative one?)

Steinke, Leland J Sr CTR DISA FSO (US) leland.j.steinke.ctr at mail.mil
Thu Dec 5 16:36:59 UTC 2013


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 at mail.mil (gov't)
lsteinke at tapestrytech.com (com'l)


> -----Original Message-----
> From: scap-security-guide-bounces at lists.fedorahosted.org [mailto:scap-
> security-guide-bounces at lists.fedorahosted.org] On Behalf Of Jan
> Lieskovsky
> Sent: Thursday, December 05, 2013 8:54 AM
> To: scap-security-guide at 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 at redhat.com>
> > To: scap-security-guide at 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 at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> >
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5601 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20131205/f6c290db/attachment.bin>


More information about the scap-security-guide mailing list