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