On Fri, Aug 14, 2020 at 5:35 PM Gabe Alford <redhatrises(a)gmail.com> wrote:
On Thu, Aug 13, 2020 at 1:34 AM Watson Sato <wsato(a)redhat.com> wrote:
>
>
> On Wed, Aug 12, 2020 at 1:40 AM Gabe Alford <redhatrises(a)gmail.com>
> wrote:
>
>>
>>
>> On Tue, Aug 11, 2020 at 6:00 AM Watson Sato <wsato(a)redhat.com> wrote:
>>
>>>
>>>
>>> On Tue, Aug 11, 2020 at 1:24 AM Shane Boulden <sboulden(a)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(a)redhat.com
>>>>
>>>> Could we use coThe idea to use cocdeowners
>>>>
<
https://docs.github.com/en/github/creating-cloning-and-archiving-reposito...
>>>> 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 <matyc(a)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(a)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(a)redhat.com
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>> On Fri, Aug 7, 2020 at 9:21 AM Watson Sato <wsato(a)redhat.com>
wrote:
>>>>>> ...
>>>>>>
>>>>>
>>>
>>> --
>>> Watson Sato
>>> Security Technologies | Red Hat, Inc
>>> _______________________________________________
>>> scap-security-guide mailing list --
>>> scap-security-guide(a)lists.fedorahosted.org
>>> To unsubscribe send an email to
>>> scap-security-guide-leave(a)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.fe...
>>>
>> _______________________________________________
>> scap-security-guide mailing list --
>> scap-security-guide(a)lists.fedorahosted.org
>> To unsubscribe send an email to
>> scap-security-guide-leave(a)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.fe...
>>
>
>
> --
> Watson Sato
> Security Technologies | Red Hat, Inc
> _______________________________________________
> scap-security-guide mailing list --
> scap-security-guide(a)lists.fedorahosted.org
> To unsubscribe send an email to
> scap-security-guide-leave(a)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.fe...
>
_______________________________________________
scap-security-guide mailing list --
scap-security-guide(a)lists.fedorahosted.org
To unsubscribe send an email to
scap-security-guide-leave(a)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.fe...
--
Watson Sato
Security Technologies | Red Hat, Inc