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]
