On 02/19/2014 06:04 PM, Shawn Wells wrote:
On 2/19/14, 2:39 PM, Gary Gapinski wrote:
> 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.
Will SCAP Workbench make this any easier for you?
I am unsure.
Currently, a variant XCCDF document is produced using a (XSL) transform
of the original XCCDF document driven by a document containing a set of
changes identifying insert/modify/delete targets using XPath references
to the original. The changes include <Benchmark> descendant-or-self
element and attribute alterations (e.g., id, <title>, <description>,
<version>, <platform>, etc.), <Profile> excision and insertion,
<Value>
modifications, <Rule> role specification, in a few cases <Rule>-specific
<platform> insertion, <Group>/<Rule> excision, and OCIL excision. The
OVAL document remains unchanged; the CPE related documents are manually
altered to address CentOS. The altered SCAP bundle is then provided to
the compliance metrics infrastructure.
This is tedious. Performed in order to maintain (in)fidelity to the
original and to avoid maintaining a distinct XCCDF document (though I
remain open to that variation as it may approach equal pain at some
later time). Particularly awkward due to XCCDF shortcomings: e.g., a
<Profile> lacks precise control of all aspects of changes, and <select>,
<set|refine-value>, <Value>+<value>, and <Rule> elements are in
the same
solar system but on different planets, in communion solely via
paranormal channels. Much easier would be a simple list of desired
checklist items where all attributes of an item were specified together
(particularly <value>(s)).
> 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.
wrt a single checklist, much of that work could be accomplished by
adjusting the OVAL. Patches would be very, very welcome.
Complexity increases due to the SSG split into RHEL 6 and 7 branches.
While some version-specific OVAL will be needed, most checklist items
(XCCDF rules) are not version-specific (many are not even
distribution-specific).
An à la carte approach would be easier were individual security posture
items defined, then elaborated upon for different venues (e.g., password
complexity, with subordinate platform- and version-specific checks).
Such ease would of course facilitate unorthodox compilations.