Ugh...that should have been *unwaiveable* instead of _unavailable_. On Sun, Dec 30, 2018 at 6:04 PM Trevor Vaughan <[email protected]> wrote:
> Hi Chuck, > > So, I agree with you all the way up to FIPS. Unfortunately, the tracing > that we've done on the FIPS 140-2 requirement through various ties to > policy and FISMA *appears* to be unavailable except by the President of the > US, by named position. Now, it's possible that this tracing is incorrect > but I have yet to find anyone that could find another *documented* > interpretation that overrides the Congressional mandate as handed down to > NIST and inherited through the 800-53 and CNSS 1253. > > That said, FIPS only applies for the "protection of sensitive > information". If you don't have any sensitive information (i.e. 100% test > and eval environment with independent credentials that have no access to > any other system) then fire away. > > Also, this mandate only applies to organizations directly under the > Executive and Legislative branches of Government. The Judicial branch can > do what it likes. > > Sorry for the slight rant, this is one of those particular items that just > drives me nuts in terms of laws (not policies) that people like to try and > ignore when it gets inconvenient. > > In terms of packages, I completely agree with Charlie that it's really > simple to just grab all of the packages through various means so the RHN is > really just making legitimate use more difficult for systems like yours and > rapid CI testing systems. We specifically do not use one of the many ways > of circumventing the process so that we don't run afoul of any licensing > rules or restrictions. > > Trevor > > On Sun, Dec 30, 2018 at 12:35 PM Chuck Atkins <[email protected]> > wrote: > >> Why use CentOS when RHEL developer subs are free? >> >> >> For our environment where we have a small deployment of only 2-4 >> machines, CentOS is much easier to manage off-line on an air-gaped >> network. Mirroring the CentOS repos is pretty easy to do with reposync and >> monthly drops to a web server on the red network. The CentOS workstations >> can then just point to the yum repos on said webserver and everything works >> like it's supposed to. Trying to do this with RHEL-proper is frustrating >> at best. A satellite server is way overkill for a deployment like this and >> setting up the clients for a "normal" yum repo requires removing and >> uninstalling all of the subscription / rhn packages. There's also the >> simplicity of only have 2 system repos to worry about to get everything >> available in CentOS (Base + Updates) vs dealing with the dozens of channels >> needed in a RHEL subscription to get the same set of available packages. I >> certainly get the value in all of the various options for managing large >> enterprise deployments but CentOS is just much simpler to deal with for us >> in a small deployment and software-developer-centric environment. We end >> up using both RHEL and CentOS for different use cases but need to apply the >> same security framework and settings to both. >> >> With regards to allowed security configurations, as a contractor we've >> never had issues with DSS and CentOS being allowed so long as we apply all >> the appropriate RHEL rules and can appropriately justify where we diverge. >> The only ones I've run into that end up not applicable across the two have >> been FIPS related, which we have to disable anyways to accommodate third >> party unsigned kernel modules for the Nvidia driver. The STIGs after all >> are just a guideline and place to start from so you can adapt it to your >> own environment with appropriate tailoring and justification, not a fixed >> "it has to be this way". Most of the government entities we work with (DoD >> and DoE) use RHEL for their infrastructure servers and end-user >> workstations but CentOS for their projects and developer environments. >> Many of the DoE labs we work with even use CentOS on their large scale HPC >> deployments (LANL, Sandia, LLNL, etc.) while others use RHEL proper. >> >> - Chuck >> _______________________________________________ >> scap-security-guide mailing list -- >> [email protected] >> To unsubscribe send an email to >> [email protected] >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedorahosted.org/archives/list/[email protected] >> > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 x788 > > -- This account not approved for unencrypted proprietary information -- > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
