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