Apologies for the late reply, I fell off of the planet for a while there.
So, let's take this for instance:
That's a good setting, and a useful variable, however I need to modify the
OVAL *checks* themselves to understand an LDAP-aware environment as well as
accepting either the cracklib or pwquality PAM plugins since they are both
If I meet this requirement in LDAP, it should also be done on the host, but
both are valid methods for enforcing the policy.
Additionally, I now have a method for mapping my variables into policy with
our compliance_markup function
. And these can be
validated over time against set variables. The first working example file
can be found at
Each of these variables should, in practice, map back to some level of SCAP
verifiable code. But, we implement items that are not yet in the
SSG/STIG/Whatever. To this end, we need to be able to easily extend the
content, without forking, in a user friendly manner. I think we *may* be
able to do this by rolling additional files into a Data Stream but I'm not
quite certain from the existing documentation.
Finally, we're starting to revamp the way that we do documentation to be
application-centric with the goal of having our acceptance tests run
micro-SCAP scans and have the output injected into our security
documentation at build time.
This is all well and good but, to really be successful, we need to be able
to override specific OVAL content to test the way that we implement in a
I didn't find any tools for this and I *really* don't want to fork the
whole thing to change OVAL content.
Fundamentally, I want to enable a 'trust but verify' model where Puppet
enforces our configuration and feeds data into a SCAP scanning system but
the SCAP scanner actually validates that the system is performing as
But again, perhaps I'm just doing it incorrectly and hopefully this helps
clarify my use case.
On Tue, Apr 26, 2016 at 1:49 PM, Shawn Wells <shawn(a)redhat.com> wrote:
On 4/25/16 2:51 PM, Martin Preisler wrote:
> ----- Original Message -----
>> >From: "Trevor Vaughan"<tvaughan(a)onyxpoint.com>
>> >To: "SCAP Security
>> >Sent: Sunday, April 24, 2016 2:03:25 PM
>> >Subject: Re: cnssi No 1253 profile needed
>> >The main RH6 and RH7 SSG profiles.
> Could you write up the use-cases and report it as a bug? Probably we can
> expose something in the rules as variables and then you will be able to
> tailor it in the way you need.
We're polishing out the RHEL7 STIG. Once that activity clears, we'll start
working on a DoD Secure Host Baseline.
(Interesting to talk about incorporating/elevating SIMP into that. Lets
hold that conversation for a minute though.)
The working intent is something like this:
- RHEL7 USGCB is a "base profile" that is aligned to NIAP's Operating
System Protection Profile. Ref:
- RHEL7 STIG extends base NIAP profile with whatever things DISA feels is
- The DoD Secure Baseline will extend the NIAP profile with CNSSI 1253
These three common/related profiles should set the base configurations for
US Government. They'll all ship natively in the installer, allowing users
to directly deploy into these configurations (as hopefully been useful with
the RHEL7 Vendor STIG!).
That leads to solving how people will tailor these baselines. In the most
simplistic use case, users can load SCAP Workbench and modify rule
selections and refine values. SCAP Workbench will generate custom RPMs (if
ran on RHEL hosts), and/or a "tailoring file" that outlines how you drifted
from the common baseline. More advanced users can cryptographically hash
things for integrity checking. The content can also be imported into
Satellite for central config management/scanning.
Trevor, how do you think you'll need to modify these for your use?
SCAP Security Guide mailing list
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --