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.
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
