Shawn, Really interesting points.
Can you also speak to Fedora vs RHEL and why Fedora is included? I think a CentOs generic is a smart approach. Greg Greg Elin P: 917-304-3488 E: grege...@gitmachines.com Sent from my iPhone > On Aug 15, 2014, at 4:57 PM, Shawn Wells <sh...@redhat.com> wrote: > >> On 8/15/14, 3:59 PM, Greg Elin wrote: >> Thanks everyone for contributing to this thread. It's been very helpful. >> >> I have had a few draft replies, but let me try to keep things short. >> >> Many of the contributions address altering the files in the source >> Scap-security-guide repo. It would be great to have an upstream resolution >> so those installing OpenSCAP and SSG can do so via RPM (or repo) and >> confidently work across Fedora, RedHat, and CentOS. (Separating CentOS >> seems might have some nuances to consider because often us users substitute >> CentOS for RedHat and we may want to see "RedHat" showing up in results.) >> >> I am still interested in how to fix the issue with the files I have >> installed via RPMs. I'm a little weak still on the whole build thing to be >> honest. But more importantly, I *want* to be aligned with what is being >> distributed. I want to have GovReady install OpenSCAP and SSG and then use >> it. I'm reluctant to fork the source SSG. >> >> So with that in mind, I got this working. I added a new >> centos6-cpe-dictionary.xml file and centos6-cpe-oval.xml file. The cpe >> dictionary can be referenced in oscap command line and it points to the >> correct centos6-cpe-oval.xml file that has a modified test for CentOS. >> >> The changes that needed to be made seem to come down to changing >> `redhat-release-server` (and/or `redhat-release-workstation`) to >> `centos-release` and changing the pattern match on the version from >> `^6\.\d+$ > > > You're entirely correct that technical enablement is trivial. It comes > to the issue of Common Criteria certification. The common criteria > process validates software lifecycle practices, that security > functionality performs as advertised, that a piece of software can be > trusted for deployment on government systems. > > A colleague of mine, Gunnar Hellekson, wrote a great common criteria primer: > http://atechnologyjobisnoexcuse.com/2011/12/a-common-criteria-primer/ > > Read it -- really -- it'll give some background to the conversation. > > As noted in the blog, US Gov policy mandates that software be common > criteria certified. There's no exception. If software you want to use is > not common criteria certified, you contractually obligate your vendor to > certify under a relevant protection profile. There's no provision for > something that isn't certified. > > CentOS has never undergone common criteria, has no government > certifications (e.g. FIPS), no support, no security patches, no CVE/IAVA > mappings, and there no plans for these things. In studies of CentOS vs > RHEL by IAD, some 1/3 of the core binaries are different. CentOS != > RHEL. The two can not be used interchangeably in government environments. > > And relating to the DoD/IC community: due to lack of certifications, the > DoD CIO and DISA FSO have not signed off on CentOS. That's why there is > no STIG for CentOS. This is why the CPE checks are enabled within SSG > content. CentOS simply isn't an approved operating system. > > As others have pointed out, DAAs can of course authorize waivers to do > whatever they want. Many DAAs chose to violate the common criteria > mandate, and unfortunately, there's no true repercussions for doing so. > As DAA, they have the authority to accept risk. > > To educate DAAs on the risks taken during CentOS deployments, NSA IAD > performed a binary analysis of CentOS6 and RHEL6. They found ~1/3 of > binary packages between the two distros are different, and because of so > many changes, IAD stated that inferring and understanding what changed > was infeasible. How is a DAA supposed to make an informed risk decision > on the use of CentOS when there are so many changes that IAD finds > proper analysis infeasible? > > But policies are policies, not law. DAAs are certainly able to break > policies, but by using unsupported and uncertified software, must be > prepared to staff, fund, and develop on their own any missing gaps. > > And besides, if one chooses to use a completely untrusted operating > system, why even both to harden it? > > <<takes deep breath>> > > Enabling CentOS on the existing profiles (stig, usgcb, c2s, cs2) is > counter intuitive, as they're formal government baselines that do > require a common criteria certified OS as part of their requirement set. > Perhaps establishing a new profile, e.g. "centos-generic," even if it > just inherits the RHEL6 STIG and disables the platform checking, would > be decent compromise. Rules that deal with certain things, like crypto, > would still need to fail as CentOS doesn't have FIPS.... but it could be > a start. > -- > 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/
