I'd like to approach this from a usability point of view and re-request a feature that I feel is crippling adoption of SCAP in orgs that can't have dedicated SCAP-fu experts.

Adding additional layers of complexity is going to further drive away adoption, particularly without good command line and/or graphical tools to understand what I'm looking at.

SA's have very little time to deal with long layers of complexity and not working to enable them to create and modify their own SCAP checks and overrides in a sensible manner is going to continue the battle between the Security and Ops/Dev teams.

What I need, and I know is being worked on in fits, is the ability to not just have profiles, but to be able to directly override various check mechanisms.

In this manner, a very small profile could be noted as compatible with the main profile version X.Y.Z but also have a small data stream that would allow for the following capabilities:

1) Direct replacement of OVAL checks (because I do it my way, per the written documentation)
2) Addition to the checks...if RHEL, or CentOS, or Fedora, or Whatever.... -> OVAL
3) Custom remediation -> I love that you want me to have a broken PAM config for my environment, but I don't want one, thanks

This, in theory, combined with a profile, would allow very small, modular segments to be written that could apply to VMs, Docker Containers, whatever. Basically, anything that is a proper subset, with extensions, of something else.

Something else that would be useful is to push the base structure of the XML databases to 3NF with association tables. While it would be a lot of work, the SCAP content is pretty much directly a database structure and would be *much* easier to manipulate if the relationships were not bound to the original files.

I 100% understand that you can fork the entire standard into another block every time you want to change something but, as history has shown, this way lies upkeep madness and promotes inconsistency across the entire environment.

If you want to be extreme about it, vendors could start setting up SCAP microservices against a standard that would allow for on the fly composition of local Data Streams where all content was twice validated before application.

The SSG, while awesome, is suffering from usability issues that is driving incompatible change at the local organization level pretty much everywhere that I've gone. At some point it's just too much work to keep merging in arbitrary upstream changes to large bases and actually know that you're getting it right. We need more abstract composition ability.

Source: Keep trying to do it my way without forking the entire SSG project and keep failing.

Thanks,

Trevor 

On Fri, Oct 21, 2016 at 1:15 PM, Radzykewycz, T (Radzy) <radzy@windriver.com> wrote:
> From: Brent Kimberley <Brent.Kimberley@Durham.ca>
> As opposed to writing one XCCDF, why not write one XCCDF per
> point of interest (inside the container of interest, inside the
> OS but outside the container of interest, ...) - until upstream
> standards address Origin, Point (in SpaceTime), Frame of Reference,
> ... for a cyber-physical assembly?

When I start working on our container environment, I expect I
need to write custom XCCDF and custom OVAL for some of the checks.
Some of the management may be done in the container, but I expect
most to be done in the underlying host.  So paths may be different,
which would lead to either more complex OVAL with parameterization,
or duplication of the OVAL content.

And as implied elsewhere, the XCCDF needs to be modified to
indicate the correct information for the environment.

Enjoy!

-- radzy
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org



--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --