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-9d97484...
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).