I'm all for simplifying SSG; however, the roadblocks that Shawn has listed
cannot be understated. How would environments using puppet or ansible or
bash or <insert_cm_tool_here> work with Inspect especially as Inspect
appears to be more of a Chef component? Moving away from a defined standard
SCAP (for better or for worse) that is consumed by multiple tools to a
single tool could decrease the adoption of SSG such as not being able to be
consumed by ACAS, Nessus, OpenSCAP, etc. Of course, the inverse could also
be true. I also would add from personal experience that many Government and
Security auditors would move not to use SSG if it is not SCAP compliant.
IMO, it would be better to change/upgrade the standard by working with NIST
to make it say JSON (or something else that address the shortcomings of the
XCCDF/OVAL XML) as a new SCAP version.
Just my 2c.
On Wed, Mar 22, 2017 at 8:57 AM, Shawn Wells <shawn(a)redhat.com> wrote:
Really like the simplicity of Inspect! In my own world view, the
only
thing that really matters is automating the C&A compliance burden and
doing so with tools+content that people can actually use (SCAP or not,
don't really care).
There are roadblocks to using Inspec: not natively included in enterprise
operating systems, the US Gov doesn't recognize it as a configuration or
vulnerability scanner, and results cannot be ingested by mandatory tooling
like ACAS and various CDM tools. Same challenges that Ansible and Puppet
face, too.
Out of the Ansible/Puppet/Chef grouping, Ansible is the only one with
roadmap to be natively included in Linux. However Ansible 'check mode'
isn't nearly as easy/robust as Inspec. Makes me feel a little.... stuck.
If content was developed for Inspec, how would people be able to consume
it? Theoretically the @redhat.com'ers could finagle a way to ship the
*content*. We certainly could upload it to the NIST National Checklist
Program. But how would people get the Inspec *tooling*? I'm not sure if
downloading off the internet is viable for most system owners.
On 3/22/17 10:05 AM, Trevor Vaughan wrote:
So, in my case, I'm working on the application and validation of different
compliance profiles as part of the SIMP project.
In each of our configuration modules, I wanted to integrate an SSG scan
into the final phases of our acceptance testing.
I probably should have said 'development framework' instead of
'demonstration framework'. But, the idea is that we can run regular
acceptance tests as part of our CI process by integrating inspec into that
mix.
We started down a path similar to inspec but abandoned it because we
wanted to use the authoritative SSG materials so that we could show the C&A
authorities an apples-to-apples comparison.
Unfortunately, this proved to be simply too complex since we could not
extract micro data streams out of the SSG in an automated fashion. For
example, we have an auditd module. For this, we would want to apply our
settings against NIST 800-53 and then test against the 800-53 SSG profile.
We would then want to switch to STIG and test against the STIG profile,
etc... However, we *only* want to do it for the auditd portions of the SSG
and we just couldn't find an easy way to make this happen that didn't
require a LOT of upkeep.
Thanks,
Trevor
On Tue, Mar 21, 2017 at 11:37 PM, Jason Newton <nevion(a)gmail.com> wrote:
> Hi Trevor,
>
> The hope is that any work with SSG, rigor included would be 10x less
> cost of any lines of the SSG. So it is a new cost but relative to
> long term maintenance costs, it likely more than wins out - and
> hopefully the SSG project would arrive at that point fast - in like a
> month or two if someone puts in serious porting effort and starts
> getting peer review going.
>
> For running Inspec on production nodes - I went back and forth on my
> reply here and my final thoughts are, well this is the double edge
> sword of solving all integration and parsing problems by hosting the
> DSL in ruby. If all concerning functionally cannot be hidden (using
> ruby-fu) prior to module loading without breaking functionality, then
> there's not really much that can be done with this approach
> fundamentally - perhaps they could make some validatable Inspec
> DSL-based document (that is not ruby) for the InSpec DSL that is
> runnable
>
> Was not quite sure what you meant regarding validating demonstration
> frameworks and utility although the condition of peer reviewed came
> through clearly.
>
> Any devs care to weigh in?
>
> -Jason
>
>
>
>
>
> On Mon, Mar 13, 2017 at 8:36 PM, Trevor Vaughan <tvaughan(a)onyxpoint.com>
> wrote:
> > I've also been looking at Inspec and it shows quite a bit of promise to
> fix
> > a lot of the usability issues of the SSG project.
> >
> > However, to be an integrated enhancement/replacement, it will need to go
> > through the same level of rigor as the SSG checks.
> >
> > Let's face it, while that rigor can be painful, it is at least
> validatable
> > while Inspec is truly just whatever code you wish to run on a system.
> >
> > I'd be a bit scared of running Inspec on production nodes since it's
> > basically a root-level command and control system with almost nothing
> in the
> > way of checks and balances.
> >
> > That said, for validating demonstration frameworks, it may be useful
> if, and
> > only if, the community content can become peer reviewed and concrete.
> >
> > Thoughts about integrating it into the SSG project?
> >
> > Trevor
> >
> > On Sun, Mar 12, 2017 at 8:17 PM, <nevion(a)gmail.com> wrote:
> >>
> >> Hi folks,
> >>
> >> I've watched the project for a couple of years now and done some work
> with
> >> it. I'm grateful many of you took the time to get SSG where it's
at.
> >> Recently I came across chef.io's Inspec and I thought hey, this seems
> to
> >> solve alot of the engineering challenges the SSG project seems to have,
> >> especially with multi-distro support.
> >> Github:
https://github.com/chef/inspec
> >> Product:
https://www.chef.io/inspec/
> >>
> >> Here are some of the benefits my eyes see:
> >>
> >> * Content is centralized (less mutli-file editing for the same tests
> aka
> >> less XMHell :-)
> >> * Content is encouraged to be less distribution specific but allowed
> to be
> >> as specific as it needs, and this is encouraged inside a module,
> meaning
> >> less versions are floating around in the codebase
> >> * Declarative/Programmatic as opposed to Declaritive/document oriented
> -
> >> I'd say with the later case has led to somewhat awkward and hard write
> >> tests, in some cases
> >> * Can test active configuration as well as configuration file state
> >> * Looks significantly less verbose - as in saving 10x lines of
> sourcecode
> >> (not counting XML output) and developer productivity would be much
> higher
> >> * and as a possible benefit, I wouldn't be surprised if tests ran much
> >> faster - though I have done no extensive tests to show this.
> >>
> >> Most importantly I believe inspec could pave the way to all distros
> >> working off of a common and smaller codebase than the existing SSG
> >> implementation and be far less maintenance burden and as such I wanted
> to
> >> raise awareness and get a topic going on the ML.
> >>
> >> Inspec doesn't seem compatible out right with openscap (or maybe it is
> -
> >> they have bidirectional oval/xccdf consumers/emitters), but it IS
> aiming to
> >> replace OVAL/XCCDF as something more sane and just plain old better
> for the
> >> tasks. They also have tools for running it without scap tools
> involved of
> >> course so it doesn't have to lean on openscap et al, but for some
> people
> >> being seperate from SCAP tools is going to be a con and not a pro.
> >> _______________________________________________
> >> scap-security-guide mailing list --
> >> scap-security-guide(a)lists.fedorahosted.org
> >> To unsubscribe send an email to
> >> scap-security-guide-leave(a)lists.fedorahosted.org
> >
> >
> >
> >
> > --
> > Trevor Vaughan
> > Vice President, Onyx Point, Inc
> > (410) 541-6699 x788
> >
> > -- This account not approved for unencrypted proprietary information --
> >
> > _______________________________________________
> > scap-security-guide mailing list --
> > scap-security-guide(a)lists.fedorahosted.org
> > To unsubscribe send an email to
> > scap-security-guide-leave(a)lists.fedorahosted.org
> >
> _______________________________________________
> scap-security-guide mailing list -- scap-security-guide(a)lists.fedo
>
rahosted.org
> To unsubscribe send an email to scap-security-guide-leave@list
>
s.fedorahosted.org
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788 <(410)%20541-6699>
-- This account not approved for unencrypted proprietary information --
_______________________________________________
scap-security-guide mailing list -- scap-security-guide(a)lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave(a)lists.fedorahosted.org
--
Shawn Wells
Chief Security Strategist
U.S. Public Sectorshawn(a)redhat.com | 443.534.0130 <(443)%20534-0130>
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.
fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@
lists.fedorahosted.org