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
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: 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@redhat.com><mailto:jcerny@redhat.com>
Sent: Friday, June 5, 2020 9:36 AM
To: SCAP Security Guide
<scap-security-guide@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.c...
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@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to
scap-security-guide-leave@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<https://d...
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines<https://fedorap...
List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fe...
Disclaimer
The information contained in this communication from
trey.henefield@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@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
and others authorized to receive it. If you are not
scap-security-guide@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@lists.fedorahosted.org<mailto:scap-security-guide@lists.fedorahosted.org>
To unsubscribe send an email to
scap-security-guide-leave@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/<https://...
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines<https://fedorap...
List Archives:
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fe...