On 1/31/18 10:22 PM, Luke Salsich wrote:
Hey all,
I've been using OpenSCAP for a while on our servers and really appreciate what it does.
I've been looking around for a way to store scan results and then query them and I can't seem to locate any plugins or apps which do this other than SCAPTimony.
SCAPTimony sounds great, but I'm not sure it's currently maintained and I don't really want to dive into Foreman just to store Oscap results.
What does the community use for this kind of scan / report storing and querying?
We're currently using Ansible AWX to run scans and to manage remediation. Love to find a way to pull that XML into a central database.......
This week was DevConf in Brno [0] and this very topic came up multiple times! The quick answer being broad agreement that "yes this must happen."
There are partner projects like Foreman (upstream) and Satellite (downstream) which integrate scanning into their embedded databases. In general there is a desire to unify SCAP with OpenControl for central reporting though.
Many are in transit from Brno back home over the next few days, or recovering locally from staying out all night for the past week :) Some responses might be slightly delayed because of this.
If you could have database integration with SCAP.... what all would you want it to do? Could you help the community form a few user stories?
Is OpenControl decided on?
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).
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.
Thanks,
Trevor
On Wed, Jan 31, 2018 at 4:45 PM, Shawn Wells shawn@redhat.com wrote:
On 1/31/18 10:22 PM, Luke Salsich wrote:
Hey all,
I've been using OpenSCAP for a while on our servers and really appreciate what it does.
I've been looking around for a way to store scan results and then query them and I can't seem to locate any plugins or apps which do this other than SCAPTimony.
SCAPTimony sounds great, but I'm not sure it's currently maintained and I don't really want to dive into Foreman just to store Oscap results.
What does the community use for this kind of scan / report storing and querying?
We're currently using Ansible AWX to run scans and to manage remediation. Love to find a way to pull that XML into a central database.......
This week was DevConf in Brno [0] and this very topic came up multiple times! The quick answer being broad agreement that "yes this must happen."
There are partner projects like Foreman (upstream) and Satellite (downstream) which integrate scanning into their embedded databases. In general there is a desire to unify SCAP with OpenControl for central reporting though.
Many are in transit from Brno back home over the next few days, or recovering locally from staying out all night for the past week :) Some responses might be slightly delayed because of this.
If you could have database integration with SCAP.... what all would you want it to do? Could you help the community form a few user stories?
[0] https://devconf.cz/cz/2018
scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
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).
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 shawn@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
What does the community use for this kind of scan / report storing and querying?
This isn't ideal -- but I generally use an oscap cron with "brief" results going to centralized syslog. Query the centralized syslog for results as needed. I also have the HTML reports archived on an NFS share, which is what the ISSO/ISSM prefer to review. This works well for anything automated, but the manual check XCCDF stuff is a mess to manage.
scap-security-guide@lists.fedorahosted.org
-
Arnold, Paul C CTR USARMY PEO STRI (US) -
Shawn Wells -
Trevor Vaughan