[RFC] time to move to github?

Jan Lieskovsky jlieskov at redhat.com
Mon Feb 24 17:25:42 UTC 2014


Hello Gary,

  apologize for late reply (other things prevented me from sooner reaction). Anyway:

----- Original Message -----
> From: "Gary Gapinski" <gapinski at nasa.gov>
> To: "Jan Lieskovsky" <jlieskov at redhat.com>, scap-security-guide at lists.fedorahosted.org
> 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.
> 
>


More information about the scap-security-guide mailing list