Thank you for your thoughts Dan.
To be clear, I don't think people are being excluded as a punishment,
and I understand perfectly that the intent is to decrease overall risk.
I also want you to know I'm not trying to assign blame on the time it
takes to fix security bugs. We are a small community with a lot of work
on our hands.
I'm also not advocating for broad alerts to the entire community
regarding security problems. I guess what I'm really saying is that, if
a trusted person from an Evergreen site wants to apply for access to the
LP security bugs simply to gain "early access to information about
security vulnerabilities in Evergreen," they should be allowed to do so.
I'm guessing there would continue to be some "have-nots" out there
because they never took the trouble to apply for access. But the option
would be available to them if they wanted to use it.
Second, by calling them “haves” and “have-nots”, this response seems
to indicate that there is some intrinsic advantage to knowing about a
security bug. I would argue that knowing about a bug and not being
able to do anything about it is actually a burden.
Oh, sure. Knowledge quite often is a burden for people, but I would
argue that information that places a burden on people is quite often the
information that is the most important for them to have, even if it
causes some discomfort.
I think I can highlight another area where we are assuming different
things. We probably have different thoughts on what kinds of activity
can lead to a solution. It's not just coding, testing, or helping to
publicize the security release. It might be putting pressure on a
support provider or on a developer community to get the problem fixed.
It could be pressuring the EOB to finally gain some traction in setting
up an emergency fund that could be used for security bugs. It could be
the thing that galvanizes someone to get more involved in the community
because they don't want to feel that burden anymore.
I want more people to feel that burden. It shouldn't just be placed on
the shoulders of our small developer community.
Have a nice weekend everyone!
Kathy
On 03/13/2015 02:32 PM, Dan Wells wrote:
Hello Kathy,
I appreciate the concern expressed here, and struggled a lot with how
to respond to the overall security problems. Perhaps it will help to
highlight a few places where we are assuming different things.
First, this response seems to assume that the average library will be
able to mitigate security issues if they know about them. In some
limited cases this might be true (e.g. don’t use credit card payments
if the settings can be compromised), but the majority of bugs will not
be simple to work around. It might make sense in some instances for
the security team to put out a broad but nonspecific alert which says
something like “a vulnerability exists in XYZ, please disable feature
if possible until a fix is developed”, but even that must be weighed
against inviting increased scrutiny and malicious intent.
Second, by calling them “haves” and “have-nots”, this response seems
to indicate that there is some intrinsic advantage to knowing about a
security bug. I would argue that knowing about a bug and not being
able to do anything about it is actually a burden.
The goal of the security policy is to attempt to lower the overall
risk to every interested party. It tries to include anyone the team
is confident can and will help, and exclude everyone else, not as a
punishment, but as the most viable and available means to actually
**decrease** their overall risk.
All that said, I do think we can try harder to err on the side of
being more open, and the team is currently reevaluating some of the
criteria for what kind of bug truly benefits from limited exposure and
what does not.
Sincerely,
Dan
Daniel Wells
Library Programmer/Analyst
Hekman Library, Calvin College
616.526.7133
*From:*Open-ils-dev
[mailto:[email protected]] *On Behalf Of
*Kathy Lussier
*Sent:* Friday, March 13, 2015 12:44 PM
*To:* [email protected]
*Subject:* Re: [OPEN-ILS-DEV] Questions about security bugs/process
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] <mailto:[email protected]>
Twitter:http://www.twitter.com/kmlussier
--
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
[email protected]
Twitter: http://www.twitter.com/kmlussier
