Interesting article and discussion. Both that blog and www.niap-ccevs.org site seems to apply specifically to "national security systems". I get why the procurement requirements are more stringent in that world, but you seem to imply that these requirements are binding on every federal IT purchase. Why? I don't want any classified or even sensitive data on my systems, so why are the purchasing requirements the same?
I am also curious why 1/3 of the CentOS binaries are different. On Fri, Aug 15, 2014 at 2: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/
