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 <[email protected]
<mailto:[email protected]>> 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: [email protected] <mailto:[email protected]>
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
[email protected]
Twitter: http://www.twitter.com/kmlussier
