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) [email protected] (gov't) [email protected] (com'l) > -----Original Message----- > From: [email protected] [mailto:scap- > [email protected]] On Behalf Of Jan > Lieskovsky > Sent: Thursday, December 05, 2013 8:54 AM > To: [email protected] > 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" <[email protected]> > > To: [email protected] > > 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 > > [email protected] > > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > > > _______________________________________________ > scap-security-guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
