On 8/15/14, 5:44 PM, Andrew Gilmore wrote:
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?
Just noticed the link in Gunnar's blog was dead. Here's the updated one:
And here's the definition of "What is a National Security System?":
Ultimately, for both DoD/IC and civilian, boil down to the Federal
Information Systems Management Act of 2002 (FISMA). This actually is a
*law*, and you can get a copy here:
Skip to PDF pg58, "$11331. Responsibilities for Federal information
- 11331(a)(1) gives NIST the power to prescribe standards and guidelines
pertaining to Federal information systems. This is generally referred to
as FISMA compliance.
- 11331(a)(2) defers to the president to figure out what to do for
"national security systems." That's what Presidential Decision Directive
(PDD-63) is all about, which ultimately created the NSTISSP. History @
- 11331(b) make following FISMA or NSTISSP mandatory
So then, on the civilian side, the Department of Commerce released
Federal Information Processing Standards 200 (FIPS-200), which is the
"Minimum Security Requirements for Federal Information and Information
Systems." You can find a copy here:
An exert from Section 1:
The E-Government Act of 2002 (Public Law 107-347), passed by the one
hundred and seventh
Congress and signed into law by the President in December 2002, recognized the importance
information security to the economic and national security interests of the United
States. Title III of
the E-Government Act, entitled the Federal Information Security Management Act (FISMA) of
tasked NIST with the responsibility of developing security standards and guidelines for
government including the development of:
• Standards for categorizing information and information systems collected or maintained
or on behalf of each federal agency based on the objectives of providing appropriate
information security according to a range of risk levels;
• Guidelines recommending the types of information and information systems to be included
each category; and
• Minimum information security requirements for information and information systems in
The document then spells out impact levels (Section 2), and tells you to
go look at NIST 800-53 for the actual, specific controls to implement
once you have an impact level decision (Section 4).
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.
Relating to the CentOS discussion, the IA-7 controls are interesting.
The information system implements mechanisms for authentication to a
module that meet the requirements of applicable federal laws, Executive Orders,
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
Another goodie, SA-4(6), "Acquisition Process | Use of Information
Assurance Products", which reads:
(a) Employs only government off-the-shelf (GOTS) or commercial off-the-shelf (COTS)
information assurance (IA) and IA-enabled information technology products that compose an
NSA-approved solution to protect classified information when the networks used to
the information are at a lower classification level than the information being
(b) Ensures that these products hav
And then SA-4(7), "Acquisition Process | NIAP-Approved Protection
Profiles," which reads:
(a) Limits the use of commercially provided information assurance (IA) and IA-enabled
information technology products to those products that have been successfully evaluated
against a National Information Assurance partnership (NIAP)-approved Protection Profile
specific technology type, if such a profile exists; and
(b) Requires, if no NIAP-approved Protection Profile exists for a specific technology
type but a
commercially provided information technology product relies on cryptographic
to enforce its security policy, that the cryptographic module is FIPS-validated.
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?).
I am also curious why 1/3 of the CentOS binaries are different.
From "How is CentOS different from Red Hat Enterprise
While CentOS is derived from the Red Hat Enterprise Linux codebase,
CentOS and Red Hat Enterprise Linux are distinguished by divergent build environments, QA
processes, and, in some editions, different kernels and other open source components. For
this reason, the CentOS binaries are not the same as the Red Hat Enterprise Linux
Once in use, the operating systems often diverge further, as users
selectively install patches to address bugs and security vulnerabilities to maintain their
respective installs. In addition, the CentOS Project maintains code repositories of
software that are not part of the Red Hat Enterprise Linux codebase. This includes feature
changes selected by the CentOS Project. These are available as extra/additional packages
and environments for CentOS users.
CentOS is a "Community Development Platform," not a RHEL clone.
Elliminate "clone" from the vocabulary when talking about CentOS. CentOS
has its own build system away from RHEL, and the RHEL guys don't share
the build details with CentOS teams. CentOS does not do CVE
verification. They simply rebuild and publish. And they figure out how
to rebuild on their own.
It's the CentOS *user*, not the CentOS project, that is responsible for
ensuring it doesn't break their software stack and actually fixes any
vulnerabilities because the CentOS project doesn't do this testing.
Once of the CentOS guys posted details to this regard:
What does this mean for CentOS users ... it means that YOU are
responsible to test the there is no longer an issue in YOUR environment
after you do the install. If you want a CERTIFIED fix that has been
tested, that is what Red Hat provides in RHEL. The reason they charge a
subscription price is because the do all this testing and they provide
assurance that the issues are known, fixed, tested, and certified as
<< deep breath again >>
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.
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'
- 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.