Apologies for the late reply, I fell off of the planet for a while there.
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.
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