On Thu, Feb 1, 2018 at 2:58 PM, Gabe Alford <redhatrises(a)gmail.com> wrote:
A couple of things to think about as we move towards the idea of
Compliance As Code and a
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
XML is a complete bear to author and nobody is going to do that manually.
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
Would something like a DSL work for this and/or be worth the effort?
If not that, how about HOCON (basically non-irritating JSON)
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
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
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
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
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
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