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.

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.

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 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

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 
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 

 - 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 

Until next time,

Alex Scheel

Freenode: cipherboy in #openscap
GitHub: https://github.com/cipherboy

Open-scap-list mailing list

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 open-scap-list@redhat.com and others 
authorized to receive it. If you are not open-scap-list@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

Reply via email to