Apologies for the late reply, I fell off of the planet for a while there. So, let's take this for instance: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/profiles/ospp-rhel7-server.xml#L20
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 functionally accurate. 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 https://github.com/simp/pupmod-simp-compliance_markup. And these can be validated over time against set variables. The first working example file can be found at https://github.com/simp/simp-core/blob/5.1.X/src/puppet/bootstrap/environments/simp/hieradata/compliance_profiles/nist_800_53_rev4.yaml . 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 non-monolithic method. 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 expected. But again, perhaps I'm just doing it incorrectly and hopefully this helps clarify my use case. Thanks, Trevor On Tue, Apr 26, 2016 at 1:49 PM, Shawn Wells <[email protected]> wrote: > > > On 4/25/16 2:51 PM, Martin Preisler wrote: > >> ----- Original Message ----- >> >>> >From: "Trevor Vaughan"<[email protected]> >>> >To: "SCAP Security Guide"<[email protected]> >>> >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: > > https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/profiles/ospp-rhel7-server.xml > > - RHEL7 STIG extends base NIAP profile with whatever things DISA feels is > relevant: > > https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/profiles/stig-rhel7-server-upstream.xml > > - The DoD Secure Baseline will extend the NIAP profile with CNSSI 1253 > overlay controls. > > 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 > [email protected] > > https://lists.fedorahosted.org/admin/lists/[email protected] > https://github.com/OpenSCAP/scap-security-guide/ > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --
-- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/admin/lists/[email protected] https://github.com/OpenSCAP/scap-security-guide/
