Hello Gary, Martin,
----- Original Message -----
From: "Gary Gapinski" <gapinski(a)nasa.gov>
To: scap-security-guide(a)lists.fedorahosted.org
Sent: Wednesday, February 19, 2014 8:39:39 PM
Subject: Re: [RFC] time to move to github?
On 02/19/2014 11:17 AM, Jeffrey Blank wrote:
> I do not want a variety of government agencies
> creating Frankenstein forks of scap-security-guide.
I am unsure whether this is worthy of a fork, but read on.
> I want them to use
> the profiling mechanisms of XCCDF to select what they need from a single
> high-quality dictionary of compliance checks (for each product for which
> such content exists). One of the unstated goals of the project is to
> keep the variety of government compliance machines under some control by
> providing a solution which meets >95% of use cases.
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).
Projected into scap-workbench functionality this means:
* have possibility to merge various profiles (by grepping various but only
unique rules),
* have possibility how to specify the subset of rules (within that resulting
checklist) that should be scored during scan.
scap-workbench (SW) currently supports tailoring (e.g. a way how to select
subset of rules from particular profile into new one). From that implies
to me that the first point could be (possibly) reached with currently
supported SW functionality as follows:
1) Select particular profile. Use tailoring. Select all rules from it, and
save it.
2) Load another profile in the "Profile:" field of the SW section, load the
previously saved tailoring file, and click customize. Naive view suggests
SW should in that scenario allow to add rules from the selected profile
to the original tailoring (but didn't try it, so might be wrong)
If not (Cc-ing Martin for hint on this), there should be a SW ticket:
[1]
https://fedorahosted.org/scap-workbench/newticket
created for this enhancement (please note you need to be logged in to be
able to file new SW ticket).
For what is worthy regarding selecting just of a subset of rules, that should
be scored during the scan, I don't think this is currently supported / possible
in SW (Martin pls correct me here too). => This would need another ticket to be
filed to cover this scenario.
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.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
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).
A <Profile> cannot alter the role² attribute of a <Rule> (to unscored
rather than full).
We intend to do this using a modified benchmark containing a single
<Profile>, and applying arbitrary "profiles" to the evaluation results
at a subsequent time.
This is most easily done using a fork describing the necessary changes.
A fork may also ease the task of having a single checklist for RHEL6 and
RHEL7 comprised of parts common to both as well as parts peculiar to either.
Regards,
Gary
--
¹ Actually most, as we will not traipse through terabytes of local
storage looking for unowned files, e.g.
² Goes back a ways:
http://making-security-measurable.1364806.n2.nabble.com/role-unchecked-er....
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide