[OPEN-ILS-DEV] Questions about security bugs/process

[Galen Charlton]

Hi,

On Wed, Mar 4, 2015 at 10:46 AM, Kathy Lussier <klussier at masslnc.org> wrote:
> I really think we need to increase the transparency of these bugs
> without compromising the security of our systems in the process. Any
> site running Evergreen in a production environment should have a right
> to know when a known security bugs affects their system, especially
> when it comes to those bugs that have been left unresolved for many
> months.  Maybe we could allow one trusted person from each site
> subscribe to security bugs or maybe there are other methods for
> sharing this information for Evergreen sites. I would like to hear
> thoughts from others on how we can improve transparency.

One avenue towards improving the transparency of the security process is to
ensure that there is a clear process for joining the security team.  I am
putting forward the following definition of the team and criteria for
membership, and I am issuing a public call for interested people to join
the security team:

--- BEGIN ---
The purpose of the Evergreen security team is to review reports of
specific security flaws in Evergreen, to write and test patches to fix
or ameliorate those flaws, and to perform security releases.

Membership in the Evergreen security team is available to individuals
who meet all of the following conditions:

(1) They request membership.
(2) They promise to adhere to the consensus of the security team
regarding when to publicly disclose security issues.
(3) They promise to maintain the confidentially of discussions on the
open-ils-security mailing list and security bugs on LaunchPad.
(4) They promise to provide assistance to the security team. Such help
can take the form of provide substantive commentary on reported
security issues, writing patches, testing and reviewing them, writing
security documentation, and assisting in the process of preparing and
publicizing security releases.
(5) They operate or support the operation of at least one production
Evergreen system known to at least one other current member of the
security team.
(6) They already have access to various tools required to
participating in a meaningful fashion, to wit: a registered account on
LaunchPad and at least one public key registered with the Evergreen
Git server.
(7) The current members of the security team come to a consensus to
admit the new member. The security team reserves the right to reject
applications, and will explain their reasoning to the applicant if
they should do so.  Applications will be reviewed promptly.

Membership applications may be made by contacting one of the current
security team members; a list of the current members' names will be
maintained on the Evergreen wiki.

Violations of the promises in (2) and (3) may result in immediate
expulsion from the security team.

Membership in the security team belongs to individuals, not
institutions.  Membership comes with an expectation that each member
will actively participate at least part of the time; it is not to be
treated simply as a means of gaining early access to information about
security vulnerabilities in Evergreen.

The team membership list will be reviewed annually; members who have
not made substantive contributions to the team may be dropped from the
list, but are free to apply to rejoin.

Members of the security team will have access to the following
restricted resources in order to carry out their work:

- membership in the private security group on LaunchPad, which will
allow them to see and
- a subscription and access to the private archives of the
open-ils-security mailing list
- access to the Git repositories hosting security patches in progress.
--- END ---

This can also be found at
http://evergreen-ils.org/dokuwiki/doku.php?id=dev:security#security_team

This proposal and invitation is offered in the hope that it will be a means
for the security team as a whole to do better, but I recognize that it's
also only a first step.  It does embody certain assumptions, including:

* some security issues need to be kept private for a period so that a fix
can be released in an orderly fashion
* a group of volunteers can manage private security issues in a timely
fashion -- and this is where the security team has fallen down
* an injection of one or more fresh volunteers can help revamp the group
and its processes

Each of these assumptions is debatable.  While the current members of the
security team who have participated in the discussion around this proposal
have either assented to it or in one case, expressed neutrality, it does
not, I think, represent the result of an enthusiastic consensus.
Nonetheless, I think it is a way forward.

Regards,

Galen
--
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20150312/c5b4d767/attachment.html>