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. > > >> 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
