So, bear with me here because it took a bit of technological soul searching to come to this conclusion...
But....if I've read the XCCDF 1.2 specification correctly, *everything* we need is contained either in it or in one of the referenced standards.
XML, at it's core (and as much as I hate it), *is* a portable, semi-normalized database format. Heck, Oracle has a built in XML DB back end!
Personally, I find working with reStructuredText to be best for the halfway point between what users need and what the data can provide. It's highly flexible through extensions (Sphinx, etc...) and creates reasonable, repeatable documentation that can be composed.
In that vein, I took a couple of days and made some transforms and scaffolding that would transform the raw specification XCCDF into user-friendly RST with reference links, etc... It's not perfect, but (so far), it appears to be generally appealing.
Working off of something like this model would allow for the core materials to flow back and forth between XCCDF and RST (or whatever) seamlessly but the core lies in being able to feed the system.
Now, give me a summer intern level web interface with the ability to allow for user-friendly manipulation of the underlying XML and we're getting somewhere! Don't make it a towering monolith of parts and I'm guessing that it'll probably gain a heck of a lot of traction pretty darn fast.
In terms of the remediation language of choice, it's a battle that we've been fighting long and hard on the SIMP project and it's the reason that we took a "compliance over time" view of the world. There's no reason you can't use any language to do it (even just BASH) but you have to approach the issue as a platform, not as a set of rules for individual parts. If you don't do this, you have no way of knowing what you've broken across the whole (I'll bug match anyone at this point).
Until (when/maybe/whatever) *fully* immutable and controlled infrastructures become the absolute norm AND OPERATIONAL DISCIPLINE CATCHES UP, a single application of configuration onto a system is only as solid as the first time that someone wants to change something. Heck, the first inkling of the thing that sparked my early ideas for something like SIMP was way back when I first learned about the STIGs. I then did what we all do and wrote a shell script that "hardened" the box -- once. It was doomed to failure because that's not how operations work.
Operations is about the flexibility to meet business requirements and to balance the automation of the underlying platform with the ability of the operator to do business *as they see fit*. Any automation of this will be complex and can only be as good as the tests and community around it. The change of any given setting should be reported and allowed or overridden by policy as required. This is where SIMP has gotten as a project but it is diametrically opposed to a one-time approach to system hardening.
Reading the NIST 800-18, *technically*, there should be an SSP just for SSH and, if the community supports it, why shouldn't all of the various components have their own micro-tailored SSPs as an open industry standard? (Ok, that might be stretching it but it's policy accurate).
In terms of the standards that currently support this type of work (as of my reading):
* NIST 800-18 fits hand in glove with
* The XCCDF Version 1.2 spec which references
* NIST IR 7693 - Specification for Asset Identification
* NIST IR 7695 - Basically SWID Tags
But, you may ask, how do we define the system!
Well, that problem was formally solved about a decade ago with SysML which is handily recognized in XML format and highly portable.
Yes, none of this is sexy, and boy is it complex, but this is a complex problem requiring high levels of precision for interoperability and I simply can't find another set of published *standards* that fit the bill. Unfortunately, this all lends itself to a small, isolated community because it's both difficult to work on and time consuming. BUT, this is a problem across the entire Federal government, and beyond now with the new CUI requirements and we need to work together, in the open, to solve it correctly.
Finally, if we target this as a consolidated community effort, we might just come up with an Open Source operational playbook that, if followed, could simply check a lot of the procedural boxes for both Federal and non-Federal entities that need to follow 800-53 and 800-171 respectively.
Uh....rant off :-/
Thanks (and hopefully this is helpful),
Trevor