Response inline. Thanks,
Trevor On Thu, Feb 1, 2018 at 2:58 PM, Gabe Alford <[email protected]> wrote: > 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. > 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-optimized-config-object-notation 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. > > 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. > 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). > > 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. > 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? > > 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? > 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 mailing list -- [email protected] To unsubscribe send an email to [email protected]
