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: https://www.niap-ccevs.org/NIAP_Evolution/faqs/nstissp-11/ And here's the definition of "What is a National Security System?": https://www.niap-ccevs.org/NIAP_Evolution/faqs/nstissp-11/#Question_III_2 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: http://www.gpo.gov/fdsys/pkg/STATUTE-116/pdf/STATUTE-116-Pg2899.pdf Skip to PDF pg58, "$11331. Responsibilities for Federal information systems standards" - 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 @ https://www.niap-ccevs.org/NIAP_Evolution/faqs/nstissp-11/#Question_I_1 - 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: http://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf 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 of > 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 2002, > tasked NIST with the responsibility of developing security standards and > guidelines for the federal > government including the development of: > • Standards for categorizing information and information systems collected or > maintained by > or on behalf of each federal agency based on the objectives of providing > appropriate levels of > information security according to a range of risk levels; > • Guidelines recommending the types of information and information systems to > be included in > each category; and > • Minimum information security requirements for information and information > systems in each such category. 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: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf 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. 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 have. Another goodie, SA-4(6), "Acquisition Process | Use of Information Assurance Products", which reads: > The organization: > (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 transmit > the information are at a lower classification level than the information > being transmitted; and > (b) Ensures that these products hav And then SA-4(7), "Acquisition Process | NIAP-Approved Protection Profiles," which reads: > The organization: > (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 for a > 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 > functionality > 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 Linux?" http://community.redhat.com/centos-faq/#_centos > 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 binaries. .... > 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: http://lists.centos.org/pipermail/centos/2014-May/143094.html > 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 > mitigated. << 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. -- 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/
