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. Reference for anyone interested: https://github.com/simp/NIST-800-18-SSP_Template 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 On Wed, Jan 31, 2018 at 6:28 PM, Shawn Wells <sh...@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 > projects. > > 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: > > PR: https://github.com/OpenSCAP/scap-security-guide/pull/2592 > > Sample: > https://github.com/OpenSCAP/scap-security-guide/pull/2592/files#diff- > 9d97484f343daa972e1d7eac853fa584 > > 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. > 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 --
_______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org
