TL;DR: FISMA Because I've done this research before....
FISMA => NIST 800-53 => FIPS (unwaiveable for the securing of sensitive information) NIST 800-53 inherited by CNSSI 1253 for NSS without modification (this one is a little muddy). NSA approved cryptography may be used instead. Trevor On Sat, Mar 7, 2020 at 1:45 AM James Cassell <[email protected]> wrote: > > On Fri, Mar 6, 2020, at 2:35 PM, Gabe Alford wrote: > > CentOS STIG profile removal was NOT political in any way. There are > > multiple reasons: > > > > - No vendor supports CentOS. > > - There is no security support for CVEs. > > - There is NO DISA STIG for CentOS. > > - RHEL-vendor supported and certified profiles do not map to CentOS... > > The CentOS project clearly states this. > > - CentOS is not common criteria certified. > > - CentOS components are not FIPS validated and using it violates > > Federal Law. > > RHEL 8 components are also not FIPS validated. Does using RHEL 8 also > violate Federal Law? (And which law, specifically?) > > V/r, > James Cassell > > > - CentOS is not in alignment with STIG requirements because it doesn't > > meet them due to not meeting applicable laws and vendor support. > > - There are valid cybersecurity reasons for not using CentOS. > > > > Now, if CentOS started to have a security team and handled it's own CVE > > content, FIPS-validation, and addressed issues, would be a completely > > different story. > > This is the same for the OSPP, CUI, etc. profiles as well. In fact, any > > profile that uses NIST 800-171 or NIST 800-53, CentOS fails to comply > > with and encouraging > > the community to support faulty security profiles is bad security > > practice in and of itself. > > > > On Fri, Mar 6, 2020 at 10:04 AM Watson Sato <[email protected]> wrote: > > > > > > > > > On Fri, Mar 6, 2020 at 5:05 PM Trey Henefield < > [email protected]> wrote: > > >> Copy that sir.____ > > > > >> __ __ > > > > >> Thanks for responding.____ > > > > >> __ __ > > > > >> I would love to contribute my changes. The problem is by the time we > get the latest release all fixed up and in alignment with STIG > requirements, a new release comes out and completely changes the way > content is generated. For example, the last release changed a bunch of > compliance code to now use templates and jinja. So now its not as simple to > merge my existing content as I now need to learn how things are now done > differently, fix issues in the new process and still get my code to work > and be compliant. It is very tiresome doing this continuously every single > release. We can never get things up to speed and commit changes because by > the time we turn around, everything is yet again drastically changed. > > > > > > > > Hello Trey, thanks for sharing your pain. > > > > > > I'd like to better understand the aspects of your changes, are they > only related to content, like rules and remediation? Or do you also tweak > the build system? > > > > > >> ____ > > > > >> __ __ > > > > >> I am all for innovation and finding better ways to accomplish tasks. > But these types of changes need to be less frequently to simply allow the > compliance code to mature.____ > > > > >> __ __ > > > > >> In most development environments, including our own, there is the > concept of major releases and minor releases. Where major releases > incorporate “major” changes into the software, such as changing how things > are done in the software. Minor releases provide for bug fixes to further > improve the reliability of the the software.____ > > > > >> __ __ > > > > >> I consider changing how all the code is compiled, adding new > processes and deprecating old processes, to be a major change as it has a > cascading affect for much of the content. Whereas, minor changes would > focus on simply improving the content utilizing the existing processes > already in place. > > > > > > > > There is an idea to separate the build system from the benchmark > directory: https://github.com/ComplianceAsCode/content/issues/5125 > > > Does this idea resonate with you? > > > Separating the content from the benchmark would minimize issues when > compiling processes change, but it could bring another set of problems, > like versioning, or upgrade paths. > > > > > >> ____ > > > > >> __ __ > > > > >> I had brought this up before but it just seems to be ignored.____ > > > > >> __ __ > > > > >> I really would like to see a better effort from the maintainers of > this content to improve on this issue so that those of us utilizing the > content and improving the content can have ample opportunity to upload > these improvements so that the rest of the community can benefit from these > changes alike.____ > > > > >> __ __ > > > > >> Best regards, > > >> > > >> > > >> *Trey Henefield, CISSP____* > > > > >> Cyber Security Manager > > >> > > >> ____ > > > > >> *__ __* > > > > >> *____* > > > > >> * > > *Ultra Intelligence & Communications____ > > > > >> 4101 Smith School Road____ > > > > >> Building IV, Suite 100____ > > > > >> Austin, TX 78744 USA > > >> T: +1 512 327 6795 ext. 647____ > > > > >> M: +1 512 541 6450 > > >> ultra.group <http://www.ultra.group/>____ > > > > >> __ __ > > > > >> *From:* Matěj Týč <[email protected]> > > >> *Sent:* Friday, March 6, 2020 4:13 AM > > >> *To:* Trey Henefield <[email protected]>; RADUSINOVIC, > IVAN J GS-12 USAF ACC 805 CTS/DOO <[email protected]>; Sherwin > Farhang <[email protected]>; [email protected] > > >> *Subject:* Re: [Open-scap] SCAP's for CentOS 7 & 8____ > > > > >> __ __ > > > > >> Hello Trey and others,____ > > > > >> first of all, the openscap list is mainly about the scanner, while > your points are about the content, for which I recommend the > [email protected] mailing list.____ > > > > >> Regarding the main topic, I vaguely recall discussions about whether > to have CentOS profiles that would be inevitably failing (due to lack of > certification of scanned systems), or whether to remove profiles that > require certifications to pass altogether. The second approach has won, > possibly driven by fears that the project would keep getting reports that a > rule is failing, so maintainers should do something about it and fix it.____ > > > > >> The scanner can't say "I am sorry, your system is not certified, > that's why the rule fails" - anyone using the scanner would see just > another rule failing, and one has to read the guide/report to correctly > understand what's the problem.____ > > > > >> On 05. 03. 20 18:16, Trey Henefield wrote:____ > > > > >>> I don’t have access to it at the moment as I am out of the office > this week and next, but I will provide this info when I return.____ > > > > >>> ____ > > > > >>> I was just as surprised as anyone else, but a customer informed me > of this. Because it is open source software, they were able to do a > complete source code review and approved it based on that, since the DoD > opensource policy permits this now.____ > > > > >>> ____ > > > > >>> We still prefer to use RedHat and bring them allot of business, but > it feels that this open source community is more business driven than > community driven, resulting in these types of decisions. But that should > not be the case for an open source community project.____ > > > > >> If any of you don't agree with decisions that were taken, let your > take on this be heard in the appropriate mailing list. Community is > inseparable from participation, maintainers will take shortcuts if there is > no visible pushback against them. > > >> > > >> ____ > > > > >>> ____ > > > > >>> While I am on my soap box, I will just reiterate again, I am not a > fan of the drastic changes that are added every two months to a new > release. Major changes like this and overhauling how compliance code gets > built every two months is just bad. These major changes should be released > in a new major release less frequently (6 months, or even once a year). > Rather, the incrimental releases pushed out every two months should be more > based on bring compliance code up to speed to provide more complete and > accurate coverage of the requirements. Everytime I merge in the latest > release with our code, we spend so much time going back and fixing all the > things it breaks.____ > > > > >> The Security Compliance field is gaining momentum, and it will > continue to do so in the foreseeable future. Therefore, the project needs > to accommodate ever-increasing requirements - such as introduction of new > profiles, new products, and even new paradigms. The only way to do so is to > refactor its parts and make them perform better. We are so far very > successful in this effort, and what you describe is the inevitable downside > of it.____ > > > > >> So Trey, do you think that your code could be upstreamed? That way, > it would become possible for us to keep it in a good shape at a low > cost.____ > > > > >>> ____ > > > > >>> Best regards, > > >>> > > >>> > > >>> *Trey Henefield, CISSP*____ > > > > >>> Cyber Security Manager > > >>> > > >>> > > >>> ____ > > > > >>> * *____ > > > > >>> ____ > > > > >>> * > > *Ultra Intelligence & Communications____ > > > > >>> 4101 Smith School Road____ > > > > >>> Building IV, Suite 100____ > > > > >>> Austin, TX 78744 USA > > >>> T: +1 512 327 6795 ext. 647____ > > > > >>> M: +1 512 541 6450 > > >>> ultra.group <http://www.ultra.group/>____ > > > > >>> ____ > > > > >>> *From:* RADUSINOVIC, IVAN J GS-12 USAF ACC 805 CTS/DOO < > [email protected]> > > >>> *Sent:* Thursday, March 5, 2020 10:54 AM > > >>> *To:* Trey Henefield <[email protected]>; Sherwin > Farhang <[email protected]>; [email protected] > > >>> *Subject:* RE: SCAP's for CentOS 7 & 8____ > > > > >>> ____ > > > > >>> Hey, while we’re on the topic, does anyone have the link depicting > it being on the APL? Which APL are we talking about?____ > > > > >>> ____ > > > > >>> Thanks!____ > > > > >>> ____ > > > > >>> S/F____ > > > > >>> ____ > > > > >>> Ivan Radusinovic____ > > > > >>> “R+10”; “Sgt Rad”____ > > > > >>> ISSE || 805th CTS / DOO____ > > > > >>> mob. 916-934-6592 || off. 702-652-8499 || ____ > > > > >>> NIPR [email protected]____ > > > > >>> SIPR [email protected] ____ > > > > >>> ____ > > > > >>> "Comm…. works 60% of the time.. all the time!"____ > > > > >>> - GySgt McCown____ > > > > >>> ____ > > > > >>> *From:* [email protected] < > [email protected]> *On Behalf Of *Trey Henefield > > >>> *Sent:* Thursday, March 5, 2020 8:47 AM > > >>> *To:* Sherwin Farhang <[email protected]>; > [email protected] > > >>> *Subject:* [Non-DoD Source] Re: [Open-scap] SCAP's for CentOS 7 & > 8____ > > > > >>> ____ > > > > >>> ____ > > > > >>> This is disappointing as it feels like a political move. There is no > functional reason why it could not be supported. It is approved within DoD > as it is on the approved software list.____ > > > > >>> ____ > > > > >>> Rather than removing its support, let the authorities that be make > the decision as to if it is acceptable for use.____ > > > > >>> ____ > > > > >>> Best regards, > > >>> > > >>> > > >>> *Trey Henefield, CISSP*____ > > > > >>> Cyber Security Manager > > >>> > > >>> > > >>> ____ > > > > >>> * *____ > > > > >>> ____ > > > > >>> * > > *Ultra Intelligence & Communications____ > > > > >>> 4101 Smith School Road____ > > > > >>> Building IV, Suite 100____ > > > > >>> Austin, TX 78744 USA > > >>> T: +1 512 327 6795 ext. 647____ > > > > >>> M: +1 512 541 6450 > > >>> ultra.group <http://www.ultra.group/>____ > > > > >>> ____ > > > > >>> *From:* [email protected] < > [email protected]> *On Behalf Of *Sherwin Farhang > > >>> *Sent:* Wednesday, March 4, 2020 3:47 PM > > >>> *To:* [email protected] > > >>> *Subject:* [Open-scap] SCAP's for CentOS 7 & 8____ > > > > >>> ____ > > > > >>> Hi OpenSCAP team,____ > > > > >>> ____ > > > > >>> I tried following a guide to deploy DISA STIG's from RedHat to > CentOS I was dissapointed this functionality is intentionally not supported > anymore. Can't a message be shot across saying "deploying this does not > make you compliant to DISA STIG because this is CentOS and does not carry > the proper certifications"? I just found this tool and tested it out to > deploy pci-dss as a test to a vm and it was really convenient that it > worked so well. It would be nice if that functionality still worked. Also > when I run CentOS 8 and download the workbench no CentOS profiles are > downloaded but they do download for CentOS - 7 Likely a bug unless your > team is actually just removing all functionality for CentOS 8 moving > forward which is disappointing as well. Whenever I see a project remove > functionality a fork is made and the community splits. I hope to hear > back.____ > > > > >>> ____ > > > > >>> Thank you,____ > > > > >>> ____ > > > > >>> -Sherwin____ > > > > >>> ____ > > > > >>> *Sherwin Farhang** *| CISSP | GCIH | CCSK ____ > > > > >>> ____ > > > > >>> ISSO____ > > > > >>> ____ > > > > >>> 6518 Meadowridge Rd. | Ste. 100 | Elkridge, MD 21075____ > > > > >>> ____ > > > > >>> ____ > > > > >>> P 443.701.5266| F 1.866.824.8914 | newwave.io < > https://www.newwave.io/>____ > > > > >>> ____ > > > > >>> ____ > > > > >>> ____ > > > > >>> ____ > > > > >>> [email protected] < > https://www.facebook.com/NewWave.Telecom.and.Technologies/>____ > > > > >>> [email protected] < > https://www.instagram.com/newwave_tech/>____ > > > > >>> [email protected] <https://twitter.com/NewWave_Tech > >____ > > > > >>> [email protected] < > https://www.linkedin.com/company/newwave_technologies>____ > > > > >>> ____ > > > > >>> ____ > > > > >>> [email protected] <https://newwave.io/>____ > > > > >>> ____ > > > > >>> ____ > > > > >>> MBE Certified; GSA Schedule 70 > > >>> CMMI® Maturity Level 4 Rated SVC | Level 3 Rated DEV____ > > > > >>> ISO 9001:2015 Certified____ > > > > >>> *Microsoft** **Partner:* Gold Cloud Platform: Gold Datacenter; > Silver Application Development____ > > > > >>> ____ > > > > >>> Confidentiality Notice: This message and all attachments are for the > sole use of the intended recipient(s) and may contain NewWave Telecom & > Technologies confidential and privileged information or otherwise be > protected by law. This message is intended for use by the individual or > entity to which it is addressed and any unauthorized review, use, > disclosure or distribution is prohibited . If you are not the intended > recipient, please contact the sender by reply e-mail and destroy all copies > of the original message. ____ > > > > >>> ____ > > > > >>> *Disclaimer* > > >>> The information contained in this communication from * > [email protected] *sent at 2020-03-05 11:47:08 is private and > may be legally privileged or export controlled. It is intended solely for > use by *[email protected] *and others authorized to receive it. > If you are not *[email protected] *you are hereby notified that > any disclosure, copying, distribution or taking action in reliance of the > contents of this information is strictly prohibited and may be unlawful.____ > > > > >>> > > >>> > > >>> ____ > > > > >>> ___________________________________________________ Open-scap-list > mailing list____ [email protected]____ > https://www.redhat.com/mailman/listinfo/open-scap-list____ > > >> _______________________________________________ > > >> Open-scap-list mailing list > > >> [email protected] > > >> https://www.redhat.com/mailman/listinfo/open-scap-list > > > > > > > > > -- > > > Watson Sato > > > Security Technologies | Red Hat, Inc > > > _______________________________________________ > > > scap-security-guide mailing list -- > [email protected] > > > To unsubscribe send an email to > [email protected] > > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > > https://lists.fedorahosted.org/archives/list/[email protected] > > _______________________________________________ > > scap-security-guide mailing list -- > > [email protected] > > To unsubscribe send an email to > > [email protected] > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > > https://lists.fedorahosted.org/archives/list/[email protected] > > > > Attachments: > > * image001.jpg > > * image002.png > > * image003.png > > * image004.png > > * image005.png > > * image006.png > > * image007.png > > * image008.png > _______________________________________________ > scap-security-guide mailing list -- > [email protected] > To unsubscribe send an email to > [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > 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 --
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
