Hello Gary, apologize for late reply (other things prevented me from sooner reaction). Anyway:
----- Original Message ----- > From: "Gary Gapinski" <[email protected]> > To: "Jan Lieskovsky" <[email protected]>, > [email protected] > Sent: Friday, February 21, 2014 1:36:05 PM > Subject: Re: [RFC] time to move to github? > > Hello, Jan: > > On 02/20/2014 05:30 AM, Jan Lieskovsky wrote: > >> Our intent is to score a subset of all checklist items but have all > >> items evaluated on all systems. This requires all¹ <Rule>s to be > >> selected. > > Gary, if I got your use case from this (and your subsequent email from > > today) correctly, > > the request being as follows: > > * on one hand to have a "profile / checklist" of all rules (grepped by > > their > > uniqueness) that ever existed for RHEL {6,7} products. All rules would > > be > > selected by default, and > > * to have possibility to score only subset of them during scan > > > > (feel free to correct me if I didn't the request details properly). > > I'll try to address this from the composite of both of my previous posts. > > First, to your second itemization… > > Yes. We wish to evaluate most rules, thus obtaining a record of security > posture, while scoring an arbitrary subset. The result of such an > evaluation will, subsequent to evaluation, be subjected to further > analysis using arbitrary foci in a large data repository. > > This can be achieved using "select" and "role" attributes on a > <refine-rule> element (XCCDF ≥1.2). The schema indicates these are > mutable as well as weight and severity. > > Not so easy to achieve is to alter other parts of the checklist not > subject to a tailoring profile. Our compliance metrics infrastructure — > currently only XCCDF 1.4 capable — requires that benchmark id and > profile id be changed, and the folks responsible wish a only a single > profile to be used to reduce complexity. We track revisions using the > status and version elements. Excision of unused matter such as unused > rules and OCIL is optional but desirable. > > The altered checklist presented to the compliance metrics infrastructure > need not be and is not the same as that presented as a prose document > for general reference. In particular, sections such as those dealing > with services such as web and email would not necessarily be immediately > automated but still used as configuration guidance. I have yet to > determine whether such service-specific checklist sections can be > routinely automated using special rules that determine the presence or > absence of such services (likely using platform qualifiers at the group > or rule level). > > > Second, to your first itemization… > > We intend to use a single checklist for both RHEL6 and RHEL7 (and > derivatives), ideally augmented at a subsequent time for use with Debian > distributions (the compliance metrics folks want as few checklists as > possible: e.g., we just released a combined Internet Explorer 9/10/11 > checklist). Such use requires altered platform specificity at the > checklist and rule level. We had hoped that SSG use a similar approach > at least for RHEL 6 and 7 (single rules and single checks where common; > platform-specific checks when platform-specific checks are required, and > platform-specific rules when required). > > In other words, a single checklist for Linux distributions having a > single rule for each single security practice common to all, but > possibly having different expressions in several. > > This is rather the same as a compilation obtained from «one "core" > content repository being able to handle various use-cases». > > > Projected into scap-workbench functionality this means: > > [snip] > > > > To sum up: > > * either "merging of rules" is currently supported in SW already, and you > > could > > perform as described above. Or an RFE should be filed for it this to be > > possible in the future (let me know, if I should file that ticket on > > your > > behalf), > > * scoring subset of profile rules during scan would require new RFE ticket > > (again can file it on your behalf, just let me know). > > > > The advantage of aforementioned approach (when compared to > > scap-security-guide > > fork) being in case more users having same request / use case scenario as > > you, they > > could profit from these (possibly new) SW features without needing to > > perform > > additional steps (SSG fork & own XSLT transforms implementation). > > > > Of course, all of the above depends on the fact if underlying standards / > > scanner implementation allows this (needs deeper inspection). Stay tuned. > > I will. Tailoring appears adequate for rule role modification, not > obviously so for some of the other desired alterations. > > Were I to reduce our intended checklist to a simple list, it would be > one specifying each desired rule to be obtained from a repository of > such individual checklist items, as well its desired select and role > attributes, and the desired variable value(s) to be used. Governing this > selection would be target platforms. OCIL presence or absence would be > arbitrary. The resulting compilation would have an id, title, > description, version, status, etc. > > That is not the same as a <Tailoring> construct. Hmm, looks like I misunderstood this could be performed via tailoring. In any case since one example is better than thousand of words (and if I remember correctly you to have mentioned having a reference implementation available already -- checking would it be possible you to point me to the fork of SSG repo / XSLT transformation performing the desired change? If not (the code not being private) could you apply that transformation at current SSG content, and share the result with me, so I could have a look and find out, what's actually desired without having to dive too deeply into the corresponding specifications? Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team > > Though it does not fit easily into the manner of "tailoring" anticipated > by those who have devised SCAP, our intended compilation is appropriate > for our current needs. > > > P.S.: Hopefully from the above being visible that (in my opinion) parser > > tools > > customizations are preferred way rather than SSG content forks (IOW > > agree with Jeffrey, > > that there should be one "core" content repository being able to > > handle various use-cases, rather than dozen of content forks, each > > of them bended to serve / handle particular instance expectations). > > I agree. > > In our case, we do not wish to perturb the individual rules and > associated checks, just the manner in which they are compiled into a > checklist. Ours is currently a derivation rather than a compilation. The > latter is preferable, the former currently easier. > > Regards, > > Gary > > PS: I like github for many of the reasons thus far mentioned, and would > prefer it if it made my tasks easier, which may not have anything to do > with forking. The "split" of SSG content for RHEL 6 and 7 does indeed > make my tasks more difficult. > > _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
