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 <fedoraproject(a)cyberpear.com>
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 <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>
> >>> *Sent:* Thursday, March 5, 2020 10:54 AM
> >>> *To:* Trey Henefield <trey.henefield(a)ultra-ats.com>; Sherwin
Farhang <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/>____
>
> >>> ____
>
> >>> ____
>
> >>> ____
>
> >>> ____
>
> >>> 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____
>
> >>> ____
>
> >>> 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 *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 *and others authorized to receive it.
If you are not *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.fe...
> _______________________________________________
> 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.fe...
>
> Attachments:
> * image001.jpg
> * image002.png
> * image003.png
> * image004.png
> * image005.png
> * image006.png
> * image007.png
> * image008.png
_______________________________________________
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.fe...
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --