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.
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@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@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
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@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@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@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@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@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
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@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@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@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@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@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@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
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@gmail.com mailto:nevion@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@onyxpoint.com <mailto:tvaughan@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@gmail.com <mailto:nevion@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 <http://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@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> >> To unsubscribe send an email to >> scap-security-guide-leave@lists.fedorahosted.org <mailto:scap-security-guide-leave@lists.fedorahosted.org> > > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 x788 <tel:%28410%29%20541-6699%20x788> > > -- This account not approved for unencrypted proprietary information -- > > _______________________________________________ > scap-security-guide mailing list -- > scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> > To unsubscribe send an email to > scap-security-guide-leave@lists.fedorahosted.org <mailto:scap-security-guide-leave@lists.fedorahosted.org> > _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org <mailto:scap-security-guide-leave@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@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
My two cents on the tooling aspect
Based on this conversation, I started doing my own investigation of Inspec on our systems. One thing that had me nervous was Ruby, since I know there’s a dependency hell that goes along with Ruby gems, and I wasn’t sure how much work would need to be done to get the right packages installed from the Red Hat repos. However, the installation from the inspec.io website was a single RPM that has all the dependencies bundled into it. This obviously has the benefit of being simple to install and maintain, and not needing to worry about which version of Ruby is installed on your system, but it doesn’t really mesh with the Unix philosophy of “Do one thing and do it well.”
For example, in the /opt/inspec/embedded/bin directory, there are 51 binaries, most of which are duplicates of binaries that Red Hat ships in their own packages. I can’t see an easy path to altering the Inspec packaging to rely on Red Hat binaries, but I definitely can’t see Red Hat even considering allowing an application install its own version of the dependent tools, if only from a security perspective, since they’re embedding sensitive libraries like OpenSSL.
So, from an outsiders perspective, I can’t see an easy road to get the tools integrated into official RHEL repositories.
Tom Albrecht III, CISSP-ISSEP, GPEN, RHCSA
From: Shawn Wells [mailto:shawn@redhat.com] Sent: Wednesday, March 22, 2017 10:58 AM To: scap-security-guide@lists.fedorahosted.org Subject: EXTERNAL: Re: RFC: chef.io Inspec
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@gmail.commailto:nevion@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@onyxpoint.commailto:tvaughan@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@gmail.commailto:nevion@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.iohttp://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@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.orgmailto:scap-security-guide-leave@lists.fedorahosted.org
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788tel:%28410%29%20541-6699%20x788
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.orgmailto:scap-security-guide-leave@lists.fedorahosted.org
_______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.orgmailto:scap-security-guide-leave@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@lists.fedorahosted.orgmailto:scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.orgmailto:scap-security-guide-leave@lists.fedorahosted.org
--
Shawn Wells
Chief Security Strategist
U.S. Public Sector
shawn@redhat.commailto:shawn@redhat.com | 443.534.0130
Hi Thomas,
I definitely understand your trepidation against all in one installers but, fundamentally, this is the new way of the world.
All in one installer => Statically compiled bunch of stuff that's hard to maintain and track Docker Container => Statically compiled bunch of stuff that's hard to maintain and track Go => Statically compiled bunch of stuff that's hard to maintain and track Rust => Statically compiled bunch of stuff that's hard to maintain and track
You get the picture, modern life is a whiz-bang set of uncontrolled and untrackable nonsense currently.
Also, the main reason that Ruby doesn't get a ton of love on Red Hat systems is that Red Hat went full bore Python. The number of esoteric Python libraries that show up is amazing compared with the similar Ruby environment. That said, both from the stock distributions are pretty much useless without enabling Software Collections to get a newer version.
For the purposes that I was talking about, just running it locally or against test systems, the OpenSSL issue doesn't really come into play. But I do 100% agree that distributed RPMs should be linked against the system OpenSSL libraries for FIPS compatibility. We can work on patching the upstream spec files to do this or make it a request *if* the SSG community decides to adopt the tool set.
Thanks,
Trevor
On Wed, Mar 22, 2017 at 10:36 AM, Albrecht, Thomas C < thomas.c.albrecht@lmco.com> wrote:
My two cents on the tooling aspect
Based on this conversation, I started doing my own investigation of Inspec on our systems. One thing that had me nervous was Ruby, since I know there’s a dependency hell that goes along with Ruby gems, and I wasn’t sure how much work would need to be done to get the right packages installed from the Red Hat repos. However, the installation from the inspec.io website was a single RPM that has all the dependencies bundled into it. This obviously has the benefit of being simple to install and maintain, and not needing to worry about which version of Ruby is installed on your system, but it doesn’t really mesh with the Unix philosophy of “Do one thing and do it well.”
For example, in the /opt/inspec/embedded/bin directory, there are 51 binaries, most of which are duplicates of binaries that Red Hat ships in their own packages. I can’t see an easy path to altering the Inspec packaging to rely on Red Hat binaries, but I definitely can’t see Red Hat even considering allowing an application install its own version of the dependent tools, if only from a security perspective, since they’re embedding sensitive libraries like OpenSSL.
So, from an outsiders perspective, I can’t see an easy road to get the tools integrated into official RHEL repositories.
Tom Albrecht III, CISSP-ISSEP, GPEN, RHCSA
*From:* Shawn Wells [mailto:shawn@redhat.com] *Sent:* Wednesday, March 22, 2017 10:58 AM *To:* scap-security-guide@lists.fedorahosted.org *Subject:* EXTERNAL: Re: RFC: chef.io Inspec
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@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@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@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@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@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@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.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@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
--
Shawn Wells
Chief Security Strategist
U.S. Public Sector
shawn@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
Shawn,
Well, if we include it in the SIMP stack, it'll be delivered with the SIMP stack.
That said, we're looking at it as an enhancement to our Rspec-driven acceptance testing and I'm still a bit leery of just dropping it out in the clear. Particularly since we're working on disabling SSH as an option on our systems per the requirement of running no unnecessary services (oh, and you might want to make Ansible have pluggable back ends because we're trying to eliminate unnecessary system agents, particularly ones that are overpowered direct command and control :-D ). No, we won't be disabling SSH by default because people get mad, but we do want it to be an achievable end goal.
I would like to keep the configuration management completely separate from the checking capabilities. I like using SCAP because I don't have the fox watching the henhouse. None of the CM tools have good capabilities for system checking specifically because that's not what they are designed to do. They are designed to *enforce* and there are logic paths in that enforcement that simply cannot be followed without application.
Scanning tools are there to...well...scan and should have community vetted content that can be used.
Ideally, we would translate directly from the SSG into inspec checks but *also* be able to easily extend and override the SSG derived content to run checks of our own. We go above and beyond what the SSG requires and it would be *great* to be able to just plop in our code and have OVAL output shot out the other side. Doing the mappings in the code, as inspec did, also helps us stay pinpoint in our checks and analysis.
Doing this well will probably require some changes to inspec but the architecture makes sense and it's something that the SIMP team can integrate and use relatively easily. But, we don't want to jump down that rabbit hole if it's not going to be honored by ACAS because that's fundamentally pointless work.
Thanks,
Trevor
On Wed, Mar 22, 2017 at 9:57 AM, Shawn Wells shawn@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@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@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@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@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@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@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
scap-security-guide mailing list -- scap-security-guide@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@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
-- Shawn Wells Chief Security Strategist U.S. Public Sectorshawn@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
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@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@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@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@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@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@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@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
scap-security-guide mailing list -- scap-security-guide@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@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
-- Shawn Wells Chief Security Strategist U.S. Public Sectorshawn@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
scap-security-guide@lists.fedorahosted.org