Hello Gary,
apologize for late reply (other things prevented me from sooner reaction). Anyway:
----- Original Message -----
From: "Gary Gapinski" <gapinski(a)nasa.gov>
To: "Jan Lieskovsky" <jlieskov(a)redhat.com>,
scap-security-guide(a)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.