On Tue, Aug 11, 2020 at 1:24 AM Shane Boulden sboulden@redhat.com wrote:
I like that the proposal adds "policy_hub", "version" and "comes_into_force" into the profile file (with the assumption that this will not make it into XCCDF). Having this information directly in the .profile file makes it simpler for users and partners to see the current state.
I see an issue with maintainers - we can mix up at least GH usernames and
e-mails - what about considering it a list of dicts, so we could have e.g. maintainers:
- github: redhatrises
- github: yuumasato email: wsato@redhat.com
Could we use coThe idea to use cocdeowners https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners instead to track profile maintainers? This way the profile owners will be immediately notified when a PR is opened for a .profile file, and avoids having to maintain dicts of username->email mappings (it's simply tied to the GH username)
The automatic notifications of codeowners make it very interesting. I have two remarks though:
1. maintenance of the codeowners file, which needs to be done by admins or owners; 2. permissions, codeowners need to have write permission for the repo;
This centralizes the management of Profile "ownership" and increases requirements on the codeowners.
On Mon, Aug 10, 2020 at 8:18 PM Matej Tyc matyc@redhat.com wrote:
I have remarks to Gabe's remarks, but I add them to Watson's reply, so the thread doesn't bifurcate. On 10. 08. 20 10:22, Watson Sato wrote:
On Sat, Aug 8, 2020 at 12:10 AM Gabe Alford redhatrises@gmail.com wrote:
Anything that is metadata should conform to the Dublin Core per the XCCDF specification for the .profile files, or it can be a commented out section at the top of the .profile.
As the purpose is to record key properties of the profile, I am not in favor of specifying them as comments - one can't parse them reliably, and as we would like this to save us some work, we want to have at most one schema that can be approached by computers.
Next, the schema presented by Watson reflects what we think is useful to record. I wouldn't compromise here because of the Dublin thing. I understand this as a resource for content authors, it could possibly be inserted as a table into the profile description, and we could have a test that key profiles have this record. Putting this info into profile XCCDF metadata makes sense, but I wouldn't use this as a factor that would restrict the data set that we would like to record.
I didn't envision this metadata to be included in the built XCCDF profile, so I didn't look into the formal syntax. And it is laid out as yaml to ease any eventual build system future automation.
Alternatively, a single file like maintainers or profile maintainers would be better as a single source of truth.
That could work too, in this case I would make the file per product, to keep them simple.
I don't get the single source of truth thing - wouldn't it be the respective profile file? Typically, one is interested in who maintains a particular profile, not in how many profiles one person maintains. But more importantly, I think it is important to see who maintains the profile when one edits the profile file, or when one reviews the change. Having two files - one with the profile definition, and the other one that may or may not contain information about possible profile stakeholders - is cumbersome.
nitpick: I think that "comes_into_force" should be something else like "when", "applicability", or "profile_enforcement".
Thank you for the suggestions, I was not sure what would be a good name for the field.
But this also makes me wonder if tracking this is even necessary as
technically in all compliance regimes a newly released profile becomes applicable on release.
The core of this field is clarity and understanding how the policy is applied in practice, if it is the case that all policies and profiles are instantly unusable when a new version is released, this field is unnecessary. The proposal for "comes_into_force" assumed that the organizations implementing and/or enforcing the policy don't update instantly, and have a time frame to adapt.
I see this as a possibility to at least loosely define shape of profiles
- if a stakeholder claims that they expect the profile to be behind at most
six months, then comparison of a couple of numbers can quickly tell us whether the profile is good, on track, or whether it was left behind.
Below is a draft proposal of a set of *optional* metadata to be added to the ".profile" file. Everything is pretty much free form and optional.
- policy_hub: (URL pointing to page or organization that publishes
the policy)
- version: (version of the policy implemented)
- comes_into_force: (text stating when a policy starts being
enforced, in other words, when a policy version is in practice obsolete)
- maintainers: (contact of policy SME, stakeholder, or person
responsible for the profile, can be in form of GitHub handle for example)
I see an issue with maintainers - we can mix up at least GH usernames and e-mails - what about considering it a list of dicts, so we could have e.g.
maintainers:
- github: redhatrises
- github: yuumasato email: wsato@redhat.com
On Fri, Aug 7, 2020 at 9:21 AM Watson Sato wsato@redhat.com wrote:
...
On Tue, Aug 11, 2020 at 6:00 AM Watson Sato wsato@redhat.com wrote:
On Tue, Aug 11, 2020 at 1:24 AM Shane Boulden sboulden@redhat.com wrote:
I like that the proposal adds "policy_hub", "version" and "comes_into_force" into the profile file (with the assumption that this will not make it into XCCDF). Having this information directly in the .profile file makes it simpler for users and partners to see the current state.
The more I think about it, the more I am against comes_into_force. This isn't something that should be maintained or used upstream and is easily misconstrued (even if documented) for when an organization enforces policy and policy changes. The more correct way is to open a milestone upstream and associate tickets with that milestone which would include the policy reference and version. This provides an accurate picture and would easily show and tell users what needs to be done to help complete tickets for closing out gaps in the profiles. It also shows that security analysis has been performed for what has to be done to a profile for a product version.
Adding keys that are only used upstream don't provide as much value as keys that are used in the downstream validated content. The "policy_hub" should become "reference" and both "reference" and "version" can be added to xccdf:Profile when the content is generated This would provide more value in the long run and can be easily discoverable in official reports.
I see an issue with maintainers - we can mix up at least GH usernames and
e-mails - what about considering it a list of dicts, so we could have e.g. maintainers:
- github: redhatrises
- github: yuumasato email: wsato@redhat.com
Could we use coThe idea to use cocdeowners https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners instead to track profile maintainers? This way the profile owners will be immediately notified when a PR is opened for a .profile file, and avoids having to maintain dicts of username->email mappings (it's simply tied to the GH username)
The automatic notifications of codeowners make it very interesting. I have two remarks though:
- maintenance of the codeowners file, which needs to be done by
admins or owners; 2. permissions, codeowners need to have write permission for the repo;
This centralizes the management of Profile "ownership" and increases requirements on the codeowners.
I actually really like this idea of using codeowners to track profile maintainers and think it is a more elegant solution than keeping track in the profile.
On Mon, Aug 10, 2020 at 8:18 PM Matej Tyc matyc@redhat.com wrote:
I have remarks to Gabe's remarks, but I add them to Watson's reply, so the thread doesn't bifurcate. On 10. 08. 20 10:22, Watson Sato wrote:
On Sat, Aug 8, 2020 at 12:10 AM Gabe Alford redhatrises@gmail.com wrote:
Anything that is metadata should conform to the Dublin Core per the XCCDF specification for the .profile files, or it can be a commented out section at the top of the .profile.
As the purpose is to record key properties of the profile, I am not in favor of specifying them as comments - one can't parse them reliably, and as we would like this to save us some work, we want to have at most one schema that can be approached by computers.
Next, the schema presented by Watson reflects what we think is useful to record. I wouldn't compromise here because of the Dublin thing. I understand this as a resource for content authors, it could possibly be inserted as a table into the profile description, and we could have a test that key profiles have this record. Putting this info into profile XCCDF metadata makes sense, but I wouldn't use this as a factor that would restrict the data set that we would like to record.
I didn't envision this metadata to be included in the built XCCDF profile, so I didn't look into the formal syntax. And it is laid out as yaml to ease any eventual build system future automation.
Alternatively, a single file like maintainers or profile maintainers would be better as a single source of truth.
That could work too, in this case I would make the file per product, to keep them simple.
I don't get the single source of truth thing - wouldn't it be the respective profile file? Typically, one is interested in who maintains a particular profile, not in how many profiles one person maintains. But more importantly, I think it is important to see who maintains the profile when one edits the profile file, or when one reviews the change. Having two files - one with the profile definition, and the other one that may or may not contain information about possible profile stakeholders - is cumbersome.
nitpick: I think that "comes_into_force" should be something else like "when", "applicability", or "profile_enforcement".
Thank you for the suggestions, I was not sure what would be a good name for the field.
But this also makes me wonder if tracking this is even necessary as
technically in all compliance regimes a newly released profile becomes applicable on release.
The core of this field is clarity and understanding how the policy is applied in practice, if it is the case that all policies and profiles are instantly unusable when a new version is released, this field is unnecessary. The proposal for "comes_into_force" assumed that the organizations implementing and/or enforcing the policy don't update instantly, and have a time frame to adapt.
I see this as a possibility to at least loosely define shape of profiles
- if a stakeholder claims that they expect the profile to be behind at most
six months, then comparison of a couple of numbers can quickly tell us whether the profile is good, on track, or whether it was left behind.
Below is a draft proposal of a set of *optional* metadata to be added to the ".profile" file. Everything is pretty much free form and optional.
- policy_hub: (URL pointing to page or organization that publishes
the policy)
- version: (version of the policy implemented)
- comes_into_force: (text stating when a policy starts being
enforced, in other words, when a policy version is in practice obsolete)
- maintainers: (contact of policy SME, stakeholder, or person
responsible for the profile, can be in form of GitHub handle for example)
I see an issue with maintainers - we can mix up at least GH usernames and e-mails - what about considering it a list of dicts, so we could have e.g.
maintainers:
- github: redhatrises
- github: yuumasato email: wsato@redhat.com
On Fri, Aug 7, 2020 at 9:21 AM Watson Sato wsato@redhat.com wrote:
...
-- Watson Sato 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...
On 12. 08. 20 1:39, Gabe Alford wrote:
On Tue, Aug 11, 2020 at 6:00 AM Watson Sato <wsato@redhat.com mailto:wsato@redhat.com> wrote:
On Tue, Aug 11, 2020 at 1:24 AM Shane Boulden <sboulden@redhat.com <mailto:sboulden@redhat.com>> wrote: I like that the proposal adds "policy_hub", "version" and "comes_into_force" into the profile file (with the assumption that this will not make it into XCCDF). Having this information directly in the .profile file makes it simpler for users and partners to see the current state.The more I think about it, the more I am against comes_into_force. This isn't something that should be maintained or used upstream and is easily misconstrued (even if documented) for when an organization enforces policy and policy changes. The more correct way is to open a milestone upstream and associate tickets with that milestone which would include the policy reference and version. This provides an accurate picture and would easily show and tell users what needs to be done to help complete tickets for closing out gaps in the profiles. It also shows that security analysis has been performed for what has to be done to a profile for a product version.
By creating tickets, you mean something like this? https://github.com/ComplianceAsCode/content/labels/New%20rule%2Fprofile
We have a long history of tickets that nobody asked for, and that were perhaps created in good faith, but they are still there, and there is a lot of them (almost 1/3 of all open tickets). I would like to avoid a situation of creating more tickets that at the end, nobody finds useful.
Adding keys that are only used upstream don't provide as much value as keys that are used in the downstream validated content. The "policy_hub" should become "reference" and both "reference" and "version" can be added to xccdf:Profile when the content is generated This would provide more value in the long run and can be easily discoverable in official reports.
The original idea is exactly about allowing new profile metadata to profile files. This means that it is a backward-compatible extension of the input format which requires almost no implementation. Some profile authors already found think that it is useful, and that's good sign for us - we target profile stakeholders and content authors, and it is good enough if only some of them are interested. If it doesn't work out, no problem - upstream-only metadata can be removed or altered without causing substantial issues to other ComplianceAsCode users.
What you propose is something else - embedding the information into the datastream would, among other things, require support for XCCDF1.2 in our build system, which is a significant development effort. I don't disagree with that, I just why not to start small?
I see an issue with maintainers - we can mix up at least GH usernames and e-mails - what about considering it a list of dicts, so we could have e.g. maintainers: - github: redhatrises - github: yuumasato email: wsato@redhat.com <mailto:wsato@redhat.com>Could we use coThe idea to use cocdeowners https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners instead to track profile maintainers? This way the profile owners will be immediately notified when a PR is opened for a .profile file, and avoids having to maintain dicts of username->email mappings (it's simply tied to the GH username)
The automatic notifications of codeowners make it very interesting. I have two remarks though: 1. maintenance of the codeowners file, which needs to be done by admins or owners; 2. permissions, codeowners need to have write permission for the repo; This centralizes the management of Profile "ownership" and increases requirements on the codeowners.I actually really like this idea of using codeowners to track profile maintainers and think it is a more elegant solution than keeping track in the profile.
Again, why not to track things in the profile, and introduce the codeowners concept once it's established? Maybe not all profile stakeholders want to approve every PR that touches their profile. Moreover, the codeowners is a slightly separate thing - it should target reference compiled profiles, as a profile composition may change as a result of a change in extended profile.
For example Ted is a STIG stakeholder, but not an OSPP stakeholder, so we would incline to have his name in the STIG profile file, but not in the OSPP one. But in RHEL8, the STIG currently inherits from OSPP, so he should be notified of OSPP changes that propagate to STIG, and that's where the codeowners system could help.
On Wed, Aug 12, 2020 at 1:40 AM Gabe Alford redhatrises@gmail.com wrote:
On Tue, Aug 11, 2020 at 6:00 AM Watson Sato wsato@redhat.com wrote:
On Tue, Aug 11, 2020 at 1:24 AM Shane Boulden sboulden@redhat.com wrote:
I like that the proposal adds "policy_hub", "version" and "comes_into_force" into the profile file (with the assumption that this will not make it into XCCDF). Having this information directly in the .profile file makes it simpler for users and partners to see the current state.
The more I think about it, the more I am against comes_into_force. This isn't something that should be maintained or used upstream and is easily misconstrued (even if documented) for when an organization enforces policy and policy changes.
I *think* I understand what you mean, that upstream should not say when an organization enforces a policy, because this is a matter between the auditor and the auditee. (I guess this is similar to how we cannot say that one is compliant just by passing all cheks). *But* can't this also mean that an older policy version is not necessarily out dated? Because the auditor may be okay with an old policy version... (I'm digressing, I guess)
My intention with the "comes_into_ force" field was to have some kind of loose documentation for the layman, for ourselves, to make it easier to identify when a profile becomes outdated and cannot be used.
The more correct way is to open a milestone upstream and associate tickets
with that milestone which would include the policy reference and version. This provides an accurate picture and would easily show and tell users what needs to be done to help complete tickets for closing out gaps in the profiles. It also shows that security analysis has been performed for what has to be done to a profile for a product version.
As you mention, this goes into the path of measuring the gap and closing it. My goal is much smaller, I'd like a way to make it easy to identify out of date profiles. It can by either putting down the data/info, pointing to a validity page, a formula with version numbers and publication dates... It may well be a foolish attempt to have written down "when a profile is out of date", either because "it always depends" or because "it is always out of date immediately when a new version is published".
Adding keys that are only used upstream don't provide as much value as keys that are used in the downstream validated content. The "policy_hub" should become "reference" and both "reference" and "version" can be added to xccdf:Profile when the content is generated This would provide more value in the long run and can be easily discoverable in official reports.
I see an issue with maintainers - we can mix up at least GH usernames
and e-mails - what about considering it a list of dicts, so we could have e.g. maintainers:
- github: redhatrises
- github: yuumasato email: wsato@redhat.com
Could we use coThe idea to use cocdeowners https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners instead to track profile maintainers? This way the profile owners will be immediately notified when a PR is opened for a .profile file, and avoids having to maintain dicts of username->email mappings (it's simply tied to the GH username)
The automatic notifications of codeowners make it very interesting. I have two remarks though:
- maintenance of the codeowners file, which needs to be done by
admins or owners; 2. permissions, codeowners need to have write permission for the repo;
This centralizes the management of Profile "ownership" and increases requirements on the codeowners.
I actually really like this idea of using codeowners to track profile maintainers and think it is a more elegant solution than keeping track in the profile.
On Mon, Aug 10, 2020 at 8:18 PM Matej Tyc matyc@redhat.com wrote:
I have remarks to Gabe's remarks, but I add them to Watson's reply, so the thread doesn't bifurcate. On 10. 08. 20 10:22, Watson Sato wrote:
On Sat, Aug 8, 2020 at 12:10 AM Gabe Alford redhatrises@gmail.com wrote:
Anything that is metadata should conform to the Dublin Core per the XCCDF specification for the .profile files, or it can be a commented out section at the top of the .profile.
As the purpose is to record key properties of the profile, I am not in favor of specifying them as comments - one can't parse them reliably, and as we would like this to save us some work, we want to have at most one schema that can be approached by computers.
Next, the schema presented by Watson reflects what we think is useful to record. I wouldn't compromise here because of the Dublin thing. I understand this as a resource for content authors, it could possibly be inserted as a table into the profile description, and we could have a test that key profiles have this record. Putting this info into profile XCCDF metadata makes sense, but I wouldn't use this as a factor that would restrict the data set that we would like to record.
I didn't envision this metadata to be included in the built XCCDF profile, so I didn't look into the formal syntax. And it is laid out as yaml to ease any eventual build system future automation.
Alternatively, a single file like maintainers or profile maintainers would be better as a single source of truth.
That could work too, in this case I would make the file per product, to keep them simple.
I don't get the single source of truth thing - wouldn't it be the respective profile file? Typically, one is interested in who maintains a particular profile, not in how many profiles one person maintains. But more importantly, I think it is important to see who maintains the profile when one edits the profile file, or when one reviews the change. Having two files - one with the profile definition, and the other one that may or may not contain information about possible profile stakeholders - is cumbersome.
nitpick: I think that "comes_into_force" should be something else like "when", "applicability", or "profile_enforcement".
Thank you for the suggestions, I was not sure what would be a good name for the field.
But this also makes me wonder if tracking this is even necessary as
technically in all compliance regimes a newly released profile becomes applicable on release.
The core of this field is clarity and understanding how the policy is applied in practice, if it is the case that all policies and profiles are instantly unusable when a new version is released, this field is unnecessary. The proposal for "comes_into_force" assumed that the organizations implementing and/or enforcing the policy don't update instantly, and have a time frame to adapt.
I see this as a possibility to at least loosely define shape of profiles - if a stakeholder claims that they expect the profile to be behind at most six months, then comparison of a couple of numbers can quickly tell us whether the profile is good, on track, or whether it was left behind.
Below is a draft proposal of a set of *optional* metadata to be added to the ".profile" file. Everything is pretty much free form and optional.
- policy_hub: (URL pointing to page or organization that publishes
the policy)
- version: (version of the policy implemented)
- comes_into_force: (text stating when a policy starts being
enforced, in other words, when a policy version is in practice obsolete)
- maintainers: (contact of policy SME, stakeholder, or person
responsible for the profile, can be in form of GitHub handle for example)
I see an issue with maintainers - we can mix up at least GH usernames and e-mails - what about considering it a list of dicts, so we could have e.g.
maintainers:
- github: redhatrises
- github: yuumasato email: wsato@redhat.com
On Fri, Aug 7, 2020 at 9:21 AM Watson Sato wsato@redhat.com wrote:
...
-- Watson Sato 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...
On Thu, Aug 13, 2020 at 1:34 AM Watson Sato wsato@redhat.com wrote:
On Wed, Aug 12, 2020 at 1:40 AM Gabe Alford redhatrises@gmail.com wrote:
On Tue, Aug 11, 2020 at 6:00 AM Watson Sato wsato@redhat.com wrote:
On Tue, Aug 11, 2020 at 1:24 AM Shane Boulden sboulden@redhat.com wrote:
I like that the proposal adds "policy_hub", "version" and "comes_into_force" into the profile file (with the assumption that this will not make it into XCCDF). Having this information directly in the .profile file makes it simpler for users and partners to see the current state.
The more I think about it, the more I am against comes_into_force. This isn't something that should be maintained or used upstream and is easily misconstrued (even if documented) for when an organization enforces policy and policy changes.
I *think* I understand what you mean, that upstream should not say when an organization enforces a policy, because this is a matter between the auditor and the auditee. (I guess this is similar to how we cannot say that one is compliant just by passing all cheks). *But* can't this also mean that an older policy version is not necessarily out dated? Because the auditor may be okay with an old policy version... (I'm digressing, I guess)
My intention with the "comes_into_ force" field was to have some kind of loose documentation for the layman, for ourselves, to make it easier to identify when a profile becomes outdated and cannot be used.
The more correct way is to open a milestone upstream and associate tickets
with that milestone which would include the policy reference and version. This provides an accurate picture and would easily show and tell users what needs to be done to help complete tickets for closing out gaps in the profiles. It also shows that security analysis has been performed for what has to be done to a profile for a product version.
As you mention, this goes into the path of measuring the gap and closing it. My goal is much smaller, I'd like a way to make it easy to identify out of date profiles. It can by either putting down the data/info, pointing to a validity page, a formula with version numbers and publication dates... It may well be a foolish attempt to have written down "when a profile is out of date", either because "it always depends" or because "it is always out of date immediately when a new version is published".
I understand what you are trying to accomplish, but this is the crux of the problem for the very reason that "it always depends" and/or "it is always out of date immediately when a new version is published". It might be better to have a "refresh" field with options of "yearly", "quarterly", "monthly", etc. but I hesitate on that because the very expectation that users will have is to have a 100% complete profile making an iterative approach very difficult. And if for some reason, that that doesn't happen, it's going to not look good for us.
Adding keys that are only used upstream don't provide as much value as keys that are used in the downstream validated content. The "policy_hub" should become "reference" and both "reference" and "version" can be added to xccdf:Profile when the content is generated This would provide more value in the long run and can be easily discoverable in official reports.
I see an issue with maintainers - we can mix up at least GH usernames
and e-mails - what about considering it a list of dicts, so we could have e.g. maintainers:
- github: redhatrises
- github: yuumasato email: wsato@redhat.com
Could we use coThe idea to use cocdeowners https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners instead to track profile maintainers? This way the profile owners will be immediately notified when a PR is opened for a .profile file, and avoids having to maintain dicts of username->email mappings (it's simply tied to the GH username)
The automatic notifications of codeowners make it very interesting. I have two remarks though:
- maintenance of the codeowners file, which needs to be done by
admins or owners; 2. permissions, codeowners need to have write permission for the repo;
This centralizes the management of Profile "ownership" and increases requirements on the codeowners.
I actually really like this idea of using codeowners to track profile maintainers and think it is a more elegant solution than keeping track in the profile.
On Mon, Aug 10, 2020 at 8:18 PM Matej Tyc matyc@redhat.com wrote:
I have remarks to Gabe's remarks, but I add them to Watson's reply, so the thread doesn't bifurcate. On 10. 08. 20 10:22, Watson Sato wrote:
On Sat, Aug 8, 2020 at 12:10 AM Gabe Alford redhatrises@gmail.com wrote:
Anything that is metadata should conform to the Dublin Core per the XCCDF specification for the .profile files, or it can be a commented out section at the top of the .profile.
As the purpose is to record key properties of the profile, I am not in favor of specifying them as comments - one can't parse them reliably, and as we would like this to save us some work, we want to have at most one schema that can be approached by computers.
Next, the schema presented by Watson reflects what we think is useful to record. I wouldn't compromise here because of the Dublin thing. I understand this as a resource for content authors, it could possibly be inserted as a table into the profile description, and we could have a test that key profiles have this record. Putting this info into profile XCCDF metadata makes sense, but I wouldn't use this as a factor that would restrict the data set that we would like to record.
I didn't envision this metadata to be included in the built XCCDF profile, so I didn't look into the formal syntax. And it is laid out as yaml to ease any eventual build system future automation.
Alternatively, a single file like maintainers or profile maintainers would be better as a single source of truth.
That could work too, in this case I would make the file per product, to keep them simple.
I don't get the single source of truth thing - wouldn't it be the respective profile file? Typically, one is interested in who maintains a particular profile, not in how many profiles one person maintains. But more importantly, I think it is important to see who maintains the profile when one edits the profile file, or when one reviews the change. Having two files - one with the profile definition, and the other one that may or may not contain information about possible profile stakeholders - is cumbersome.
nitpick: I think that "comes_into_force" should be something else like "when", "applicability", or "profile_enforcement".
Thank you for the suggestions, I was not sure what would be a good name for the field.
But this also makes me wonder if tracking this is even necessary as
technically in all compliance regimes a newly released profile becomes applicable on release.
The core of this field is clarity and understanding how the policy is applied in practice, if it is the case that all policies and profiles are instantly unusable when a new version is released, this field is unnecessary. The proposal for "comes_into_force" assumed that the organizations implementing and/or enforcing the policy don't update instantly, and have a time frame to adapt.
I see this as a possibility to at least loosely define shape of profiles - if a stakeholder claims that they expect the profile to be behind at most six months, then comparison of a couple of numbers can quickly tell us whether the profile is good, on track, or whether it was left behind.
Below is a draft proposal of a set of *optional* metadata to be added to the ".profile" file. Everything is pretty much free form and optional.
- policy_hub: (URL pointing to page or organization that publishes
the policy)
- version: (version of the policy implemented)
- comes_into_force: (text stating when a policy starts being
enforced, in other words, when a policy version is in practice obsolete)
- maintainers: (contact of policy SME, stakeholder, or person
responsible for the profile, can be in form of GitHub handle for example)
I see an issue with maintainers - we can mix up at least GH usernames and e-mails - what about considering it a list of dicts, so we could have e.g.
maintainers:
- github: redhatrises
- github: yuumasato email: wsato@redhat.com
On Fri, Aug 7, 2020 at 9:21 AM Watson Sato wsato@redhat.com wrote:
...
-- Watson Sato 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...
-- Watson Sato 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...
On Fri, Aug 14, 2020 at 5:35 PM Gabe Alford redhatrises@gmail.com wrote:
On Thu, Aug 13, 2020 at 1:34 AM Watson Sato wsato@redhat.com wrote:
On Wed, Aug 12, 2020 at 1:40 AM Gabe Alford redhatrises@gmail.com wrote:
On Tue, Aug 11, 2020 at 6:00 AM Watson Sato wsato@redhat.com wrote:
On Tue, Aug 11, 2020 at 1:24 AM Shane Boulden sboulden@redhat.com wrote:
I like that the proposal adds "policy_hub", "version" and "comes_into_force" into the profile file (with the assumption that this will not make it into XCCDF). Having this information directly in the .profile file makes it simpler for users and partners to see the current state.
The more I think about it, the more I am against comes_into_force. This isn't something that should be maintained or used upstream and is easily misconstrued (even if documented) for when an organization enforces policy and policy changes.
I *think* I understand what you mean, that upstream should not say when an organization enforces a policy, because this is a matter between the auditor and the auditee. (I guess this is similar to how we cannot say that one is compliant just by passing all cheks). *But* can't this also mean that an older policy version is not necessarily out dated? Because the auditor may be okay with an old policy version... (I'm digressing, I guess)
My intention with the "comes_into_ force" field was to have some kind of loose documentation for the layman, for ourselves, to make it easier to identify when a profile becomes outdated and cannot be used.
The more correct way is to open a milestone upstream and associate
tickets with that milestone which would include the policy reference and version. This provides an accurate picture and would easily show and tell users what needs to be done to help complete tickets for closing out gaps in the profiles. It also shows that security analysis has been performed for what has to be done to a profile for a product version.
As you mention, this goes into the path of measuring the gap and closing it. My goal is much smaller, I'd like a way to make it easy to identify out of date profiles. It can by either putting down the data/info, pointing to a validity page, a formula with version numbers and publication dates... It may well be a foolish attempt to have written down "when a profile is out of date", either because "it always depends" or because "it is always out of date immediately when a new version is published".
I understand what you are trying to accomplish, but this is the crux of the problem for the very reason that "it always depends" and/or "it is always out of date immediately when a new version is published". It might be better to have a "refresh" field with options of "yearly", "quarterly", "monthly", etc. but I hesitate on that because the very expectation that users will have is to have a 100% complete profile making an iterative approach very difficult. And if for some reason, that that doesn't happen, it's going to not look good for us.
I understand your concerns too.
So it seems that one should consider its own context, and interpret the outdatedness of a profile for themselves, and representing it in upstream is tricky and can be misleading.
I have made a PR https://github.com/ComplianceAsCode/content/pull/6004 to illustrate in code how the metadata info in the Profile would look like (I've dropped the "comes_into_force" field). Although I put some info already, and even assigned a few people as mainters, it would be best if in the future the maintainers put themselves there.
Adding keys that are only used upstream don't provide as much value as keys that are used in the downstream validated content. The "policy_hub" should become "reference" and both "reference" and "version" can be added to xccdf:Profile when the content is generated This would provide more value in the long run and can be easily discoverable in official reports.
I see an issue with maintainers - we can mix up at least GH usernames
and e-mails - what about considering it a list of dicts, so we could have e.g. maintainers:
- github: redhatrises
- github: yuumasato email: wsato@redhat.com
Could we use coThe idea to use cocdeowners https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners instead to track profile maintainers? This way the profile owners will be immediately notified when a PR is opened for a .profile file, and avoids having to maintain dicts of username->email mappings (it's simply tied to the GH username)
The automatic notifications of codeowners make it very interesting. I have two remarks though:
- maintenance of the codeowners file, which needs to be done by
admins or owners; 2. permissions, codeowners need to have write permission for the repo;
This centralizes the management of Profile "ownership" and increases requirements on the codeowners.
I actually really like this idea of using codeowners to track profile maintainers and think it is a more elegant solution than keeping track in the profile.
On Mon, Aug 10, 2020 at 8:18 PM Matej Tyc matyc@redhat.com wrote:
I have remarks to Gabe's remarks, but I add them to Watson's reply, so the thread doesn't bifurcate. On 10. 08. 20 10:22, Watson Sato wrote:
On Sat, Aug 8, 2020 at 12:10 AM Gabe Alford redhatrises@gmail.com wrote:
> Anything that is metadata should conform to the Dublin Core per the > XCCDF specification for the .profile files, or it can be a commented out > section at the top of the .profile. > As the purpose is to record key properties of the profile, I am not in favor of specifying them as comments - one can't parse them reliably, and as we would like this to save us some work, we want to have at most one schema that can be approached by computers.
Next, the schema presented by Watson reflects what we think is useful to record. I wouldn't compromise here because of the Dublin thing. I understand this as a resource for content authors, it could possibly be inserted as a table into the profile description, and we could have a test that key profiles have this record. Putting this info into profile XCCDF metadata makes sense, but I wouldn't use this as a factor that would restrict the data set that we would like to record.
I didn't envision this metadata to be included in the built XCCDF profile, so I didn't look into the formal syntax. And it is laid out as yaml to ease any eventual build system future automation.
> Alternatively, a single file like maintainers or profile maintainers > would be better as a single source of truth. >
That could work too, in this case I would make the file per product, to keep them simple.
I don't get the single source of truth thing - wouldn't it be the respective profile file? Typically, one is interested in who maintains a particular profile, not in how many profiles one person maintains. But more importantly, I think it is important to see who maintains the profile when one edits the profile file, or when one reviews the change. Having two files - one with the profile definition, and the other one that may or may not contain information about possible profile stakeholders - is cumbersome.
> nitpick: I think that "comes_into_force" should be something else > like "when", "applicability", or "profile_enforcement". >
Thank you for the suggestions, I was not sure what would be a good name for the field.
But this also makes me wonder if tracking this is even necessary as > technically in all compliance regimes a newly released profile becomes > applicable on release. >
The core of this field is clarity and understanding how the policy is applied in practice, if it is the case that all policies and profiles are instantly unusable when a new version is released, this field is unnecessary. The proposal for "comes_into_force" assumed that the organizations implementing and/or enforcing the policy don't update instantly, and have a time frame to adapt.
I see this as a possibility to at least loosely define shape of profiles - if a stakeholder claims that they expect the profile to be behind at most six months, then comparison of a couple of numbers can quickly tell us whether the profile is good, on track, or whether it was left behind.
Below is a draft proposal of a set of *optional* metadata to be added to the ".profile" file. Everything is pretty much free form and optional.
- policy_hub: (URL pointing to page or organization that
publishes the policy)
- version: (version of the policy implemented)
- comes_into_force: (text stating when a policy starts being
enforced, in other words, when a policy version is in practice obsolete)
- maintainers: (contact of policy SME, stakeholder, or person
responsible for the profile, can be in form of GitHub handle for example)
I see an issue with maintainers - we can mix up at least GH usernames and e-mails - what about considering it a list of dicts, so we could have e.g.
maintainers:
- github: redhatrises
- github: yuumasato email: wsato@redhat.com
> On Fri, Aug 7, 2020 at 9:21 AM Watson Sato wsato@redhat.com wrote: > ... >
-- Watson Sato 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...
-- Watson Sato 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...
scap-security-guide@lists.fedorahosted.org
-
Gabe Alford -
Matej Tyc -
Watson Sato