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

Fri Mar 13 12:43:39 EDT 2015

Many thanks to the security team for considering the issues I raised in 
my e-mail and for opening up security team membership to a larger group 
of people. I certainly will be one of the people submitting my name for 
membership, and I hope people like Jeff Davis and Justin Hopkins, who 
have already shown interest in helping out, do the same.

However, I do want to encourage the security team to think about going 
further with transparency. I'm specifically referring to this bit of the 
proposal:
> it is not to be
> treated simply as a means of gaining early access to information about
> security vulnerabilities in Evergreen.

I totally understand why you want to restrict membership to just those 
who commit to helping out with solutions. However, it is very important 
for sites running Evergreen to know about their system's 
vulnerabilities, even if they are not in a position to help with a solution.

As an example, let me turn to an Evergreen feature that, as far as I 
know, doesn't have a security flaw, but does have a serious 
accessibility bug. If somebody sent out a message to the Evergreen list 
to ask about enabling auto-suggest, in addition to replying with 
information on how to configure it, I would also send along a strong 
word of caution given that the feature also makes your catalog totally 
inaccessible to users with screen readers - 
https://bugs.launchpad.net/evergreen/+bug/1187993.

Some sites may decide to enable autosuggest anyway, but they are able to 
make that determination with all of the available information at hand.

On the other hand, if I had been on the security team when the 
recently-fixed bug was still unresolved and somebody asked about setting 
up credit card processing, I wouldn't be able to give that person all of 
the information they needed to determine if it should be implemented. In 
fact, relaying that information, even if it were in confidence to an 
Evergreen user I trust not to exploit the bug or share the information, 
could result in my immediate expulsion from the team.

This proposal will generally reduce the gaps between the haves and the 
have-nots (those who have information about security flaws and those who 
do not) in our community. However, it will still leave a lot of 
have-nots behind. I think large Evergreen sites, those that represent 
large consortia or big county library systems, are in the best position 
to have people who can contribute to security processes and, therefore, 
qualify for membership on the team. I suspect that what we will 
ultimately find is that larger Evergreen sites will be more likely to 
know about known security flaws while the small, single-library sites, 
will be more likely to be left out of the loop. In fact, I can't help 
but notice that the three non-security-team people who have participate 
in this discussion thus far are, indeed, representing large consortia.

As a librarian, eliminating gaps between the haves and have-nots is very 
important to me, so this resolution does leave a bit of bad taste in my 
mouth.

It could be that expanding the security team and re-focusing on 
processes will lead to more timely resolution of security bugs, in which 
case, my concerns about more widespread disclosure would be moot. 
However, I remain skeptical at this point.

Thanks for listening!
Kathy

On 03/12/2015 04:53 PM, Galen Charlton wrote:
> Hi,
>
> On Wed, Mar 4, 2015 at 10:46 AM, Kathy Lussier <klussier at masslnc.org 
> <mailto: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 <mailto: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

-- 
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
klussier at masslnc.org
Twitter: http://www.twitter.com/kmlussier

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20150313/c662bee9/attachment.html>