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?
Thanks, Philip
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?
Thanks, Philip
-- 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/
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 mailto: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.
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/
Warning - shameless commercial plug below.
I'm an engineer on a commercial product called 'Security Blanket' that can also help with the remediation against the RHEL5 and RHEL6 STIGs, in addition to other industry/government standards. We do not consume the SCAP content directly from DISA, but read the manual prose and then use our own library code to implement the desired changes. If you are interested, please check our our website at http://www.trustedcs.com/securityblanket. There are some very dated videos on YouTube that you can find as well as a much more recent video on our reseller's web-site : http://www.shadow-soft.com/linux-hardening. Feel free to contact me off list as well.
-Rob Sanders
=========================== Rob Sanders Sr. Secure Systems Engineer Raytheon Trusted Computer Solutions 12950 Worldgate Drive, Suite 600 Herndon, Virginia 20170 Security Blanket Support: 1-866-230-1317 Security Blanket Email: SecurityBlanket@TrustedCS.com Office: 703-896-4762 Fax: 703-318-5041 Email: RSanders@TrustedCS.com
________________________________ From: scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Vincent Passaro [vince@buddhalabs.com] Sent: Wednesday, September 03, 2014 1:49 AM To: Joe Nall 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.commailto: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.commailto: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.orgmailto:scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
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.
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/
On 9/3/14, 12:47 PM, Vincent Passaro wrote:
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.
Many Red Hat staff needed a stable, repeatable process to build a customized RHEL6 STIG installation disk. Code from Aqueduct was needed to accomplish this goal. /And/ from the Tresys CLIP. /And/ from SCAP Security Guide. /And/ from some home-brew gluecode. Once these things were mashed together a installation disk was churned out in a very predictable manner, serving the purposes of those who needed the disks. People noticed the ability to generate custom, pre-STIG'd installation media and wanted to create their own. So we put the code on GitHub.
Independently tracking each underlying project and figuring out what patches/revisions from each are needed is generally to cumbersome to the average user. The stig-fix-el6-kickstart [1] and stig-fix-el6 [2] repositories are not to meant to usurp or undermine any of these communities, but rather snapshot each component and turn out an installable DVD/ISO file. This represents a very healthy upstream/downstream relationship. Every attempt was made to credit upstream sources, and you'll notice upstream sources are called out in the respective README files [3][4].
Hope this clears up the stig-fix-el6-kickstart repos. They are not an attempt at forking any project, or to build a new community. Just to organize all the subprojects in a very consumable fashion (which is to say, generate installation disks).
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.
Hatters helped migrate the DoDBastile code from forge.mil into Aqueduct [5], Hatters helped create some of the first "how to use Aqueduct" videos [6], Hatters hosted the initial Aqueduct community calls [7][8][9], Hatters helped organize Aqueduct community meetups (such as before the DC Government Symposium [10]), and Hatters invited you to speak at Red Hat Summit 2012 [11].
Hatters also list Aqueduct as a project of interest off the official Red Hat Government webpage: https://www.redhat.com/en/technologies/industries/government/standards
And I personally wrote a blog on using Aqueduct to STIG a RHEL5 box (albeit, it's now somewhat outdated): http://blog-shawndwells.rhcloud.com/so-you-wanna-stig-a-rhel5-box-part2/
My prior role at Red Hat was to cover U.S. Intelligence programs. During our 2012 update to Ft Meade -- which had worldwide attendance from staffers and contractors -- I specifically called out Aqueduct. Reference p91-p96: http://blog-shawndwells.rhcloud.com/wp-content/uploads/2012/07/2012-02-08-MP...
Another Hatter called out Aqueduct at Red Hat Summit 2014 as well (ref p17): http://rhsummit.files.wordpress.com/2014/04/seifried_w_0230_cloud_security.p...
So, we should perhaps reword slightly: "A community is only as strong as it's contributors and Red Hat isn't contributing anything /*to Aqueduct, _lately_*/"
And lets now address that reworded statement.
On 7-JULY-2011, Hatters began briefing the Aqueduct on initiatives regarding SCAP [12][13]. Steve Grubb personally gave a webinar on the matter [14]. Then on 28-SEPT-2011, the Aqueduct community was informed the SCAP Security Guide project was starting [15]. A snippet from that original EMail:
It is designed to provide security guidance and checking content in the SCAP formats. Specifically, the project goal is to produce --- from a single body of content:
- an informative prose guide, similar in style to NSA's RHEL 5 guide
- a desktop settings baseline, similar in style to NIST USGCB
- a server settings baseline, similar in style to a STIG
- additional baselines for other network roles (such as LAMP server)
- a body of automated checking content in the OVAL format
As reflected in the text above, SSG was initially formed to build out prose and compliance automation content. Incredibly complementary to Aqueduct, which held remediation scripts.
Almost a year later, on 1-AUG-2012, I began the conversation of linking SSG (compliance) with Aqueduct (remediation) [16]. My own words:
Today the scap-security-guide project provides scanning only (pass/fail), in the near future we'll start working on remediation. For remediation it is envisioned that we'll be able to work together with the Aqueduct community to provide a single document (the scap-security-guide) which will contain both scanning and remediation components.
Functionally you'll deploy RHEL, run "oscap eval --profile STIG-server" and receive a report stating what actions you must take to become STIG compliant. "oscap fix --profile STIG-server" will perform the remediation(s).
Between Sept 2011 and Aug 2012 the SSG project matured greatly. One of the maturation points was the establishment of a very large body of compliance rules which could be logically organized into profiles (STIG, USGCB, NIST, etc). The vision was to have SSG become more of an "engine" -- you run a profile, and the variables of that profile (say, password length) would auto-populate into human-readable prose guides, OVAL, and remediation scripts. This vision would enable multiple groups (DoD for STIG, civilian for NIST) to collaborate in a central location for all aspects of compliance.
To accomplish that vision the bash scripts needed to be embedded inside the SSG content. There was not, nor currently is, any feasible way to link to external sources. Aqueduct decided to maintain their own bash scripts and not integrate into a consolidated prose->scanning->remediation process. And that's totally fine. But because of this decision, SSG began to embedded <fix> tags natively outside of Aqueduct. For the complete workflow to be established there wasn't any other choice.
Personally, I've long known individuals attach themselves to shared visions, shared purposes, shared callings. But I never fully appreciated this until working on the SCAP Security Guide project. As our scope expanded from compliance checking (which is, admit it, boring) to an integrated compliance workflow (which is incredibly useful and spans multiple user communities), our community exponentially expanded. Today we have some 47 code committers who have pushed an average of 50 commits per author across 226,969 lines of code [17]. Our other types of contributors, those working on documentation, reporting bugs, and working across their spheres of influence advocating the use of SSG, are incredibly hard to measure and provide metrics on. But they are there, and they are highly valued. 64.14% of SSG's commits come during 0800-1800, core business hours [18]. Not only are SSG community members working during their personal time, many employers are allowing employees to work on SSG during working hours as it provides a direct business impact. In fact, the business impact has been so overwhelming that SSG will begin shipping natively in RHEL come RHEL 6.6 [19]. Heck, there is even a community college giving homework assignments to use SSG to harden Linux machines (/how cool is that?!/) [20].
And the SCAP Security Guide project is but one under the umbrella of OpenSCAP family. A core principal of OpenSCAP is that the components and peripherals to enable enterprise SCAP usage should be open source and freely available. To us Red Hatters, that means we should ship them natively in the operating system. And the core components are (or will be shortly) shipping natively.
The OpenSCAP interpreter reflects some 4,799 commits across 46 authors and 1,414,106 lines of code [21]. Even Oracle has submitted patches to OpenSCAP [22]!
The SCAP Workbench project, which provides a GUI to using and customizing SCAP, reflects some 1,114 commits across 10 authors and 12,760 lines of code [23].
The OSCAP Anaconda Plugin, which integrates SCAP directly into RHEL's installer, reflects some 222 commits across 2 authors and 6,308 lines of code [24].
Across the 4 core projects -- OpenSCAP interpretter, SSG, Workbench, and Anaconda -- there are some 1.66 million lines of source code from nearly 80 individual contributors. And that's just the code contributors! The community is so, so much more.
All this verbosity to provide background for the following: The state of technology has allowed us to move from "compliance craftsmanship" to "compliance manufacturing." Under this vein OpenSCAP has become an empowered movement across multiple interrelated communities, all working towards the vision of a holistic workflow between prose guides, scanning engines, remediation content, and natively provided tools. This fundamental shift meant that compliance scripts must be natively integrated into the scanning technologies. A side effect of forging unified workflow meant that Aqueduct would be put in a position of integrating with SSG -- which we welcomed, and continue to welcome, with open arms! -- or, unfortunately, would be left behind as the broader community forged ahead [yes yes, I realize how "borg"-ish this sounds].
When it came to the matter of "integrate or forge ahead," and in order for progress to be made, I had to make a decision. It was to forge ahead. And I beat that drum in a very loud, outspoken manner. So yes, when it came to Red Hat contributions, I lobbied for them to be made to SSG. This was not out of malintent or anger, and certainly not about control. When talking about SSG I proudly refer to the Aqueduct as part of our lineage. I state that many of the remediation scripts originated from Aqueduct, and I talk about the DoDBastile story. I actively state that Aqueduct is a perfect place for things like Puppet, which SSG simply isn't ready for yet.
It's disheartening when you make comments insinuating that Red Hat, or any of our communities, is falling short. Upon becoming a Hatter, everyone is shown this video: http://www.redhat.com/v/ogg/stories/RHS_RedHatWay.ogg
It reflects our mission statement, which itself was developed in an open source fashion [25]:
To be the catalyst in communities of customers, contributors, and partners creating better technology the open source way.
Vince, and others in the Aqueduct community, I know my decision to forge ahead (effectively split from Aqueduct) gave you heartburn. In hindsight I can certainly identify moments where I could have been far less of, well, a dick. The decision weighed on me, and I often reflect on if I made the right one. I carry an element of personal guilt about it. Vince, I am sorry for how I handled the divergence of Aqueduct and SSG and I am sorry for any perceived role in devaluing the Aqueduct community.
But do not take it out on the community. Telling a Red Hatter they are effectively falling short on the ethos of open source is a dagger to the heart. I really can't think of a more negatively impacting statement that cuts to the core of our ideology. Such comments devalue the work of people like Simon, Jan, and Martin who are professionals that Red Hat employs and who work on OpenSCAP projects as their full time job. This is completely uncalled for.
With this long note coming to a close, it would sincerely be great to work together and re-unify. There's strength in numbers, and strength in a broad base of ideas to accomplish a goal. Constructive dialog on that would be incredibly welcome. Hope hasn't been lost for a vulcan re-unification [26]*;)
[1] https://github.com/RedHatGov/stig-fix-el6-kickstart [2] https://github.com/RedHatGov/stig-fix-el6 [3] https://github.com/RedHatGov/stig-fix-el6/blob/master/README [4] https://github.com/RedHatGov/stig-fix-el6-kickstart/blob/master/README [5] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-June/000000.htm... [6] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-June/000004.htm... [7] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-June/000012.htm... [8] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-September/00003... [9] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-November/000080... [10] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-November/000062... [11] http://www.vincentpassaro.com/2012/04/01/red-hat-summit-2012-2/ [12] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-July/000023.htm... [13] https://fedorahosted.org/aqueduct/attachment/wiki/Call/intro-SCAP-tech-talk.... [14] https://sas.elluminate.com/p.jnlp?psid=2011-07-15.0937.M.A6EDFFACF1B4203F040... [15] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-September/00003... [16] https://lists.fedorahosted.org/mailman/private/aqueduct/2012-August/000373.h... [17] http://people.redhat.com/swells/gitstats/ssg-20140904/ [18] http://people.redhat.com/swells/gitstats/ssg-20140904/activity.html [19] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6-Bet... [20] http://content.hccfl.edu/pollock/AUnixSec/Proj-C-Harden.htm [21] http://people.redhat.com/swells/gitstats/20140904-openscap/ [22] http://people.redhat.com/swells/gitstats/20140904-openscap/authors.html [23] http://people.redhat.com/swells/gitstats/20140904-scap-workbench/ [24] http://people.redhat.com/swells/gitstats/20140904-oscap-anaconda-addon/ [25] http://www.managementexchange.com/blog/how-red-hat-used-open-source-way-deve... [26] http://en.memory-alpha.org/wiki/Vulcan_reunification * I just realized I've been watching way, way to much Star Trek
+1
I was wondering what reaction this would get.
Well done and interesting commentary on one of those critical decisions in open source development.
+1
I believe that the SSG is the future for Red Hat because it maps the STIG, NIST, and other references, then maps those controls to a particular remediation, and still allows for site/project customization (Password Length, Complexity, etc.) The framework that the SSG provides can adapt to those controls (GEN, SRG, NIST [http://csrc.nist.gov/publications/nistpubs/800-53-rev4/sp800-53r4_summary.pd...]), which the mappings are getting increasingly complex and divergent in language. For example, several DISA SRG controls can be mapped satisfy a single NIST control. The mappings that SSG provides to those controls are critical to the documentation required for a classified system (Great presentation on the future of SCAP for NIST and DISA here: http://nvd.nist.gov/scap/docs/2008-conf-presentations/day1/nvd-vms-scap-inte...).
The other point that needs to be made is that it is no longer about just hardening a system a single time - it's about the continuous monitoring of that system to verify it's compliance - that is why SSG is being is being integrated and leveraged on the RHN Satellite to help monitor systems and their compliance.
All of this software is designed to be consumed by the government to help them focus less on the paperwork and more on the mission at hand - whatever that may be.
----- Original Message ----- From: "Shawn Wells" shawn.d.wells@gmail.com To: scap-security-guide@lists.fedorahosted.org Sent: Thursday, September 4, 2014 10:45:01 PM Subject: Re: Remediation advice for RHEL 5 and 6
On 9/3/14, 12:47 PM, Vincent Passaro wrote:
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.
Many Red Hat staff needed a stable, repeatable process to build a customized RHEL6 STIG installation disk. Code from Aqueduct was needed to accomplish this goal. And from the Tresys CLIP. And from SCAP Security Guide. And from some home-brew gluecode. Once these things were mashed together a installation disk was churned out in a very predictable manner, serving the purposes of those who needed the disks. People noticed the ability to generate custom, pre-STIG'd installation media and wanted to create their own. So we put the code on GitHub.
Independently tracking each underlying project and figuring out what patches/revisions from each are needed is generally to cumbersome to the average user. The stig-fix-el6-kickstart [1] and stig-fix-el6 [2] repositories are not to meant to usurp or undermine any of these communities, but rather snapshot each component and turn out an installable DVD/ISO file. This represents a very healthy upstream/downstream relationship. Every attempt was made to credit upstream sources, and you'll notice upstream sources are called out in the respective README files [3][4].
Hope this clears up the stig-fix-el6-kickstart repos. They are not an attempt at forking any project, or to build a new community. Just to organize all the subprojects in a very consumable fashion (which is to say, generate installation disks).
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. Hatters helped migrate the DoDBastile code from forge.mil into Aqueduct [5], Hatters helped create some of the first "how to use Aqueduct" videos [6], Hatters hosted the initial Aqueduct community calls [7][8][9], Hatters helped organize Aqueduct community meetups (such as before the DC Government Symposium [10]), and Hatters invited you to speak at Red Hat Summit 2012 [11].
Hatters also list Aqueduct as a project of interest off the official Red Hat Government webpage: https://www.redhat.com/en/technologies/industries/government/standards
And I personally wrote a blog on using Aqueduct to STIG a RHEL5 box (albeit, it's now somewhat outdated): http://blog-shawndwells.rhcloud.com/so-you-wanna-stig-a-rhel5-box-part2/
My prior role at Red Hat was to cover U.S. Intelligence programs. During our 2012 update to Ft Meade -- which had worldwide attendance from staffers and contractors -- I specifically called out Aqueduct. Reference p91-p96: http://blog-shawndwells.rhcloud.com/wp-content/uploads/2012/07/2012-02-08-MP...
Another Hatter called out Aqueduct at Red Hat Summit 2014 as well (ref p17): http://rhsummit.files.wordpress.com/2014/04/seifried_w_0230_cloud_security.p...
So, we should perhaps reword slightly: "A community is only as strong as it's contributors and Red Hat isn't contributing anything to Aqueduct, lately "
And lets now address that reworded statement.
On 7-JULY-2011, Hatters began briefing the Aqueduct on initiatives regarding SCAP [12][13]. Steve Grubb personally gave a webinar on the matter [14]. Then on 28-SEPT-2011, the Aqueduct community was informed the SCAP Security Guide project was starting [15]. A snippet from that original EMail:
It is designed to provide security guidance and checking content in the SCAP formats. Specifically, the project goal is to produce --- from a single body of content:
1) an informative prose guide, similar in style to NSA's RHEL 5 guide 2) a desktop settings baseline, similar in style to NIST USGCB 3) a server settings baseline, similar in style to a STIG 4) additional baselines for other network roles (such as LAMP server) 5) a body of automated checking content in the OVAL format
As reflected in the text above, SSG was initially formed to build out prose and compliance automation content. Incredibly complementary to Aqueduct, which held remediation scripts.
Almost a year later, on 1-AUG-2012, I began the conversation of linking SSG (compliance) with Aqueduct (remediation) [16]. My own words:
Today the scap-security-guide project provides scanning only (pass/fail), in the near future we'll start working on remediation. For remediation it is envisioned that we'll be able to work together with the Aqueduct community to provide a single document (the scap-security-guide) which will contain both scanning and remediation components.
Functionally you'll deploy RHEL, run "oscap eval --profile STIG-server" and receive a report stating what actions you must take to become STIG compliant. "oscap fix --profile STIG-server" will perform the remediation(s).
Between Sept 2011 and Aug 2012 the SSG project matured greatly. One of the maturation points was the establishment of a very large body of compliance rules which could be logically organized into profiles (STIG, USGCB, NIST, etc). The vision was to have SSG become more of an "engine" -- you run a profile, and the variables of that profile (say, password length) would auto-populate into human-readable prose guides, OVAL, and remediation scripts. This vision would enable multiple groups (DoD for STIG, civilian for NIST) to collaborate in a central location for all aspects of compliance.
To accomplish that vision the bash scripts needed to be embedded inside the SSG content. There was not, nor currently is, any feasible way to link to external sources. Aqueduct decided to maintain their own bash scripts and not integrate into a consolidated prose->scanning->remediation process. And that's totally fine. But because of this decision, SSG began to embedded <fix> tags natively outside of Aqueduct. For the complete workflow to be established there wasn't any other choice.
Personally, I've long known individuals attach themselves to shared visions, shared purposes, shared callings. But I never fully appreciated this until working on the SCAP Security Guide project. As our scope expanded from compliance checking (which is, admit it, boring) to an integrated compliance workflow (which is incredibly useful and spans multiple user communities), our community exponentially expanded. Today we have some 47 code committers who have pushed an average of 50 commits per author across 226,969 lines of code [17]. Our other types of contributors, those working on documentation, reporting bugs, and working across their spheres of influence advocating the use of SSG, are incredibly hard to measure and provide metrics on. But they are there, and they are highly valued. 64.14% of SSG's commits come during 0800-1800, core business hours [18]. Not only are SSG community members working during their personal time, many employers are allowing employees to work on SSG during working hours as it provides a direct business impact. In fact, the business impact has been so overwhelming that SSG will begin shipping natively in RHEL come RHEL 6.6 [19]. Heck, there is even a community college giving homework assignments to use SSG to harden Linux machines ( how cool is that?! ) [20].
And the SCAP Security Guide project is but one under the umbrella of OpenSCAP family. A core principal of OpenSCAP is that the components and peripherals to enable enterprise SCAP usage should be open source and freely available. To us Red Hatters, that means we should ship them natively in the operating system. And the core components are (or will be shortly) shipping natively.
The OpenSCAP interpreter reflects some 4,799 commits across 46 authors and 1,414,106 lines of code [21]. Even Oracle has submitted patches to OpenSCAP [22]!
The SCAP Workbench project, which provides a GUI to using and customizing SCAP, reflects some 1,114 commits across 10 authors and 12,760 lines of code [23].
The OSCAP Anaconda Plugin, which integrates SCAP directly into RHEL's installer, reflects some 222 commits across 2 authors and 6,308 lines of code [24].
Across the 4 core projects -- OpenSCAP interpretter, SSG, Workbench, and Anaconda -- there are some 1.66 million lines of source code from nearly 80 individual contributors. And that's just the code contributors! The community is so, so much more.
All this verbosity to provide background for the following: The state of technology has allowed us to move from "compliance craftsmanship" to "compliance manufacturing." Under this vein OpenSCAP has become an empowered movement across multiple interrelated communities, all working towards the vision of a holistic workflow between prose guides, scanning engines, remediation content, and natively provided tools. This fundamental shift meant that compliance scripts must be natively integrated into the scanning technologies. A side effect of forging unified workflow meant that Aqueduct would be put in a position of integrating with SSG -- which we welcomed, and continue to welcome, with open arms! -- or, unfortunately, would be left behind as the broader community forged ahead [yes yes, I realize how "borg"-ish this sounds].
When it came to the matter of "integrate or forge ahead," and in order for progress to be made, I had to make a decision. It was to forge ahead. And I beat that drum in a very loud, outspoken manner. So yes, when it came to Red Hat contributions, I lobbied for them to be made to SSG. This was not out of malintent or anger, and certainly not about control. When talking about SSG I proudly refer to the Aqueduct as part of our lineage. I state that many of the remediation scripts originated from Aqueduct, and I talk about the DoDBastile story. I actively state that Aqueduct is a perfect place for things like Puppet, which SSG simply isn't ready for yet.
It's disheartening when you make comments insinuating that Red Hat, or any of our communities, is falling short. Upon becoming a Hatter, everyone is shown this video: http://www.redhat.com/v/ogg/stories/RHS_RedHatWay.ogg
It reflects our mission statement, which itself was developed in an open source fashion [25]:
To be the catalyst in communities of customers, contributors, and partners creating better technology the open source way. Vince, and others in the Aqueduct community, I know my decision to forge ahead (effectively split from Aqueduct) gave you heartburn. In hindsight I can certainly identify moments where I could have been far less of, well, a dick. The decision weighed on me, and I often reflect on if I made the right one. I carry an element of personal guilt about it. Vince, I am sorry for how I handled the divergence of Aqueduct and SSG and I am sorry for any perceived role in devaluing the Aqueduct community.
But do not take it out on the community. Telling a Red Hatter they are effectively falling short on the ethos of open source is a dagger to the heart. I really can't think of a more negatively impacting statement that cuts to the core of our ideology. Such comments devalue the work of people like Simon, Jan, and Martin who are professionals that Red Hat employs and who work on OpenSCAP projects as their full time job. This is completely uncalled for.
With this long note coming to a close, it would sincerely be great to work together and re-unify. There's strength in numbers, and strength in a broad base of ideas to accomplish a goal. Constructive dialog on that would be incredibly welcome. Hope hasn't been lost for a vulcan re-unification [26]*;)
[1] https://github.com/RedHatGov/stig-fix-el6-kickstart [2] https://github.com/RedHatGov/stig-fix-el6 [3] https://github.com/RedHatGov/stig-fix-el6/blob/master/README [4] https://github.com/RedHatGov/stig-fix-el6-kickstart/blob/master/README [5] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-June/000000.htm... [6] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-June/000004.htm... [7] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-June/000012.htm... [8] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-September/00003... [9] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-November/000080... [10] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-November/000062... [11] http://www.vincentpassaro.com/2012/04/01/red-hat-summit-2012-2/ [12] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-July/000023.htm... [13] https://fedorahosted.org/aqueduct/attachment/wiki/Call/intro-SCAP-tech-talk.... [14] https://sas.elluminate.com/p.jnlp?psid=2011-07-15.0937.M.A6EDFFACF1B4203F040... [15] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-September/00003... [16] https://lists.fedorahosted.org/mailman/private/aqueduct/2012-August/000373.h... [17] http://people.redhat.com/swells/gitstats/ssg-20140904/ [18] http://people.redhat.com/swells/gitstats/ssg-20140904/activity.html [19] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6-Bet... [20] http://content.hccfl.edu/pollock/AUnixSec/Proj-C-Harden.htm [21] http://people.redhat.com/swells/gitstats/20140904-openscap/ [22] http://people.redhat.com/swells/gitstats/20140904-openscap/authors.html [23] http://people.redhat.com/swells/gitstats/20140904-scap-workbench/ [24] http://people.redhat.com/swells/gitstats/20140904-oscap-anaconda-addon/ [25] http://www.managementexchange.com/blog/how-red-hat-used-open-source-way-deve... [26] http://en.memory-alpha.org/wiki/Vulcan_reunification * I just realized I've been watching way, way to much Star Trek
Shawn,
I'd like to respond to several points made in your e-mail. The first, and most critical, is that one cannot watch "to (sic) much Star Trek". You should be ashamed of yourself for implying such and I'm sure your next performance report will reflect these sorts of failures.
Since we haven't met I'll simply accept your apology and admit that that part of your e-mail impressed me. Often the ones who can't apologize are the ones most needing to do so. If your behavior follows your apology then the world will be a better place.
Parts of the world, however, are crap. It seems that not enough decision-making Hatters "get" the "E" in RHEL, especially when it comes to STIG environments. If that part was graded today it would go down in flames.
SSG seems to not get the Unix philosophy of "small tools that do one thing well". When you had a scanning tool that could take criteria and identify issues it was awesome. Now it seems to be growing into a bloated mongo thing that only works with certain versions of certain products from certain vendors and only ingests certain criteria that are not related to the criteria actually used by the customer.
If you want to be successful you need to take a big step back.
1. Do not put your idea of "best practices" into the core measurement criteria. The last time I looked at this: 1.a. The criteria was not a really good practice. 1.b. The test flagged the issue as if it were equal to a STIG violation. 1.c. The test actually wasn't testing what it was said it was.
STIG environments are accredited by people that seldom have a deep knowledge of all technical areas. The STIG is the measurement, not what you think things should be like. Separate your opinions from actual criteria. Test against documented criteria.
2. Include active OS versions in the tools. 2.a. Few STIG environments are running nothing but RHEL 6 yet. If you don't deal with RHEL 5 your product is useless to your paying customers. 2.b. Almost no STIG environment is purely RHEL. If you create a mongo tool that only works on RHEL you have no value to the customer who also supports Solaris, HP/UX, and AIX. 2.c. This seems to be a RH problem as well. Upstart and systemd are bad ideas for anyone that actually works in an Enterprise, just like SMF is on Solaris. If you make an interface like chkconfig, awesome! If you have to change how you do business because some vendor can't work with a System V standard, well, maybe that vendor needs to be re-evaulated.
I firmly believe RH has the intellects and capabilities to change the Enterprise world for the better. The behavior I'm seeing says they just don't have the desire to be any more than a new flavor of has been ideas like forking, control by lock in, and exclusion.
Leam
"2.b. Almost no STIG environment is purely RHEL. If you create a mongo tool that only works on RHEL you have no value to the customer who also supports Solaris, HP/UX, and AIX."
It's RHT's responsibility to ensure availability of tools to support Solaris, HP/UX, and AIX? How?
"2.c. This seems to be a RH problem as well. Upstart and systemd are bad ideas for anyone that actually works in an Enterprise, just like SMF is on Solaris. If you make an interface like chkconfig, awesome! If you have to change how you do business because some vendor can't work with a System V standard, well, maybe that vendor needs to be re-evaulated."
RHT is far from the only vendor adopting systemd. A quick search http://en.wikipedia.org/wiki/Systemd#Adoption shows several.
On Fri, Sep 5, 2014 at 9:18 AM, leam hall leamhall@gmail.com wrote:
Shawn,
I'd like to respond to several points made in your e-mail. The first, and most critical, is that one cannot watch "to (sic) much Star Trek". You should be ashamed of yourself for implying such and I'm sure your next performance report will reflect these sorts of failures.
Since we haven't met I'll simply accept your apology and admit that that part of your e-mail impressed me. Often the ones who can't apologize are the ones most needing to do so. If your behavior follows your apology then the world will be a better place.
Parts of the world, however, are crap. It seems that not enough decision-making Hatters "get" the "E" in RHEL, especially when it comes to STIG environments. If that part was graded today it would go down in flames.
SSG seems to not get the Unix philosophy of "small tools that do one thing well". When you had a scanning tool that could take criteria and identify issues it was awesome. Now it seems to be growing into a bloated mongo thing that only works with certain versions of certain products from certain vendors and only ingests certain criteria that are not related to the criteria actually used by the customer.
If you want to be successful you need to take a big step back.
- Do not put your idea of "best practices" into the core measurement
criteria. The last time I looked at this: 1.a. The criteria was not a really good practice. 1.b. The test flagged the issue as if it were equal to a STIG violation. 1.c. The test actually wasn't testing what it was said it was.
STIG environments are accredited by people that seldom have a deep knowledge of all technical areas. The STIG is the measurement, not what you think things should be like. Separate your opinions from actual criteria. Test against documented criteria.
- Include active OS versions in the tools.
2.a. Few STIG environments are running nothing but RHEL 6 yet. If you don't deal with RHEL 5 your product is useless to your paying customers. 2.b. Almost no STIG environment is purely RHEL. If you create a mongo tool that only works on RHEL you have no value to the customer who also supports Solaris, HP/UX, and AIX. 2.c. This seems to be a RH problem as well. Upstart and systemd are bad ideas for anyone that actually works in an Enterprise, just like SMF is on Solaris. If you make an interface like chkconfig, awesome! If you have to change how you do business because some vendor can't work with a System V standard, well, maybe that vendor needs to be re-evaulated.
I firmly believe RH has the intellects and capabilities to change the Enterprise world for the better. The behavior I'm seeing says they just don't have the desire to be any more than a new flavor of has been ideas like forking, control by lock in, and exclusion.
Leam
-- Mind on a Mission -- 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/
On Fri, Sep 5, 2014 at 12:08 PM, David Smith dsmith@secure-innovations.net wrote:
It's RHT's responsibility to ensure availability of tools to support Solaris, HP/UX, and AIX? How?
Oh, of course not. Just as it's not my responsibility to champion RH in a large (20K server) environment. Or at the Wall Street Journal. Or to get RH to put it's distro cd in a book back in the '90s. Or to lobby for more RH in several places I've worked. I have done so because of loyalty to the same Open Source quality and freedom RH used to support. When tasked to find solutions it was easy to look at RH first.
If RH chooses to be just one more vendor then my options for solutions broadens greatly.
RHT is far from the only vendor adopting systemd. A quick search shows several.
Not a single non-Linux OS in the lot. Enterprises use Solaris, HP/UX, and AIX. Not sure there are thousands of Gentoo boxes in corporate datacenters.
Leam
On 9/5/14, 9:18 AM, leam hall wrote:
Shawn,
I'd like to respond to several points made in your e-mail. The first, and most critical, is that one cannot watch "to (sic) much Star Trek". You should be ashamed of yourself for implying such and I'm sure your next performance report will reflect these sorts of failures.
Hah. I've been NetFlix binging. Now on Season 7, ep 160. No spoilers please ;)
Since we haven't met I'll simply accept your apology and admit that that part of your e-mail impressed me. Often the ones who can't apologize are the ones most needing to do so. If your behavior follows your apology then the world will be a better place.
Parts of the world, however, are crap. It seems that not enough decision-making Hatters "get" the "E" in RHEL, especially when it comes to STIG environments. If that part was graded today it would go down in flames.
In the past, Red Hat STIGs have certainly been rather haphazard. I'd argue one cause was lack of community in their development. There was to much disjointedness between those who wrote the STIGs and those who had to implement them. Also, Red Hat itself wasn't fully engaged which lead to support issues when deployments would call Red Hat for support.
These two issues -- community consensus on what should be in a STIG, and how to properly support the baseline at the Vendor level -- became raised at very high levels within industry and government.
DISA FSO did their part by forming the Vendor STIG process. Classically DISA FSO would develop a STIG on their own, and because technology turnover rates are so high, FSO was constantly behind on publishing STIGs. Under the new Vendor STIG process FSO effectively hands over STIG creation to the vendors. Vendors have free realm to develop the STIGs however they wish (as long as SRG requirements are fully met). Once complete, Vendors hand over a formal package to FSO for their review and final approval before an official STIG is published.
On the Red Hat side, to address the community and support issues, we partnered with NSA IAD to form the SCAP Security Guide project. The charter was to create a large body of security controls from which a STIG could be derived. I recall the initial meeting was Jeff Blank, Trevor Vaughan, Mark St. Laurent, Dave Smith, Maura Daily, myself, though it was ~3yrs ago and I may be mistaken. While the origins were small, I would argue the community has grown into something amazing. Contributions range from agencies such as NIST, NSA, FBI, Oak Ridge, NRO, NASA, and industry partners like Lockheed Martin, Harris, and Secure Innovations. The establishment of community has helped connect the "policy makers" to the "policy consumers" in a single project. Hopefully this collaboration will drive enterprise-ready baselines (and in many ways, I think it has).
The formation of community is no trivial task and security compliance efforts have incredible visibility at Red Hat. It's no secret that part of my formal job is to manage U.S. Government compliance baselines, but I don't know if where I fall organizationally is widely known. To give you an idea, here is screenshot of my reporting chain:
I share only to demonstrate:
(1) According to Red Hat's investor relations report from 31-MAY-2014 [1], Red Hat has some 6,500 employees. My participation reflects full support at a level three tiers below the CEO; (2) Red Hat's compliance efforts are organizationally backed by Vice Presidents and General Managers. If something can't be accomplished at my level, the immediate escalation path is to Lynne (my boss, a Vice President) or to Paul (the General Manager of Red Hat Federal);
Hopefully this clears up concerns that Red Hat doesn't have decision-making staff focused on security compliance. There's also support of a wide network of influencers, ranging from the Chief Architect of Red Hat Federal (Dave Egts) to Steve Grubb (Leads Security Engineering), etc.
Concerns and comments relating to Red Hat's processes and overall support for compliance initiatives get equally high levels of attention, and we take feedback very seriously.
SSG seems to not get the Unix philosophy of "small tools that do one thing well". When you had a scanning tool that could take criteria and identify issues it was awesome. Now it seems to be growing into a bloated mongo thing that only works with certain versions of certain products from certain vendors and only ingests certain criteria that are not related to the criteria actually used by the customer.
I share the mindset of small functional tools, which is why OpenSCAP was broken into parts:
- OpenSCAP interpreter, now a NIST certified scanner [2], that can parse any source of valid SCAP content, not just SSG. While I'm not intimately familiar with the details, other communities have began building OpenSCAP interpreter for their platforms. Ubuntu's last build appears to be 27-AUG-2014 [3].
- SCAP Workbench, an optional GUI tool to scan and manipulate SCAP content. The last build was just today.
- SCAP Security Guide: A framework for developing SCAP guidance for specific technologies. Yes, today content exists for primarily Red Hat technologies, however just last week I had a conversation on how a 3rd party could start contributing nginx or ElasticSearch SCAP content.
Functional limitations -- "certain versions of certain products from certain vendors" -- are limited only by the available body of SCAP content. This has nothing to do with OpenSCAP itself.
If you want to be successful you need to take a big step back.
- Do not put your idea of "best practices" into the core measurement
criteria. The last time I looked at this: 1.a. The criteria was not a really good practice.
SSG content reflects a large body of checks from several agencies, industry, academic partners, and Red Hat proper.
When forming an official baseline, such as the RHEL 6 STIG, we hold "consensus calls" to take feedback from the various stakeholder communities. The RHEL 6 call was on 25-OCT-2012, and the Aqueduct community was invited: https://lists.fedorahosted.org/mailman/private/aqueduct/2012-October/000418....
It's unlikely that we'll be able to appease every individual stakeholder. Well reasoned arguments for/against a rule should be submitted to the mailing list for discussion, and patches are most welcome.
1.b. The test flagged the issue as if it were equal to a STIG violation.
Well, since SSG is the upstream of Red Hat's STIGs, it's likely that it *is* a violation. Review section 1.1 of the STIG Overview from DISA [4]:
The consensus content was developed using an open-source project called SCAP Security Guide. The project’s website is https://fedorahosted.org/scap-security-guide/. Except for differences in formatting to accommodate the DISA STIG publishing process, the content of the RHEL6 STIG should mirror the SCAP Security Guide content with only minor divergence as updates from multiple sources work through the consensus process.
In reality this divergence is a bit more pronounced. We didn't expect SSG to take off like it did (not that it's such a bad thing!)
1.c. The test actually wasn't testing what it was said it was.
I get the impression this view is historical, so I'd invite another review of the content to see if the comments on good practice and false positives hold true today. There are most definitely bugs though, and as you find them, it'd be great if you could open a ticket:
https://github.com/OpenSCAP/scap-security-guide/issues
Fixes make their way into RHEL, and for any effecting the STIG baseline, make their way into the content off iase.disa.mil. SSG represents the democratization of the STIG -- the more feedback the better.
STIG environments are accredited by people that seldom have a deep knowledge of all technical areas. The STIG is the measurement, not what you think things should be like. Separate your opinions from actual criteria. Test against documented criteria.
- Include active OS versions in the tools.
2.a. Few STIG environments are running nothing but RHEL 6 yet. If you don't deal with RHEL 5 your product is useless to your paying customers.
The OpenSCAP scanner is certified by NIST and is provided natively on RHEL5+.
$ sudo yum install openscap-utils
Creating RHEL 6 content was an easy choice. It's the latest release, and new technologies (e.g. OpenStack) are layered on top. RHEL 6 content was foundational for those needing baremetal and VM-level deployments, and serves as a catalyst for future Docker and OpenStack STIGs.
Today RHEL 5 content can be downloaded from DISA: http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx or directly @ http://iasecontent.disa.mil/stigs/zip/u_redhat_5_v1r8_benchmark.zip
RHEL 5 content can also be found from NIST: http://usgcb.nist.gov/usgcb/rhel/download_rhel5.html
So then, in terms of SSG providing RHEL 5 content: The initial was no way. RHEL 5 is in "Production 3 Phase" which is defined as [5]:
During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available. Other errata advisories may be delivered as appropriate.
New functionality and new hardware enablement are not planned for availability in the Production 3 Phase. Minor releases with updated installation images may be made available in this Phase.
Generating SSG content is nontrivial and takes considerable time to make reputable content. RHEL 5 is scheduled for EOL on 31-MAR-2017 [5]. The time investment for a product that EOL's in a few years isn't worth it. And even if we did develop content, RHEL 5 is to far along in its lifecycle to add new RPM packages. We couldn't ship it to customers.
With that said, the USGCB content is effectively abandoned and needs a home. There's talk about importing the RHEL5 USGCB content into SSG to give it a home. This would allow those who care about/need RHEL5 SCAP content to build off the RHEL5 USGCB. If this is important to you (you the reader, not just Leam) then please +1 on the list.
2.b. Almost no STIG environment is purely RHEL. If you create a mongo tool that only works on RHEL you have no value to the customer who also supports Solaris, HP/UX, and AIX.
Ultimately adding SCAP functionality to an operating system is the OS vendor's responsibility. If SCAP functionality is needed on HP/UX, AIX, etc I suggest contacting your OS vendor rep. SCAP is an international standard, so I'd be surprised if they don't provide SCAP interpreters.
Note that OpenSCAP is open source and porting to other platforms would be most welcome. As mentioned above, it appears other Linux distros may be working on this [3].
2.c. This seems to be a RH problem as well. Upstart and systemd are bad ideas for anyone that actually works in an Enterprise, just like SMF is on Solaris. If you make an interface like chkconfig, awesome! If you have to change how you do business because some vendor can't work with a System V standard, well, maybe that vendor needs to be re-evaulated.
This is total troll bait.
I firmly believe RH has the intellects and capabilities to change the Enterprise world for the better. The behavior I'm seeing says they just don't have the desire to be any more than a new flavor of has been ideas like forking, control by lock in, and exclusion.
[1] http://investors.redhat.com/faq.cfm [2] http://investors.redhat.com/releasedetail.cfm?ReleaseID=843440 [3] https://launchpad.net/ubuntu/+source/openscap [4] http://people.redhat.com/swells/rhel6stig/U_RedHat_6_V1R1_Overview.pdf [5] https://access.redhat.com/support/policy/updates/errata
First of let me say that the statement was not intended to insult any of the contributors such as Simon, Jan, Martin, and so many others on different projects. Their work in other SCAP related projects has been absolutely phenomenal. This thread is about Aqueduct and Red Hat's role in that project as a developer and user.
There is no disputing Red Hat has been a voice for the Aqueduct project since the beginning. But Linux, OpenSCAP, SSG, RHEL, Docker, and thousands of other Open Source projects were not built by blogs, presentations and podcasts alone. It was built with a community - a community contributing code. Something we all (Red Hat included) take great pride in (http://www.redhat.com/infographics/openstack/).
Shawn, you had a tough decision to make and you made it. Being an Open Source community leader isn’t easy and isn’t always fun. As leaders in the community we often have to remember that “the needs of the many outweigh the needs of the few” *Star Trek*.
At the time when you made the decision to push forward with remediation inside SSG Aqueduct code base was too large for the bash one-liners restriction in SSG. Aqueduct community understood the decision, even if it caused a little heartburn Aqueduct stood by SSG. But then ‘hatters’ used Aqueduct code to answer a problem Red Hat has for their professional services team with no contributions back into Aqueduct.
Actions need to align with the decisions and the code speaks for itself.
Aqueduct_GIT ---$ grep -rai '@redhat.com' *
aqueduct.spec:* Mon Sep 10 2012 Ted Brunell tbrunell@redhat.com
aqueduct.spec:* Tue May 4 2012 Ted Brunell tbrunell@redhat.com
Looking at the Aqueduct code there are 29,136 lines. A quick search for Red Hat contributions (see above). The basis for this search is that a Red Hat email is tied to the Copy Right or email (as seen in rhel-stig-fix). I excluded findings for generic emails such as security@redhat.com.
A git log yields no Red Hat contributions.
The community was fully aware of Red Hat’s position on Aqueduct being a separate project as Red Hat wanted SSG to be the source of remediation content within the <fix> tag statement. Aqueduct wasn’t able to fit this model simply due to the size (line count) of the Aqueduct scripts. Aqueduct needed more code to conduct remediation properly and the consensus was that ‘bash one liners’ were the most viable candidates for <fix> tags. As no other language support existed in the SCAP framework, non-bash languages in Aqueduct such as Puppet and Ansible would be completely unfeasible to ingest, both near and far term [1]. This is why the government pushed Puppet content into Aqueduct (Thank you Maura).
Conversations around linking of SCAP content to external sources was discussed and favored by a number of different sources (Red Hat & Non-Red Hat) [2] [5.1]. Non-Red Hat & Red Hat people even agreed that linking remediation content to SCAP content would be feasible [4-5]. Other contributors voiced concerns of SCAP remediation language openly in the community and decided to push content into Aqueduct [5.1].
The Aqueduct community has stood by SSG and assisted as much as possible. We even hosted a call specifically to help SSG meet their submission deadline of the RHEL 5 SCAP content [6].
Thanks for the how-to guide [3]. P.S. You have a 404 link broken to one of the Aqueduct postings [7] :( .
Credit where credit is due, Aaron Prayther contributed that code in Aqueduct [8] [9].
Just as the comments previously in the thread are as you put it ‘a dagger to the heart’ of hatters, it is the same dagger to the heart of an open source community watch an organization champion the project, leverage its code to solve its own problems, while not contributing back into the project. As Open Source community leaders this is not the example we want to set.
[1] https://lists.fedorahosted.org/mailman/private/aqueduct/2012-August/000384.h...
[2] https://lists.fedorahosted.org/pipermail/scap-security-guide/2012-September/...
[3] http://blog-shawndwells.rhcloud.com/so-you-wanna-stig-a-rhel5-box-part2/
[4] https://lists.fedorahosted.org/pipermail/scap-security-guide/2012-September/...
[5] https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-March/0028...
[5.1] https://lists.fedorahosted.org/mailman/private/aqueduct/2012-August/000375.h...
[6] https://fedorahosted.org/aqueduct/attachment/wiki/Call/Aqueduct_8-10-2012.mp...
[7] http://blog-shawndwells.rhcloud.com/2012/10/so-you-wanna-stig-a-rhel5-box-pa...
[8] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-June/000003.htm...
[9] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-June/000002.htm...
5 PM, Shawn Wells shawn.d.wells@gmail.com wrote:
On 9/3/14, 12:47 PM, Vincent Passaro wrote:
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.
Many Red Hat staff needed a stable, repeatable process to build a customized RHEL6 STIG installation disk. Code from Aqueduct was needed to accomplish this goal. And from the Tresys CLIP. And from SCAP Security Guide. And from some home-brew gluecode. Once these things were mashed together a installation disk was churned out in a very predictable manner, serving the purposes of those who needed the disks. People noticed the ability to generate custom, pre-STIG'd installation media and wanted to create their own. So we put the code on GitHub.
Independently tracking each underlying project and figuring out what patches/revisions from each are needed is generally to cumbersome to the average user. The stig-fix-el6-kickstart [1] and stig-fix-el6 [2] repositories are not to meant to usurp or undermine any of these communities, but rather snapshot each component and turn out an installable DVD/ISO file. This represents a very healthy upstream/downstream relationship. Every attempt was made to credit upstream sources, and you'll notice upstream sources are called out in the respective README files [3][4].
Hope this clears up the stig-fix-el6-kickstart repos. They are not an attempt at forking any project, or to build a new community. Just to organize all the subprojects in a very consumable fashion (which is to say, generate installation disks).
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.
Hatters helped migrate the DoDBastile code from forge.mil into Aqueduct [5], Hatters helped create some of the first "how to use Aqueduct" videos [6], Hatters hosted the initial Aqueduct community calls [7][8][9], Hatters helped organize Aqueduct community meetups (such as before the DC Government Symposium [10]), and Hatters invited you to speak at Red Hat Summit 2012 [11].
Hatters also list Aqueduct as a project of interest off the official Red Hat Government webpage: https://www.redhat.com/en/technologies/industries/government/standards
And I personally wrote a blog on using Aqueduct to STIG a RHEL5 box (albeit, it's now somewhat outdated): http://blog-shawndwells.rhcloud.com/so-you-wanna-stig-a-rhel5-box-part2/
My prior role at Red Hat was to cover U.S. Intelligence programs. During our 2012 update to Ft Meade -- which had worldwide attendance from staffers and contractors -- I specifically called out Aqueduct. Reference p91-p96: http://blog-shawndwells.rhcloud.com/wp-content/uploads/2012/07/2012-02-08-MP...
Another Hatter called out Aqueduct at Red Hat Summit 2014 as well (ref p17): http://rhsummit.files.wordpress.com/2014/04/seifried_w_0230_cloud_security.p...
So, we should perhaps reword slightly: "A community is only as strong as it's contributors and Red Hat isn't contributing anything to Aqueduct, lately"
And lets now address that reworded statement.
On 7-JULY-2011, Hatters began briefing the Aqueduct on initiatives regarding SCAP [12][13]. Steve Grubb personally gave a webinar on the matter [14]. Then on 28-SEPT-2011, the Aqueduct community was informed the SCAP Security Guide project was starting [15]. A snippet from that original EMail:
It is designed to provide security guidance and checking content in the SCAP formats. Specifically, the project goal is to produce --- from a single body of content:
- an informative prose guide, similar in style to NSA's RHEL 5 guide
- a desktop settings baseline, similar in style to NIST USGCB
- a server settings baseline, similar in style to a STIG
- additional baselines for other network roles (such as LAMP server)
- a body of automated checking content in the OVAL format
As reflected in the text above, SSG was initially formed to build out prose and compliance automation content. Incredibly complementary to Aqueduct, which held remediation scripts.
Almost a year later, on 1-AUG-2012, I began the conversation of linking SSG (compliance) with Aqueduct (remediation) [16]. My own words:
Today the scap-security-guide project provides scanning only (pass/fail), in the near future we'll start working on remediation. For remediation it is envisioned that we'll be able to work together with the Aqueduct community to provide a single document (the scap-security-guide) which will contain both scanning and remediation components.
Functionally you'll deploy RHEL, run "oscap eval --profile STIG-server" and receive a report stating what actions you must take to become STIG compliant. "oscap fix --profile STIG-server" will perform the remediation(s).
Between Sept 2011 and Aug 2012 the SSG project matured greatly. One of the maturation points was the establishment of a very large body of compliance rules which could be logically organized into profiles (STIG, USGCB, NIST, etc). The vision was to have SSG become more of an "engine" -- you run a profile, and the variables of that profile (say, password length) would auto-populate into human-readable prose guides, OVAL, and remediation scripts. This vision would enable multiple groups (DoD for STIG, civilian for NIST) to collaborate in a central location for all aspects of compliance.
To accomplish that vision the bash scripts needed to be embedded inside the SSG content. There was not, nor currently is, any feasible way to link to external sources. Aqueduct decided to maintain their own bash scripts and not integrate into a consolidated prose->scanning->remediation process. And that's totally fine. But because of this decision, SSG began to embedded <fix> tags natively outside of Aqueduct. For the complete workflow to be established there wasn't any other choice.
Personally, I've long known individuals attach themselves to shared visions, shared purposes, shared callings. But I never fully appreciated this until working on the SCAP Security Guide project. As our scope expanded from compliance checking (which is, admit it, boring) to an integrated compliance workflow (which is incredibly useful and spans multiple user communities), our community exponentially expanded. Today we have some 47 code committers who have pushed an average of 50 commits per author across 226,969 lines of code [17]. Our other types of contributors, those working on documentation, reporting bugs, and working across their spheres of influence advocating the use of SSG, are incredibly hard to measure and provide metrics on. But they are there, and they are highly valued. 64.14% of SSG's commits come during 0800-1800, core business hours [18]. Not only are SSG community members working during their personal time, many employers are allowing employees to work on SSG during working hours as it provides a direct business impact. In fact, the business impact has been so overwhelming that SSG will begin shipping natively in RHEL come RHEL 6.6 [19]. Heck, there is even a community college giving homework assignments to use SSG to harden Linux machines (how cool is that?!) [20].
And the SCAP Security Guide project is but one under the umbrella of OpenSCAP family. A core principal of OpenSCAP is that the components and peripherals to enable enterprise SCAP usage should be open source and freely available. To us Red Hatters, that means we should ship them natively in the operating system. And the core components are (or will be shortly) shipping natively.
The OpenSCAP interpreter reflects some 4,799 commits across 46 authors and 1,414,106 lines of code [21]. Even Oracle has submitted patches to OpenSCAP [22]!
The SCAP Workbench project, which provides a GUI to using and customizing SCAP, reflects some 1,114 commits across 10 authors and 12,760 lines of code [23].
The OSCAP Anaconda Plugin, which integrates SCAP directly into RHEL's installer, reflects some 222 commits across 2 authors and 6,308 lines of code [24].
Across the 4 core projects -- OpenSCAP interpretter, SSG, Workbench, and Anaconda -- there are some 1.66 million lines of source code from nearly 80 individual contributors. And that's just the code contributors! The community is so, so much more.
All this verbosity to provide background for the following: The state of technology has allowed us to move from "compliance craftsmanship" to "compliance manufacturing." Under this vein OpenSCAP has become an empowered movement across multiple interrelated communities, all working towards the vision of a holistic workflow between prose guides, scanning engines, remediation content, and natively provided tools. This fundamental shift meant that compliance scripts must be natively integrated into the scanning technologies. A side effect of forging unified workflow meant that Aqueduct would be put in a position of integrating with SSG -- which we welcomed, and continue to welcome, with open arms! -- or, unfortunately, would be left behind as the broader community forged ahead [yes yes, I realize how "borg"-ish this sounds].
When it came to the matter of "integrate or forge ahead," and in order for progress to be made, I had to make a decision. It was to forge ahead. And I beat that drum in a very loud, outspoken manner. So yes, when it came to Red Hat contributions, I lobbied for them to be made to SSG. This was not out of malintent or anger, and certainly not about control. When talking about SSG I proudly refer to the Aqueduct as part of our lineage. I state that many of the remediation scripts originated from Aqueduct, and I talk about the DoDBastile story. I actively state that Aqueduct is a perfect place for things like Puppet, which SSG simply isn't ready for yet.
It's disheartening when you make comments insinuating that Red Hat, or any of our communities, is falling short. Upon becoming a Hatter, everyone is shown this video: http://www.redhat.com/v/ogg/stories/RHS_RedHatWay.ogg
It reflects our mission statement, which itself was developed in an open source fashion [25]:
To be the catalyst in communities of customers, contributors, and partners creating better technology the open source way.
Vince, and others in the Aqueduct community, I know my decision to forge ahead (effectively split from Aqueduct) gave you heartburn. In hindsight I can certainly identify moments where I could have been far less of, well, a dick. The decision weighed on me, and I often reflect on if I made the right one. I carry an element of personal guilt about it. Vince, I am sorry for how I handled the divergence of Aqueduct and SSG and I am sorry for any perceived role in devaluing the Aqueduct community.
But do not take it out on the community. Telling a Red Hatter they are effectively falling short on the ethos of open source is a dagger to the heart. I really can't think of a more negatively impacting statement that cuts to the core of our ideology. Such comments devalue the work of people like Simon, Jan, and Martin who are professionals that Red Hat employs and who work on OpenSCAP projects as their full time job. This is completely uncalled for.
With this long note coming to a close, it would sincerely be great to work together and re-unify. There's strength in numbers, and strength in a broad base of ideas to accomplish a goal. Constructive dialog on that would be incredibly welcome. Hope hasn't been lost for a vulcan re-unification [26]*;)
[1] https://github.com/RedHatGov/stig-fix-el6-kickstart [2] https://github.com/RedHatGov/stig-fix-el6 [3] https://github.com/RedHatGov/stig-fix-el6/blob/master/README [4] https://github.com/RedHatGov/stig-fix-el6-kickstart/blob/master/README [5] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-June/000000.htm... [6] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-June/000004.htm... [7] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-June/000012.htm... [8] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-September/00003... [9] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-November/000080... [10] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-November/000062... [11] http://www.vincentpassaro.com/2012/04/01/red-hat-summit-2012-2/ [12] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-July/000023.htm... [13] https://fedorahosted.org/aqueduct/attachment/wiki/Call/intro-SCAP-tech-talk.... [14] https://sas.elluminate.com/p.jnlp?psid=2011-07-15.0937.M.A6EDFFACF1B4203F040... [15] https://lists.fedorahosted.org/mailman/private/aqueduct/2011-September/00003... [16] https://lists.fedorahosted.org/mailman/private/aqueduct/2012-August/000373.h... [17] http://people.redhat.com/swells/gitstats/ssg-20140904/ [18] http://people.redhat.com/swells/gitstats/ssg-20140904/activity.html [19] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6-Bet... [20] http://content.hccfl.edu/pollock/AUnixSec/Proj-C-Harden.htm [21] http://people.redhat.com/swells/gitstats/20140904-openscap/ [22] http://people.redhat.com/swells/gitstats/20140904-openscap/authors.html [23] http://people.redhat.com/swells/gitstats/20140904-scap-workbench/ [24] http://people.redhat.com/swells/gitstats/20140904-oscap-anaconda-addon/ [25] http://www.managementexchange.com/blog/how-red-hat-used-open-source-way-deve... [26] http://en.memory-alpha.org/wiki/Vulcan_reunification
- I just realized I've been watching way, way to much Star Trek
-- 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/
On 09/05/2014 12:43 PM, Shawn Wells wrote:
On 9/4/14, 1:08 PM, Philip Shuman wrote:
Thanks for all the input!
Probably a bit more than you asked for, huh?
Welcome to open source ;)
I'd rather get that over chirping crickets!
I have our install to 95% passing with the SCC tool and have some aqueduct updates I'll send over to Vincent.
Thanks! Philip
Philip,
Excellent news! I’m glad to hear Aqueduct was a success and we look forward to the contributions.
Please let me know if you have any questions or help on submitting patches.
Thx,
V
On Sep 7, 2014, at 5:35 PM, Philip Shuman philip.shuman@sri.com wrote:
On 09/05/2014 12:43 PM, Shawn Wells wrote:
On 9/4/14, 1:08 PM, Philip Shuman wrote:
Thanks for all the input!
Probably a bit more than you asked for, huh?
Welcome to open source ;)
I'd rather get that over chirping crickets!
I have our install to 95% passing with the SCC tool and have some aqueduct updates I'll send over to Vincent.
Thanks! Philip
-- Philip Shuman Software Engineer SRI International 805-542-9330 x115
-- 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@lists.fedorahosted.org
-
Andrew Gilmore -
David Smith -
Frank Caviggia -
leam hall -
Philip Shuman -
Robert Sanders -
Shawn Wells -
Shawn Wells -
Vincent Passaro