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. > 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. > > 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. > On Fri, Aug 7, 2020 at 9:21 AM Watson Sato <ws...@redhat.com> wrote: > >> Hello all, >> >> With the increasing number of products and profiles in >> ComplianceAsCode/content, keeping track of the policies, profiles and >> people involved has become more complex. >> In an effort to better maintain the profiles in the project, I'm looking >> for a way to have the following questions easily answered WRT to a profile: >> >> - Who should be consulted in case of questions about how a profile >> aligns (or should be aligned) with the policy? >> - Where does one get to know about new policy releases? >> - When is a policy version considered out of date? >> >> >> 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) >> >> Here is an example of how it can look like. (I have used profiles with >> known implicit maintainers or SMEs, in CC): >> >> https://github.com/yuumasato/scap-security-guide/commit/ba967716ef966048357228675a353801017485a9 >> >> I think these data will bring profile transparency to project >> maintainers, and profile maintainers can be kept in the loop with regards >> to changes in the profiles they care about. >> >> Let me know what you think about it, do you have other ideas? >> >> -- >> 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
