scap-security-guide March 2020

scap-security-guide@lists.fedorahosted.org

22 participants
16 discussions

New blog post: Stay on Top of Your Profile
by Matěj Týč 10 Mar '20

10 Mar '20

Are you a profile stakeholder, or are you just interested in a profile and its development? Then check out the ComplianceAsCode blog, and enjoy the last post: https://complianceascode.github.io/template/2020/03/06/profile_guard.html The upstream project has recently acquired a feature that can help you to make a profile stable, and you can alternatively decide to use it to compare profile contents between git refs. Check it out and tell us what you think - you can discuss below the blog post, or you can use the list. Happy hardening and content authoring!

1 0

Apache stig question
by Matthew 09 Mar '20

09 Mar '20

Pretty confident wrong place to ask, But someone here should know(cough cough trevor) There's an Apache stig AS24-U1-000510 that states to enable session_crypto or SessionCryptoCipher aes256 yet when I try, apache fails to start. Apr-util-openssl is installed.

2 2

Re: [Open-scap] SCAP's for CentOS 7 & 8
by Chuck Atkins 09 Mar '20

09 Mar '20

FWIW, I had a PR to the SSG that enables all the available profiles for RHEL derivatives even though they will fail the FIPS and vendor supported tests. https://github.com/chuckatkins/scap-security-guide/commit/4de658370f3c4bace… It was quickly dismissed for the reasons already mentioned. It's something that regularly comes up a few times a year and is generally met with the same responses. It seems to be something that users and admins actively want but that the SSG maintainers are are not likely to budge on. ---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. (518) 881-1183 On Fri, Mar 6, 2020 at 3:04 PM Trey Henefield <trey.henefield(a)ultra-ats.com> wrote: > Hi Gabe, > > > > A majority of the RHEL STIG rules can directly map to CentOS, as it is > largely based on RedHat releases. > > > > CentOS does release security patches that align with those released for > RedHat. > > > > I can understand the FIPS and Common Criteria concerns. Let those checks > fail as they may. I was previously an evaluator and consultant for Common > Criteria in a prior life, so I do appreciate the hard effort and extreme > costs involved with that. But moving into a system accredditation > standpoint, it’s a simple IA control in RMF. One of many others which it > can address. > > > > Trust me, I was severely disappointed about how little the large effort of > Common Criteria goes unnoticed in a system accredditation process. There’s > not even a requirement to ensure the system is in its evaluated > configuration. Rather, they are more focused on ensuring it meets the STIG > requirements. But in light of DoD’s stance on the acceptance of Open Source > software, the need for Common Criteria certification seems to be left > behind. It is a disappointing reality, but nonetheless a reality. > > > > For example, we utilize OpenSSH on Windows. We compile it ourselves > utilizing the OpenSSL FIPS module to gain FIPS compliance. While > technically since it offers an abundance of IA capabilities, one would > think that it should also be Common Criteria certified. But that is not the > case. > > > > I understand your reasonings. But the fact of the matter is that CentOS is > approved for use and RHEL STIGs are used as guidance in configuring it to > be compliant. > > > > With that said, there’s no reason why a CentOS profile could not be > maintained within the ComplianceAsCode content. > > > > 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:* Gabe Alford <redhatrises(a)gmail.com> > *Sent:* Friday, March 6, 2020 1:36 PM > *To:* SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org> > *Cc:* Trey Henefield <trey.henefield(a)ultra-ats.com>; RADUSINOVIC, IVAN J > GS-12 USAF ACC 805 CTS/DOO <ivan.radusinovic(a)us.af.mil>; > open-scap-list(a)redhat.com; Sherwin Farhang <Sherwin.Farhang(a)newwave.io>; > Matěj Týč <matyc(a)redhat.com> > *Subject:* Re: [Open-scap] SCAP's for CentOS 7 & 8 > > > > 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. > > - 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 <wsato(a)redhat.com> wrote: > > > > > > On Fri, Mar 6, 2020 at 5:05 PM Trey Henefield < > trey.henefield(a)ultra-ats.com> 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ýč <matyc(a)redhat.com> > *Sent:* Friday, March 6, 2020 4:13 AM > *To:* Trey Henefield <trey.henefield(a)ultra-ats.com>; RADUSINOVIC, IVAN J > GS-12 USAF ACC 805 CTS/DOO <ivan.radusinovic(a)us.af.mil>; Sherwin Farhang < > Sherwin.Farhang(a)newwave.io>; open-scap-list(a)redhat.com > *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 > scap-security-guide(a)lists.fedorahosted.org 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 > <ivan.radusinovic(a)us.af.mil> <ivan.radusinovic(a)us.af.mil> > *Sent:* Thursday, March 5, 2020 10:54 AM > *To:* Trey Henefield <trey.henefield(a)ultra-ats.com> > <trey.henefield(a)ultra-ats.com>; Sherwin Farhang > <Sherwin.Farhang(a)newwave.io> <Sherwin.Farhang(a)newwave.io>; > open-scap-list(a)redhat.com > *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 ivan.radusinovic(a)us.af.mil > > SIPR ivan.j.radusinovic.civ(a)mail.smil.mil > > > > "Comm…. works 60% of the time.. all the time!" > > - GySgt McCown > > > > *From:* open-scap-list-bounces(a)redhat.com < > open-scap-list-bounces(a)redhat.com> *On Behalf Of *Trey Henefield > *Sent:* Thursday, March 5, 2020 8:47 AM > *To:* Sherwin Farhang <Sherwin.Farhang(a)newwave.io>; > open-scap-list(a)redhat.com > *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:* open-scap-list-bounces(a)redhat.com < > open-scap-list-bounces(a)redhat.com> *On Behalf Of *Sherwin Farhang > *Sent:* Wednesday, March 4, 2020 3:47 PM > *To:* open-scap-list(a)redhat.com > *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/> > > > > > > > > > > [image: cidimage011.png(a)01D5E32F.9731D090] > <https://www.facebook.com/NewWave.Telecom.and.Technologies/> > > [image: cidimage012.png(a)01D5E32F.9731D090] > <https://www.instagram.com/newwave_tech/> > > [image: cidimage013.png(a)01D5E32F.9731D090] > <https://twitter.com/NewWave_Tech> > > [image: cidimage014.png(a)01D5E32F.9731D090] > <https://www.linkedin.com/company/newwave_technologies> > > > > > > [image: cidimage015.png(a)01D5E32F.9731D090] <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 *trey.henefield(a)ultra-ats.com > <trey.henefield(a)ultra-ats.com> *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 *open-scap-list(a)redhat.com <open-scap-list(a)redhat.com> *and > others authorized to receive it. If you are not *open-scap-list(a)redhat.com > <open-scap-list(a)redhat.com> *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 > > Open-scap-list(a)redhat.com > > https://www.redhat.com/mailman/listinfo/open-scap-list > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list > > > > -- > > Watson Sato > Security Technologies | Red Hat, Inc > > _______________________________________________ > scap-security-guide mailing list -- > scap-security-guide(a)lists.fedorahosted.org > To unsubscribe send an email to > scap-security-guide-leave(a)lists.fedorahosted.org > 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/scap-security-guide@lists.fedo… > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list

3 2

Re: [Open-scap] SCAP's for CentOS 7 & 8
by Watson Sato 07 Mar '20

07 Mar '20

On Fri, Mar 6, 2020 at 5:05 PM Trey Henefield <trey.henefield(a)ultra-ats.com> 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ýč <matyc(a)redhat.com> > *Sent:* Friday, March 6, 2020 4:13 AM > *To:* Trey Henefield <trey.henefield(a)ultra-ats.com>; RADUSINOVIC, IVAN J > GS-12 USAF ACC 805 CTS/DOO <ivan.radusinovic(a)us.af.mil>; Sherwin Farhang < > Sherwin.Farhang(a)newwave.io>; open-scap-list(a)redhat.com > *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 > scap-security-guide(a)lists.fedorahosted.org 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 > <ivan.radusinovic(a)us.af.mil> <ivan.radusinovic(a)us.af.mil> > *Sent:* Thursday, March 5, 2020 10:54 AM > *To:* Trey Henefield <trey.henefield(a)ultra-ats.com> > <trey.henefield(a)ultra-ats.com>; Sherwin Farhang > <Sherwin.Farhang(a)newwave.io> <Sherwin.Farhang(a)newwave.io>; > open-scap-list(a)redhat.com > *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 ivan.radusinovic(a)us.af.mil > > SIPR ivan.j.radusinovic.civ(a)mail.smil.mil > > > > "Comm…. works 60% of the time.. all the time!" > > - GySgt McCown > > > > *From:* open-scap-list-bounces(a)redhat.com < > open-scap-list-bounces(a)redhat.com> *On Behalf Of *Trey Henefield > *Sent:* Thursday, March 5, 2020 8:47 AM > *To:* Sherwin Farhang <Sherwin.Farhang(a)newwave.io>; > open-scap-list(a)redhat.com > *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:* open-scap-list-bounces(a)redhat.com < > open-scap-list-bounces(a)redhat.com> *On Behalf Of *Sherwin Farhang > *Sent:* Wednesday, March 4, 2020 3:47 PM > *To:* open-scap-list(a)redhat.com > *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/> > > > > > > > > > > [image: cidimage011.png(a)01D5E32F.9731D090] > <https://www.facebook.com/NewWave.Telecom.and.Technologies/> > > [image: cidimage012.png(a)01D5E32F.9731D090] > <https://www.instagram.com/newwave_tech/> > > [image: cidimage013.png(a)01D5E32F.9731D090] > <https://twitter.com/NewWave_Tech> > > [image: cidimage014.png(a)01D5E32F.9731D090] > <https://www.linkedin.com/company/newwave_technologies> > > > > > > [image: cidimage015.png(a)01D5E32F.9731D090] <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 *trey.henefield(a)ultra-ats.com > <trey.henefield(a)ultra-ats.com> *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 *open-scap-list(a)redhat.com <open-scap-list(a)redhat.com> *and > others authorized to receive it. If you are not *open-scap-list(a)redhat.com > <open-scap-list(a)redhat.com> *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 > > Open-scap-list(a)redhat.com > > https://www.redhat.com/mailman/listinfo/open-scap-list > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list -- Watson Sato Security Technologies | Red Hat, Inc

4 3

RE: [Open-scap] SCAP's for CentOS 7 & 8
by Trey Henefield 06 Mar '20

06 Mar '20

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. 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. 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 [cid:image001.jpg@01D5F39D.CB086E00] 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ýč <matyc(a)redhat.com> Sent: Friday, March 6, 2020 4:13 AM To: Trey Henefield <trey.henefield(a)ultra-ats.com>; RADUSINOVIC, IVAN J GS-12 USAF ACC 805 CTS/DOO <ivan.radusinovic(a)us.af.mil>; Sherwin Farhang <Sherwin.Farhang(a)newwave.io>; open-scap-list(a)redhat.com 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 scap-security-guide(a)lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org> 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 [cid:image001.jpg@01D5F39D.CB086E00] 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 <ivan.radusinovic(a)us.af.mil><mailto:ivan.radusinovic@us.af.mil> Sent: Thursday, March 5, 2020 10:54 AM To: Trey Henefield <trey.henefield(a)ultra-ats.com><mailto:trey.henefield@ultra-ats.com>; Sherwin Farhang <Sherwin.Farhang(a)newwave.io><mailto:Sherwin.Farhang@newwave.io>; open-scap-list(a)redhat.com<mailto:open-scap-list@redhat.com> 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 ivan.radusinovic(a)us.af.mil<mailto:ivan.radusinovic@us.af.mil> SIPR ivan.j.radusinovic.civ(a)mail.smil.mil<mailto:ivan.j.radusinovic.civ@mail.smil.mil> "Comm…. works 60% of the time.. all the time!" - GySgt McCown From: open-scap-list-bounces(a)redhat.com<mailto:open-scap-list-bounces@redhat.com> <open-scap-list-bounces(a)redhat.com<mailto:open-scap-list-bounces@redhat.com>> On Behalf Of Trey Henefield Sent: Thursday, March 5, 2020 8:47 AM To: Sherwin Farhang <Sherwin.Farhang(a)newwave.io<mailto:Sherwin.Farhang@newwave.io>>; open-scap-list(a)redhat.com<mailto:open-scap-list@redhat.com> 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 [cid:image001.jpg@01D5F39D.CB086E00] 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: open-scap-list-bounces(a)redhat.com<mailto:open-scap-list-bounces@redhat.com> <open-scap-list-bounces(a)redhat.com<mailto:open-scap-list-bounces@redhat.com>> On Behalf Of Sherwin Farhang Sent: Wednesday, March 4, 2020 3:47 PM To: open-scap-list(a)redhat.com<mailto:open-scap-list@redhat.com> 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/> [cidimage011.png(a)01D5E32F.9731D090]<https://www.facebook.com/NewWave.Telecom.and.Technologies/> [cidimage012.png(a)01D5E32F.9731D090]<https://www.instagram.com/newwave_tech/> [cidimage013.png(a)01D5E32F.9731D090]<https://twitter.com/NewWave_Tech> [cidimage014.png(a)01D5E32F.9731D090]<https://www.linkedin.com/company/newwave_technologies> [cidimage015.png(a)01D5E32F.9731D090]<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 [cid:image007.png@01D5F39D.CB086E00][cid:image008.png@01D5F39D.CB086E00] 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 trey.henefield(a)ultra-ats.com<mailto:trey.henefield@ultra-ats.com> 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 open-scap-list(a)redhat.com<mailto:open-scap-list@redhat.com> and others authorized to receive it. If you are not open-scap-list(a)redhat.com<mailto:open-scap-list@redhat.com> 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 Open-scap-list(a)redhat.com<mailto:Open-scap-list@redhat.com> https://www.redhat.com/mailman/listinfo/open-scap-list<https://www.redhat.com/mailman/listinfo/open-scap-list>

1 0

Stabilization of v0.1.49
by Watson Sato 05 Mar '20

05 Mar '20

Hello all, *Release of Content version 0.1.49 is scheduled for March 13th*, so I've created a stabilization branch for it. Now is a good time to hunt for bugs and propose fixes for them. Starting today, merged Pull Requests should be assigned to milestone v0.1.50. Bug fixes should be proposed to master and labeled "bugfix", they will be cherry-picked to the stabilization branch. -- Watson Sato Security Technologies | Red Hat, Inc

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide March 2020