On Fri, Aug 14, 2020 at 5:35 PM Gabe Alford <redhatri...@gmail.com> wrote:
> > > On Thu, Aug 13, 2020 at 1:34 AM Watson Sato <ws...@redhat.com> wrote: > >> >> >> On Wed, Aug 12, 2020 at 1:40 AM Gabe Alford <redhatri...@gmail.com> >> wrote: >> >>> >>> >>> On Tue, Aug 11, 2020 at 6:00 AM Watson Sato <ws...@redhat.com> wrote: >>> >>>> >>>> >>>> On Tue, Aug 11, 2020 at 1:24 AM Shane Boulden <sboul...@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: ws...@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. >>> >>> >>>> >>>> >>>>> On Mon, Aug 10, 2020 at 8:18 PM Matej Tyc <ma...@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 <redhatri...@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: ws...@redhat.com >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>> On Fri, Aug 7, 2020 at 9:21 AM Watson Sato <ws...@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-le...@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.fedorahosted.org >>>> >>> _______________________________________________ >>> scap-security-guide mailing list -- >>> scap-security-guide@lists.fedorahosted.org >>> To unsubscribe send an email to >>> scap-security-guide-le...@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.fedorahosted.org >>> >> >> >> -- >> 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-le...@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.fedorahosted.org >> > _______________________________________________ > scap-security-guide mailing list -- > scap-security-guide@lists.fedorahosted.org > To unsubscribe send an email to > scap-security-guide-le...@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.fedorahosted.org > -- 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-le...@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.fedorahosted.org
