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 <shawn(a)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
> 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
> 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
> 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
> 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
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
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
SCAP Security Guide mailing list