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/
