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
NACK.
If you would like to work on real policy evaluation, there are projects that we can hook you up with. There is a lot more to policy evaluation than what this proposal is and incorporates more work than the members of this project have time for. This problem is being worked on in other spaces and has standards being developed around them which the proposed format doesn't take into consideration.
This is major scope creep to the purpose of this repo which is about security scanning and remediation of content and will fundamentally break our downstream users. This project is not positioned to correctly tackle policy evaluation and is going to slow down our release and build process even further. This is also a roadblock to getting the requests that current customers are demanding completed. There are other higher priority upstream tasks that have received no attention in OpenSCAP, SCAP Workbench, etc. repos. Those need to be dealt with and completed first.
On Fri, Jun 5, 2020 at 8:36 AM Jan Cerny jcerny@redhat.com wrote:
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@lists.fedorahosted.org To unsubscribe send an email to 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.fedor...
Hi,
On Fri, Jun 5, 2020 at 5:50 PM Gabe Alford redhatrises@gmail.com wrote:
NACK.
I would rather welcome some specific ideas or comments on how to improve the proposed format to get this feature finished soon.
If you would like to work on real policy evaluation, there are projects that we can hook you up with.
It is intentionally proposed this way to avoid dependencies on other projects and repositories.
There is a lot more to policy evaluation than what this proposal is and incorporates more work than the members of this project have time for. This problem is being worked on in other spaces and has standards being developed around them which the proposed format doesn't take into consideration.
We were considering OSCAL, but we have received feedback that its purpose is different from what we do in SCAP Security Guide. To me personally OSCAL seems overly complex for this purpose. Do you know any other standard which we should consider?
This is major scope creep to the purpose of this repo which is about security scanning and remediation of content and will fundamentally break our downstream users. This project is not positioned to correctly tackle policy evaluation and is going to slow down our release and build process even further. This is also a roadblock to getting the requests that current customers are demanding completed. There are other higher priority upstream tasks that have received no attention in OpenSCAP, SCAP Workbench, etc. repos. Those need to be dealt with and completed first.
We don't want to break any downstream user by this change. What specific problem can it cause?
What customer requests is it blocking?
Which issues need to be completed first? I think that this is an independent effort.
On Fri, Jun 5, 2020 at 8:36 AM Jan Cerny jcerny@redhat.com wrote:
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@lists.fedorahosted.org To unsubscribe send an email to 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.fedor...
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to 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.fedor...
Best regards
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@redhat.com Sent: Friday, June 5, 2020 9:36 AM To: SCAP Security Guide 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 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 To unsubscribe send an email to 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.fedor...
Disclaimer The information contained in this communication from trey.henefield@ultra-ats.com sent at 2020-06-05 14:25:26 is confidential and may be legally privileged. It is intended solely for use by scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not 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@lists.fedorahosted.org
-
Gabe Alford -
Jan Cerny -
Trey Henefield