Great stuff!

On Fri, Aug 15, 2014 at 5:08 PM, Shawn Wells <> wrote:
- 11331(b) make following FISMA or NSTISSP mandatory

So, lets hop over to NIST 800-53:

Skip allllll the way to PDF pg 108, "Table D-2: Security Control
Baselines," and you'll see the Low/Mod/High impact levels and what
controls you have to meet at each one.

Ok, we're in territory I recognize here.

Relating to the CentOS discussion, the IA-7 controls are interesting.
They state:
> The information system implements mechanisms for authentication to a cryptographic
> module that meet the requirements of applicable federal laws, Executive Orders, directives,
> policies, regulations, standards, and guidance for such authentication

The "that meet requirements of applicable federal laws... policies..
standards" bit refers to FIPS 140-2 certification. Which CentOS doesn't

Ok, this one is applicable to all impact levels, and CentOS doesn't have the certifications. I got that.

Another goodie, SA-4(6), "Acquisition Process | Use of Information
Assurance Products", which reads:
And then SA-4(7), "Acquisition Process | NIAP-Approved Protection
Profiles," which reads:

These two are only applicable for "enhanced assurance", and are not selected even at the "High" impact level. I'd assume that this is where the national security systems deviate from the FISMA-compliant, lower impact set.

But again, agencies must elect to follow these controls and standards.
DAAs can certainly waiver them -- and in the case of wherever CentOS is
being deployed -- they have (you're not running CentOS without the
knowledge of your CISO/DAA, right?).

Nope, I'm running Red Hat. I've heard of others in my organization running and recommending CentOS, so this is very helpful. I don't hear much about the accreditation process for those systems. Is it just the FIPS certifications, or is there more involved with a "Medium" or "Low" impact system?

CentOS isn't the devil, though. It provides a nice middleground between
bleeding-edge Fedora and 10yr stable RHEL. When it comes to government
systems though, I fail to see any place for CentOS.

I've heard similar arguments from Oracle reps about Postgres. :-) And people still run both CentOS and Postgres cause they're "free" and good enough.  I'm much fonder of Red Hat than Oracle though. I run Oracle cause I inherited it.

 I do think that RHT is missing the boat here, although I have yet to investigate what's recently been happening in CentOS and on the Desktop. Gnome 3 has been disastrous, and just when a solid Desktop entry could have jumped into the void between WinXP and Win7. Sad.

And for those who argue "we don't need RHEL for just development!":
- Even development systems must follow Information Assurance guidelines
spoken about above. And ok, fine, internal environments at System
Integrators are not specifically called out for these regulations...
however many contracts do require integrators to follow the same
standards as government systems;

- CentOS isn't RHEL. If you dev/test on CentOS, you'll need to
completely retest on RHEL. Two different OS'

I think RHT needs to carefully consider what the purpose/audience for CentOS is. I'm hearing about Ubuntu on the server more and more, and this is a feature they trumpet.

- If you throw out the economic argument ("it's just dev! i can't double
my RHEL costs for dev!"), then I'll gladly volunteer to find out who
your RHT Rep is... they'd love to work the economics out with you. And
besides, most RHEL subscriptions come with unlimited VMs per hypervisor
these days anyway. Doesn't care if it's dev/test/prod.

My subscriptions are all 1 supported VM. Not that I'm using it, currently. I'm also not all that enamored of running databases in VMs, but I'm considering moving that direction.