Hello Trey,
the change that is discussed here is a backwards-compatible one, so it
wouldn't break anything for you.
I understand your pain, but as the repository increases in size both in
rule count and profile count, actions need to be taken so the project
retains its level of maintainability. For example, the recent redesign
of templates was quite disruptive, but it also fixed tens of rules that
nobody had capacity to fix before.
This change aims to introduce possibility to reuse chunks of rules
between profiles, and to make profile definitions easier to read and to
maintain.
How would you rate maintainability of
https://github.com/ComplianceAsCode/content/blob/master/rhel7/profiles/nc...
and of
https://github.com/ComplianceAsCode/content/blob/master/rhel8/profiles/os...
? Both profiles select over hundred of rules, and I am sure that the
RHEL7 profile would make it very difficult for anybody to determine
whether a rule is missing, or the profile is complete. The RHEL8 profile
has comments that make things more clear, and the proposal we are
discussing in this thread basically moves things one step further, from
optional comments to a schema. It will still be possible to do things
the old way though.
I am sure that all contributors feel disappointed when contributions are
not accepted, and trust me, it happens to everybody. I would recommend
you to have a fork with all rules that were rejected upstream added.
You say that the immediate focus should be content completeness and
accuracy. I think that this should be the long-term focus. When you have
incorrect copy-pasted code, the immediate thing to do is not fixing it
again by more copy-pasting, but one should rather remove the
copy-pasting, if it is possible. Unfortunately, this is what breaks the
backwards compatibility, but it is always for a good reason.
If you have a particular backward-compatibility problem, please tell us,
and we may write a blog post about it, so porting your old code will be
fast and efficient:
https://complianceascode.github.io
Best regards,
Matej Tyc
On 05. 06. 20 20:25, Trey Henefield wrote:
This won't solve the problems with your content.
The problem is that there has been pushback to accept community
suggestions due to personal perferences. There is much more focus on
continuously changing the structure of the project, than the content
of the project.
The ultimate goal for this project should be to provide checks and
remediations that accurately reflect (no more and no less) what is
required by a particular regulation.
Regaurdless of what default behaviors are present in the RedHat
operating system, if a configuration is required to be explicitly
configured, it should be configured. So that the intent of what the
requirement is explicitly requiring is addressed. Saying that this
does not apply because it does this already, does not hold well when
this content is used and this discrepency has to be explained to
validators.
Our organization has basically gave up contributing and maintain our
own personal branch to ensure we provide solutions that meet the
needed requirements.
To greatly improve this project, the immediate focus needs to be on
content completeness and accuracy. This would provide the best value
this project could offer to the community.
The structure of this project and how to better improve it should be a
secondary focus, with these structural changes better thought out and
implemented, before being integrated into the project. These major
changes should be introduced less frequently (1 or 2 times a year) to
allow contributors time to complete their changes. Just about every
two months when a new release is pushed, we have to redo allot of
stuff we did to get our changes working in the new release. This is
very time consuming and difficult to maintain.
I truly hope someone there at RedHat is finally listening to this and
takes our advice.
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
-----Original Message-----
From: Jan Cerny <jcerny(a)redhat.com>
Sent: Friday, June 5, 2020 9:36 AM
To: SCAP Security Guide <scap-security-guide(a)lists.fedorahosted.org>
Subject: Policy source data format proposal is ready for comments
Hi,
The policy source data format proposal is available and ready for
comments. The text has been submitted as a pull request on GitHub to
make the discussion easier using comments and reviews.
See
https://github.com/ComplianceAsCode/content/pull/5817
We are looking forward to seeing your feedback on GitHub.
What is it about? We will use the policy source data format to improve
development of our profiles. It will allow us to store security
controls and requirements in the repository and then define profiles
by using their IDs instead of separate rules.
This is done in order to solve the problem that there is no easy way
to demonstrate to profile stakeholders the status of their profile.
Intended workflow:
* SME identifies security controls the policy consists of. Those
controls serve as direct input for our profiles.
* SME goes through controls, and makes sure that they are sufficiently
covered by rules.
* SME fine-tunes the profile by overriding a couple of individual
rules in the profile file.
Once the format is accepted we can start developing tools that support
this new workflow.
In future, we can also use it for further refactoring, for example
streamlining the generation of HTML tables.
Best regards
--
Jan Černý
Security Technologies | Red Hat, Inc.
_______________________________________________
scap-security-guide mailing list --
scap-security-guide(a)lists.fedorahosted.org
<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to
scap-security-guide-leave(a)lists.fedorahosted.org
<mailto:scap-security-guide-leave@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...
*Disclaimer*
The information contained in this communication from
*trey.henefield(a)ultra-ats.com * sent at 2020-06-05 14:25:25 is private
and may be legally privileged or export controlled. It is intended
solely for use by *scap-security-guide(a)lists.fedorahosted.org * and
others authorized to receive it. If you are not
*scap-security-guide(a)lists.fedorahosted.org * 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.
_______________________________________________
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...