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
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.
Reference for anyone interested:
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
* 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
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),
On Wed, Jan 31, 2018 at 6:28 PM, Shawn Wells <shawn(a)redhat.com> wrote:
On 1/31/18 11:42 PM, Trevor Vaughan wrote:
> Is OpenControl decided on?
OpenControl and SCAP serve two different purposes. There's been
conversations about providing something to integrate them, aka through
some higher-level tooling or Web UI, but each would exist as independent
Lots of the SSG community sufficiently convinced me it was a really bad
idea. I was wrong about integrating everything together.
There *is* work ongoing on creating a much easier input language for
XCCDF. Something that can better support tailoring that would flow
through SCAP, Ansible, and future remediation and evaluation languages
(Chef? Puppet?). The build tools would transform the input language into
specification-compliant XCCDF. For code examples, see:
It's all an experiment at this point. Gabe brought up a really good idea
at DevConf..... once people get back from DevConf and vacations it may
be a good idea to host a community call so we can all share
notes/opinions on how to evolve.
> It's not an approved standard from NIST, there seem to be standards in
> place, or being developed, that would support what it's trying to do,
> and it's *extremely* loosely defined to the point of constant
> misinterpretation. (Please let's not go down the route of "the
> implementation is the standard", that way lies madness of the 90's).
Any pointers to stuff being developed?
> I also still have had issues with actually maintaining the content
> once is has been reasonably formed in the first place.
> Though the controls are *extremely* odious, it seems like the tooling
> needs to go into the content management experience as opposed to a git
> workflow that we expect ISSOs to be able to use (I simply haven't
> found it yet).
> I LOVE the idea, but the practical execution and maintenance over time
> has yet to be proven.
> On the centralized DB idea, it's XML, import translations to SQL (or
> anything else) should be an XSLT away!
> I don't think that dictating any database in particular is a good idea
> for SCAP but I do think that making it easy to put the data into
> processable chunks would be a good idea. That said, it's pretty easy
> to parse the XML and I think some consolidated libs in the most common
> languages would go a long way (Python, Ruby, PERL(maybe?), SQL99+
> standard output for automatic DB creation in <DB of choice>).
> Thinking about this, it might be nice to have a standardized SCAP
> server with a standardized API for queries. That I could 100% get
> behind so that everything could be vendor agnostic.
Yah, we definitely need that open community call in a weekish time.
There were lots of conversations at DevConf that were not meant to be
exclusionary for people not at DevConf. Stuff will be floating to the
mailing list or broad community conversations over the next few days
(week?) as people travel home from the Czech Republic.
But in general... no DB needed for operating SCAP. Rather we have the
component pieces to make something of higher value (like a DB with an
API for standard queries for collections of SCAP reports that represent
all components of an information system).
scap-security-guide mailing list -- scap-security-guide@lists.
To unsubscribe send an email to scap-security-guide-leave@
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --