I can relate to you experienced from your previous employers. It’s sometimes very difficult to convince leadership to buy off on pushing code into the Open Source community. 

We (the Aqueduct community) would have really liked to see Red Hat and their Employees set the standard for keeping a community working together, rather than individuals forking existing code in active projects to solve the exact problem. 

A community is only as strong as it's contributors and Red Hat isn't contributing anything.

If you were to pose the concept to the Aqueduct mailing list, the community would embrace your ideas of ‘allowing the customer to decide on what’s best for their site/project’ and would help you along the way. As the STIG matures and issues/fixes are committed, having the source Aqueduct code based being reused will save all of us a great deal of time. Rather than forcing people to pick which fork of the day works best for them. Again - a community is only as strong as it's contributors. 

If you’re interested in helping out the Aqueduct community, I’d be more than happy to sponsor your commit access.

-V

On Sep 3, 2014, at 5:23 AM, Frank Caviggia <fcaviggi@redhat.com> wrote:

Vincent,

The reason the scripts that I wrote were called "stig-fix" is because the bash scripts that I originally I started with were part of Tresys' CLIP project. I wanted to contribute back to Aqueduct originally, but my employer at the time wouldn't let me at the time (I believe I meet you at one of the summit presentations a few years back). It took 4 entire re-writes of the code (each between different government customers and the same employer, starting with the stig-fix base that I wrote at home) before I could get both the government and the and my employer to allow me to release a "finished" and evaluated version the code to Red Hat. (The government was understanding that it could benefit the community, but It took telling my customer that they couldn't make a dime off of the source because I started with open-source code.)  I merged in USGCB, NSA SNAC guidance along the way, and the Aqueduct content was finally merged in around the 4th re-write, all of which had to be massaged for changes RHEL 6.  It is by no means the official script from Red Hat (SSG is the official project), and is offered AS-IS with no support which is why I put it up on github, I want the users to have control over the end product and make a fork that works for their group/site/project.

I may remove the checks entirely at some point (SSG is the official Red Hat security script to check configurations) and only distribute only some pre-STIG'ed configurations (iptables, ip6tables, sysctl.conf, PAM configs, etc.) and a few toggle scripts (e.g. toggle_usb, toggle_ipv6, etc.), allowing the users to check-point the configurations after customization and creating and redistributing those customizations as an RPM for configuration other like systems using a kickstart.  The purpose to allow the customer to decide what's best for them and their site/project.

Anyway, I hope this clears up where everything came from. Please feel free to ask if you have any question.  I just want to get the job done for a customer in the most efficient way possible, which is straight from the installation. Please feel free to contact me if you have any questions or concerns.

Regards,

Frank Caviggia


----- Original Message -----
From: "Vincent Passaro" <vince@buddhalabs.com>
To: "Joe Nall" <scap-security-guide@lists.fedorahosted.org>
Sent: Wednesday, September 3, 2014 1:49:37 AM
Subject: Re: Remediation advice for RHEL 5 and 6



On the topic of the rhel stig fix repo, what was the intent in forking Aqueduct bash content and creating a separate project? Wouldn't we want to keep things together to prevent the community from now having multiple projects attempting the same goal... Using the same Aqueduct code?

It would make sense that a fork occurred if it was done by an external person or company, but this was done by Red Hat employees.

I'm sure the Aqueduct community would have loved to see the contribution from Red Hat back into the project.
On Sep 2, 2014 9:46 PM, "Shawn Wells" < shawn@redhat.com > wrote:



On 9/3/14, 12:09 AM, Vincent Passaro wrote:


Phillip,

Aqueduct definitely has the most options (Ansible / Puppet / Bash) for DISA STIG remediation.

Cheers,

Vince

On Sep 2, 2014, at 9:03 PM, Philip Shuman < philip.shuman@sri.com > wrote:



Are the Aqueduct remediation scripts still the best available place to start for implementing requested changes from the DISA STIG findings for RHEL5 and RHEL6?


Aqueduct is pretty much the only location with RHEL5 scripts. And like Vince pointed out, Aqueduct also has Puppet and Ansible. IIRC, the Puppet scripts were contributed by Maura Dailey earlier this summer, and represented NSA open sourcing their baseline. Everything Aqueduct has is reputable and very tested.

A benefit of SSG is that scanning/remediation is tightly integrated through human-readable prose guides, scanning/evaluation, and remediation. A single change within SSG (say, to tailor password lengths) will automatically trickle to prose guides (XCCDF), evaluation (OVAL), and remediation (bash scripts). SSG also benefits from a vibrant community, and further, will be shipping natively in RHEL 6.6+.

A third option would be to evaluate the STIG kickstart builder Red Hat Gov released to GitHub:
https://github.com/RedHatGov/stig-fix-el6-kickstart

It wraps SSG + stig-fix scripts + banners into a customized installation DVD/ISO. Many of the remediation scripts were originally sourced from Aqueduct.




--
SCAP Security Guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
https://github.com/OpenSCAP/scap-security-guide/

--
SCAP Security Guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
https://github.com/OpenSCAP/scap-security-guide/

--
Frank Caviggia
Consultant, Red Hat
fcaviggi@redhat.com
(M) (571) 295-4560
--
SCAP Security Guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
https://github.com/OpenSCAP/scap-security-guide/