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@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@us.af.mil><mailto:ivan.radusinovic@us.af.mil>
Sent: Thursday, March 5, 2020 10:54 AM
To: Trey Henefield
<trey.henefield@ultra-ats.com><mailto:trey.henefield@ultra-ats.com>; Sherwin
Farhang <Sherwin.Farhang@newwave.io><mailto:Sherwin.Farhang@newwave.io>;
open-scap-list@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@us.af.mil<mailto:ivan.radusinovic@us.af.mil>
SIPR
ivan.j.radusinovic.civ@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@redhat.com<mailto:open-scap-list-bounces@redhat.com>
<open-scap-list-bounces@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@newwave.io<mailto:Sherwin.Farhang@newwave.io>>;
open-scap-list@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@redhat.com<mailto:open-scap-list-bounces@redhat.com>
<open-scap-list-bounces@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@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@01D5E32F.9731D090]<https://www.facebook.com/NewWave.Telecom.and.Technologies/>
[cidimage012.png@01D5E32F.9731D090]<https://www.instagram.com/newwave_tech/>
[cidimage013.png@01D5E32F.9731D090]<https://twitter.com/NewWave_Tech>
[cidimage014.png@01D5E32F.9731D090]<https://www.linkedin.com/company/newwave_technologies>
[cidimage015.png@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@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@redhat.com<mailto:open-scap-list@redhat.com> and
others authorized to receive it. If you are not
open-scap-list@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@redhat.com<mailto:Open-scap-list@redhat.com>
https://www.redhat.com/mailman/listinfo/open-scap-list<https://www.red...