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 <[email protected] > <mailto:[email protected]>> 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 > <[email protected] <mailto:[email protected]>> 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, <[email protected] > <mailto:[email protected]>> 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 -- > >> [email protected] > <mailto:[email protected]> > >> To unsubscribe send an email to > >> [email protected] > <mailto:[email protected]> > > > > > > > > > > -- > > 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 -- > > [email protected] > <mailto:[email protected]> > > To unsubscribe send an email to > > [email protected] > <mailto:[email protected]> > > > _______________________________________________ > scap-security-guide mailing list -- > [email protected] > <mailto:[email protected]> > To unsubscribe send an email to > [email protected] > <mailto:[email protected]> > > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 x788 > > -- This account not approved for unencrypted proprietary information -- > > > _______________________________________________ > scap-security-guide mailing list -- [email protected] > To unsubscribe send an email to > [email protected] -- Shawn Wells Chief Security Strategist U.S. Public Sector [email protected] | 443.534.0130
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected]
