Thanks for the reply! A few comments inline. :)

- Alex

----- Original Message -----
> From: "Trey Henefield" <trey.henefi...@ultra-ats.com>
> To: "Alexander Scheel" <asch...@redhat.com>, open-scap-list@redhat.com
> Sent: Thursday, August 23, 2018 11:24:14 AM
> Subject: RE: Guide Mergers and Simplifications in SCAP Security Guide
> 
> Hi Alex,
> 
> I have contributed a fair ammount of content in the past and would love to
> continue to do so.
> 
> The biggest challenge Iv'e had in working with this group is the rapid number
> of structural changes.

Yeah, structural changes are hard and I definitely hear you on that. I think
we're nearing a stabilizing point with the project though. I think the structure
is much better designed now than it was before. Hopefully there'll be less churn
in location of files. I can't speak to future plans of the team but I don't
personally foresee many major reorganizations except for maybe with the
SSG Test Suite and perhaps with templated files.


What I've tried to do personally is to provide utilities to convert between
structures. They'll likely need some modification to work with your particular
usages, but the bulk of the work is done there. A few comments below:



For the guide mergers discussed in this email, I've used the
`utils/find_similar.py` script:

https://github.com/OpenSCAP/scap-security-guide/pull/3218

Along with a couple of custom shell commands to walk the files after merging
them and deal with the few manual cases:

https://github.com/cipherboy/dotfiles/blob/master/bashrc.d/ssg.bash#L1-L60

(Sorry about the one-character non-descriptive names, but typing only
one character speeds up the comparison significantly...). I'll update those
functions with comments.



For the rule directory changes (which I'm working on a separate post about
that), there's the `utils/move_rules.py` utility that can be adapted for any
internal products you're carrying:

https://github.com/OpenSCAP/scap-security-guide/blob/78ef185e6b886aa19a3df27a966af2ba3df65803/utils/move_rules.py

That one should need fewer manual modifications to get work with your
internal products or changes.


There's also the creation of the ssg python module + unit tests for that.
These changes might affect your build if you've significantly changed our 
CMake scripts, but it should be easier to find how the build is orchestrated,
and add support for other artifacts if you're interested in that.


> 
> By the time I take the latest content and add in changes to bring us closer
> to full compliance with STIG requirements, a new SSG release is pushed, and
> requires me to change allot of what I just wrote to match the new structure
> in SSG. While enhancements to the process to makes things simpler and
> consistent are always welcomed. It would be nice if those changes were
> pushed less often to allow us content developers to complete changes and
> submit them upstream before having to go back and change everything to match
> newest release.

I'd encourage you to open a PR with some subset of your changes if you can, 
even if it doesn't apply to master and is based against an older commit.

If nothing else, it'd give us visibility into what sorts of patches are needed
for better STIG compliance and make us more aware of your content changes
before reorganizing stuff. In the better case, we can perhaps pull some of your
changes and refine our tools to make the restructuring easier to deal with.

>
> Secondly, there seems to be some difference of opinions between what RedHat
> feels should be implemented for a requirement versus what DISA requires to
> be configured to meet a requirement. Ive had commits rejected for that very
> reason. This has pretty much discouraged me from commiting any other
> changes. While we still develop content to support ensuring our systems are
> compliant with the DISA STIGs, it would be nice to put aside difference of
> opinions and support bringing compliance to currently enforced DISA STIG
> requirements within the SSG baseline.

I'll leave this to be discussed among those with more knowledge about this.

> 
> I think that once those two issues are resolved, you will likely see further
> enhanced content being contributed.
> 
> Best regards,
> 
> Trey Henefield, CISSP
> Senior IAVA Engineer
> 
> Ultra Electronics
> Advanced Tactical Systems, Inc.
> 4101 Smith School Road
> Building IV, Suite 100
> Austin, TX 78744 USA
> 
> trey.henefi...@ultra-ats.com
> Tel: +1 512 327 6795 ext. 647
> Fax: +1 512 327 8043
> Mobile: +1 512 541 6450
> 
> -----Original Message-----
> From: open-scap-list-boun...@redhat.com <open-scap-list-boun...@redhat.com>
> On Behalf Of Alexander Scheel
> Sent: Thursday, August 23, 2018 9:16 AM
> To: open-scap-list@redhat.com
> Subject: [Open-scap] Guide Mergers and Simplifications in SCAP Security Guide
> 
> Greetings, everyone!
> 
> 
> I'm Alex, the US-based intern working with the OpenSCAP team this summer. We
> also have an intern in Brno, Milan, who has been with the team for longer.
> I'm posting to highlight some of the work I've done, and how I think this
> will help the OpenSCAP community at large. I’ll be focusing on the SCAP
> Security Guide (SSG) project, where we host all of our compliance content.
> 
> Part of the problems facing the OpenSCAP team is that we’re not experts with
> the complete matrix of different compliance documents, Linux distributions,
> or projects that we provide content for. As different individuals contribute
> to SSG, they usually do so for only the projects they’re familiar with. A
> direct result of this was that, over time, Debian, RHEL6, and RHEL7 content
> grew increasingly fragmented despite starting out largely similar. Partly,
> this was due to the complexity of writing content in XML format and using
> XSLT macros; with the migration to YAML markup and Jinja2 macros,
> maintaining a shared directory which supports all distributions is now
> easier than separate directories. On top of this, having many independent
> locations for content made it hard for individuals new to the project to
> find where to make their changes. Thus, merging the guides was an important
> step in reducing technical debt in SCAP Security Guide.
> 
> Below, I outline one of the things we’ve improved this summer, with the hopes
> of encouraging more individuals to contribute to the SSG project. Hopefully
> a few users will be inspired to create quick PRs fixing issues you see on a
> day-to-day basis. Stay tuned for a later mailing list post about additional
> changes made. :)
> 
> With the help of Martin Preisler, Gabe Alford, and everyone else, I've been
> collapsing the disparate Linux guides into a shared location:
> `linux_os/guide`.
> This helps to improve maintainability, finding the location of rules, and
> fixing any issues they have. Changes against one product will now benefit
> all products:
> typos, new additions, compliance with standardized language, etc.
> 
> This means that, if anyone is carrying internal patches or tailoring files
> against rhel6, debian8, or wrlinux, your changes will not apply cleanly to
> the
> 0.1.40 release (or current master). While this causes major breakage--and you
> should audit your tailoring and patches--the quality of the content
> definitely improved on the whole. If you are able to upstream these, we'll
> be happy to review them and incorporate what we can, which will let us help
> migrate your rules in the future if we do any more reorganization.
> 
> Together, these changes should significantly improve the contribution process
> and reduce the cost of maintaining the SSG project. To compare the latest
> master
> (cef60dd72fae0c858e236667344ba531188ba977) to the tagged v0.1.39 release
> (74e45ee0373d2c8f06dfc3fa66e6b83660cfce2a) to show the state of content:
> 
> Red Hat Enterprise Linux 6
> === v0.1.39 ===
> * rules:            441
> * checks (OVAL):    378       [85% covered]
> * fixes (bash):     280       [63% covered]
> * fixes (ansible):  221       [50% covered]
> * fixes (puppet):   32        [7% covered]
> * fixes (anaconda): 33        [7% covered]
> * CCEs:             423       [95% covered]
> === master ===
> * rules:            480
> * checks (OVAL):    391       [81% covered]
> * fixes (bash):     286       [59% covered]
> * fixes (ansible):  237       [49% covered]
> * fixes (puppet):   35        [7% covered]
> * fixes (anaconda): 35        [7% covered]
> * CCEs:             406       [84% covered]
> 
> Benchmark statistics for debian8:
> === v0.1.39 ===
> Profile all:
> * rules:            49
> * checks (OVAL):    45        [91% covered]
> * fixes (bash):     9 [18% covered]
> * fixes (ansible):  23        [46% covered]
> * fixes (puppet):   9 [18% covered]
> * fixes (anaconda): 0 [0% covered]
> * CCEs:             16        [32% covered]
> === master ===
> Profile all:
> * rules:            213
> * checks (OVAL):    88        [41% covered]
> * fixes (bash):     22        [10% covered]
> * fixes (ansible):  34        [15% covered]
> * fixes (puppet):   12        [5% covered]
> * fixes (anaconda): 0 [0% covered]
> * CCEs:             0 [0% covered]
> 
> Benchmark statistics for wrlinux:
> === v0.1.39 ===
> Profile all:
> * rules:            50
> * checks (OVAL):    29        [57% covered]
> * fixes (bash):     13        [26% covered]
> * fixes (ansible):  10        [20% covered]
> * fixes (puppet):   0 [0% covered]
> * fixes (anaconda): 0 [0% covered]
> * CCEs:             0 [0% covered]
> === master ===
> 
> Profile all:
> * rules:            213
> * checks (OVAL):    55        [25% covered]
> * fixes (bash):     15        [7% covered]
> * fixes (ansible):  10        [4% covered]
> * fixes (puppet):   2 [0% covered]
> * fixes (anaconda): 0 [0% covered]
> * CCEs:             0 [0% covered]
> 
> Note that many of the rules which were added to Debian 8 and WRLinux lack
> checks and remediations. Most of these do have corresponding checks for
> RHEL7 though -- if you’re interested in contributing PRs to add support for
> these distributions, we’re happy to review and merge them! If anyone wants
> help getting started, feel free to ask.
> 
> For more technical information about these changes, please refer to the
> corresponding pull requests below, or reach out to one of us, either
> directly or via the mailing list. (Friendly reminder that we lurk in the
> #openscap channel on Freenode. Due to spam recently, we've restricted
> messaging to users with voice mode, but we're happy to grant that to anyone
> if they PM one of the operators).
> 
>  - rhel6 start: https://github.com/OpenSCAP/scap-security-guide/pull/3037
>  - debian8 start: https://github.com/OpenSCAP/scap-security-guide/pull/3129
>  - wrlinux start: https://github.com/OpenSCAP/scap-security-guide/pull/3153
>  - rhel6 end: https://github.com/OpenSCAP/scap-security-guide/pull/3131
>  - debian8 end: https://github.com/OpenSCAP/scap-security-guide/pull/3151
>  - wrlinux end: https://github.com/OpenSCAP/scap-security-guide/pull/3154
> 
> Thanks everyone for their support, advice, and reviews! As always, we're
> happy to receive feedback, issues regarding the content, or PRs helping to
> improve the content. We'll do our best to review these in a timely manner
> and will try and tag some issues as easy fix or help wanted if people are
> looking for a place to get started. And lastly, a shout-out and thanks to
> all our external contributors!
> 
> 
> 
> 
> Until next time,
> 
> Alex Scheel
> 
> Freenode: cipherboy in #openscap
> GitHub: https://github.com/cipherboy
> 
> _______________________________________________
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
> 
> Disclaimer
> The information contained in this communication from
> trey.henefi...@ultra-ats.com sent at 2018-08-23 11:24:17 is confidential and
> may be legally privileged.
> It is intended solely for use by asch...@redhat.com and others authorized to
> receive it. If you are not asch...@redhat.com you are hereby notified that
> any disclosure, copying, distribution or taking action in reliance of the
> contents of this information is strictly prohibited and may be unlawful.
> 

_______________________________________________
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Reply via email to