Hello Trey,
we are talking about two different things, and those are not mutually
exclusive.
Some subjects see the projects as a gigantic jigsaw puzzle, where
individual pieces are rules, and they can use those to compose custom
profiles - I understood that this is your case as well. For those,
everything else than rules and associated content doesn't really matter,
and improvements to how rules are defined may become quite disruptive.
However, a huge number of subjects would like to use the high-level
aspect of the project - profiles in datastreams that you can feed to the
scanner right away, and that will scan your system. We get a huge number
of requests for profiles, and we try to make things easier to profile
authors, so they can start contributing to ComplianceAsCode, and we can
focus on rules and on the testing infrastructure.
I disagree that we introduce new features just for the sake of
creativity, and again, the announcement that started this discussion was
about a backwards-compatible improvement that profile authors are on
board with. In other words, this won't break anything, so you can relax
about this.
I am really curious though what is it that broke your builds. Could you
please share some details? We may be able to help, or to at least do a
better job in this regard next time.
Best regards,
Matej
On 08. 06. 20 16:07, Trey Henefield wrote:
Hi Matej,
I see what you’re saying.
It does improve readability.
Ultimately, automation is king. I had some code in the project once
upon a time that would improve visibility of coverage of the
requirements. Pulling the data from the source requirements (i.e.
STIG), then aligning that data with the STIG overlay to identify total
coverage of the STIG, then aligning that data with the mapped OVAL
rules to identify overall coverage of requirements by the checks and
remediations included. This probably could have been extended to
compare the rules in the STIG profile with the rules in the STIG
overlay to identify rules in the overlay not captured in the profile
and rules in the profile that don’t align to a requirement in the STIG
overlay.
I still respectfully disagree with you.
The goal of this project is to provide content that facilitates
helping organizations meet requirements. From the consumer side of
this, this project is pretty pointless if it only gets you a fraction
of the way there. To make this project useful, it needs to be more
complete and accurate. Having it build better or include a better way
showing what few requirements are addressed doesn’t provide any value
add if it still doesn’t increase the percentage of coverage of
requirements to be validated and mitigated.
You can change the frame of a picture, but it doesn’t change the picture.
I just want to give you the perspective from a user of this content. I
can’t use the content as it’s provided. I have to go in and address
all the issues and add code to get compliant for our systems. But for
the many other users out there that don’t have the luxury of
understanding how to deal with updating the code, they end up with a
solution that gets them compliant after days\hours of manual changes
to fix the issues it causes and make up for the lack of coverage where
it doesn’t.
If the goal of this project is to be a pet project for developers to
try new things and be creative, then I can understand your current
direction.
If the goal of this project is to help users in meeting industry
standards with applicable software instaled, then the direction should
be to provide complete and accurate checks and remedations. This is
what end users really need and would value most from this project.
Best regards,
*Trey Henefield, CISSP*
Cyber Security Manager
UltraIntelligence & 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:* Matej Tyc <matyc(a)redhat.com>
*Sent:* Monday, June 8, 2020 4:52 AM
*To:* scap-security-guide(a)lists.fedorahosted.org
*Subject:* Re: Policy source data format proposal is ready for comments
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
<
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 <
http://ultra.group>
-----Original Message-----
From: Jan Cerny <jcerny(a)redhat.com> <mailto:jcerny@redhat.com>
Sent: Friday, June 5, 2020 9:36 AM
To: SCAP Security Guide
<scap-security-guide(a)lists.fedorahosted.org>
<mailto:scap-security-guide@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
<
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
<
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
<mailto:trey.henefield@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
<mailto:scap-security-guide@lists.fedorahosted.org> *and others
authorized to receive it. If you are not
*scap-security-guide(a)lists.fedorahosted.org
<mailto:scap-security-guide@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
<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email toscap-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...
_______________________________________________
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...