On 2/1/18 1:21 PM, Luke Salsich wrote:
Thanks for the comments guys. It helps me understand where things are and where they might be going.
For me, I would write a (initial) user story much along the lines of:
"I would like to be able to parse oscap results into a MySQL database so that I can compare specific aspects of these results to others from the same server or from other servers."
I word it like this because I (personally) am not looking for a larger application framework (user interface, authentication, etc) that has to come along with the central database. I also like the idea of not being tied to one database engine and/or using a standardized API, but an API sounds like a few stories down the road.
Anyway, I'm grateful for the thoughts. I was initially just checking to make sure that before I start working on converting the XML to SQL (probably with xslt and Python) that someone else hasn't already done that. I hate it when I build something only to find out later that someone in the community has already built it (and probably way better).
Imagine something like https://osquery.io/, except with enriched compliance data.
I guess I was thinking of this being the modernized version of the CMDB effort that keeps trying to live because, frankly, it literally is CM information.
This was the first FOSS-core thing that popped up in my search and seems reasonable at first glance.
I'd love to be part of this, I'd also love to not reinvent the wheel (again). That said, as an extendable platform, maybe iTop is horrible, there needs to be a global conversation about it (and FIPS, SSP, etc...)
https://www.combodo.com/itop-193
Trevor
On Thu, Feb 1, 2018 at 11:41 AM, Shawn Wells shawn@redhat.com wrote:
On 2/1/18 1:21 PM, Luke Salsich wrote:
Thanks for the comments guys. It helps me understand where things are and where they might be going.
For me, I would write a (initial) user story much along the lines of:
"I would like to be able to parse oscap results into a MySQL database so that I can compare specific aspects of these results to others from the same server or from other servers."
I word it like this because I (personally) am not looking for a larger application framework (user interface, authentication, etc) that has to come along with the central database. I also like the idea of not being tied to one database engine and/or using a standardized API, but an API sounds like a few stories down the road.
Anyway, I'm grateful for the thoughts. I was initially just checking to make sure that before I start working on converting the XML to SQL (probably with xslt and Python) that someone else hasn't already done that. I hate it when I build something only to find out later that someone in the community has already built it (and probably way better).
Imagine something like https://osquery.io/, except with enriched compliance data.
scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
I like where this is going as I have similar needs/issues. I currently do the same as Paul Arnold ("an oscap cron with "brief" results going to centralized syslog") and give a big "+1" for open systems.
I like https://osquery.io/ (open source at: https://github.com/facebook/osquery)
Also consider InSpec (https://github.com/chef/inspec) - though created by/for Chef, it's entirely self-contained. OpenSCAP integrating with either/both of these would be awesome.
(Both are Apache 2.0 licensed.)
=Fen
On Thu, Feb 1, 2018 at 11:41 AM, Shawn Wells shawn@redhat.com wrote:
Imagine something like https://osquery.io/, except with enriched compliance data.
I knew about inspec, but everything else is new to me. One thing I dislike about gov't work, is your so far behind on learning/using new tech.
A couple of things to think about as we move towards the idea of Compliance As Code and a central CLI/WebUI.
1. We are moving away from authoring content in XML and towards a YAML style format which was shown at Defense in Depth last year. Many people were smiling and liking the idea. Even now, playing with YAML as the authoring language at DevConf has people smiling and exclaiming how easy it is to use. There is no perfect format, but we have had too much feedback over the dislike of XML for authoring.
2. One guide authoring language to many outputs. In essence, the build system would consume the YAML guides (migrated from XCCDF), Ansible, BASH, Inspec, OVAL (possibly migrating writing this in YAML), etc. to output in DS, XCCDF, Ansible/Bash roles, Inspec, etc. to be consumed by the engine of your choice. Don't think that the OpenSCAP scanner should actually consume Inspec content..... or maybe it should. Also, just to be clear, SCAP formats would still be generated as output for consuming in SCAP scanners.
3. DB would most likely be used for this central CLI/WebUI as a way to store, manipulate, and potentially generate the data/content for SSPs, SCAP reports, etc.
4. Think beyond a CM tool. That would just one potential component of this. What other tooling could be used in the future to solve security issues in the disconnected space? For example OpenControl allows you to code and generate a SSP. What else could be an addon or integrated?
It is important to note that OpenControl and SSG for example would still be separate projects that would be consumed by the CLI/DB/WebUI for generation, reporting, etc.
On Thu, Feb 1, 2018 at 11:59 AM, Matthew simontek@gmail.com wrote:
I knew about inspec, but everything else is new to me. One thing I dislike about gov't work, is your so far behind on learning/using new tech.
scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
Response inline.
Thanks,
Trevor
On Thu, Feb 1, 2018 at 2:58 PM, Gabe Alford redhatrises@gmail.com wrote:
A couple of things to think about as we move towards the idea of Compliance As Code and a central CLI/WebUI.
- We are moving away from authoring content in XML and towards a YAML
style format which was shown at Defense in Depth last year. Many people were smiling and liking the idea. Even now, playing with YAML as the authoring language at DevConf has people smiling and exclaiming how easy it is to use. There is no perfect format, but we have had too much feedback over the dislike of XML for authoring.
So, I'd like to officially vote against YAML for this (if that counts for anything).
XML is a complete bear to author and nobody is going to do that manually. 100% agree.
However, YAML is not really rich enough to cover what we need across the board and has the added drawback that it can be unsafe to use as well as made VERY confusing to non-technical users (whitespace matters, bizarre internal link references, and all that).
For admins and devs, it's fine, but we *need* to start getting input on this from people that write policy and have a hard time with fiddly technology.
Would something like a DSL work for this and/or be worth the effort?
If not that, how about HOCON (basically non-irritating JSON) https://github.com/lightbend/config/blob/master/HOCON.md#hocon-human-optimiz...
I like the idea of a DSL because, frankly, this is a specific domain and we're basically just talking about making something that can be processed into XML (for compatibility and compliance reasons) but easy for people to write and maintain.
Personally, I really need the ability to be able to inject all of these results into my documentation with minimal fuss.
- One guide authoring language to many outputs. In essence, the build
system would consume the YAML guides (migrated from XCCDF), Ansible, BASH, Inspec, OVAL (possibly migrating writing this in YAML), etc. to output in DS, XCCDF, Ansible/Bash roles, Inspec, etc. to be consumed by the engine of your choice. Don't think that the OpenSCAP scanner should actually consume Inspec content..... or maybe it should. Also, just to be clear, SCAP formats would still be generated as output for consuming in SCAP scanners.
I think that the stated community workflow should be XCCDF/OVAL -> <Arbitrary Scanner> -> OVAL Results. OpenSCAP should be the reference implementation but other scanners should be able to be injected without issue into the process.
Perhaps the `oscap` command could turn into a multiplexer that calls one of many back-end scanners of your choice?
The real issue here is the tailoring. What we do with InSpec vastly outstrips what the native OVAL checks can support since we can dynamically and richly interpret the content of the system. That said, it also makes them potentially more variable since the check (and overrides) can support the target environment and 'one size' no longer fits all (but then, it never really did).
- DB would most likely be used for this central CLI/WebUI as a way to
store, manipulate, and potentially generate the data/content for SSPs, SCAP reports, etc.
Could this start with a set of APIs that are designed for the data and then let the DB back-ends find themselves as the community sees fit to contribute?
- Think beyond a CM tool. That would just one potential component of
this. What other tooling could be used in the future to solve security issues in the disconnected space? For example OpenControl allows you to code and generate a SSP. What else could be an addon or integrated?
I don't quite follow. This *is* part of the core definition of CM. We've just been doing it badly as an industry.
For context, from http://sebokwiki.org/wiki/Configuration_Management:
"The purpose of configuration management (CM) is to establish and maintain the integrity of all of the identified outputs of a project or process and make them available to concerned parties (ISO/IEC/IEEE 2015). Unmanaged changes to system artifacts (such as those associated with plans, requirements, design, software, hardware, testing, and documentation) can lead to problems that persist throughout the system life cycle..."
In the case of SCAP, we're defining the ability to measure the configuration drift of system security artifacts from a specified and allowed configuration. But, that configuration has to be explicitly tied to all of the appropriate subsystems such that we can sufficiently demonstrate a constant, and consistently updating, operational situational awareness.
So, in short, why would we not tie that back into a consistent CM scheme and re-jumpstart the awareness that good CM is what we're actually trying to achieve?
In terms of generating an SSP, copy/paste also lets me generate an SSP but, just like OpenControl (or anything else where the content is not reviewed per system change), 90% of the time it will be wrong in one or more ways.
I believe that our Open Source community should start moving down the path of providing 800-18 compliant SSPs for all system components inasmuch as they are actually applicable and that these outputs should have a standardized, computer processable, format. Fundamentally, it's just documenting your code in a repeatable (highly tedious) and standardized manner.
scap-security-guide@lists.fedorahosted.org