[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 May 2023 13:57:04 +0200
From: Marcus Meissner <meissner@...e.de>
To: oss-security@...ts.openwall.com
Subject: Re: Clarification on embargoed testing in a partner
cloud
Hi,
On Thu, May 11, 2023 at 07:36:44AM -0400, Marc Deslauriers wrote:
> Hi,
>
> The Ubuntu security team shares and obtains information about embargoed
> issues from the distros and linux-distros mailing lists.
>
> One of our large cloud partners has asked the Ubuntu security team to do
> automated testing of embargoed security updates on their public cloud before
> the CRD. While technically we would not be directly sharing details of
> embargoed issues with them as the tests will be run under accounts owned by
> the Ubuntu security team, they will be run on their infrastructure. As such,
> this may hinder our ability to conduct a comprehensive internal
> investigation of any leak that may occur.
>
> I’m not exactly sure how this scenario fits within the policy of these
> lists, and would like to validate before we go ahead. ( Policy can be found
> here: https://oss-security.openwall.org/wiki/mailing-lists/distros )
>
> Would testing embargoed updates obtained from the distros and linux-distros
> lists on an external cloud infrastructure violate the terms of those mailing
> lists? Would testing embargoed updates on an external cloud infrastructure
> be contrary to the expectations of the vendors posting embargoed issues to
> those lists?
Let me add some cents here from SUSE perspective.
At SUSE we are common criteria certified, including the handling of
embargoed issues, which has similar strictness.
For CC we have to have processes in such a way that embargoed information
must not touch or be controlled by third party systems not within the
CC scope, which basically excludes everything not in the protected space
of our physical SUSE datacenter.
So we have real tight need to know, "must not leave any SUSE premise or
SUSE employee eyes" rules on embargoed security issues.
Relevant scope of information is really "anything where people can derive
knowledge from", and this includes security patched binaries (or also
rpm changelogs).
In regards to distros,
https://oss-security.openwall.org/wiki/mailing-lists/distros
is similar strict.
>From this page all info on distros is (at least) TLP:AMBER ( https://www.first.org/tlp/ )
and TLP:AMBER would exclude disclosing information outside of the need-to-know within your organization.
I understand that while some of the operators of the public clouds are also on
the distro lists, these are parts of very large cooperations and not the same
team as the intake PSIRT subscribed to distros.
So from my point I would suggest to exclude testing on third party public clouds.
Ciao, Marcus
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
