[OPEN-ILS-DEV] Questions about security bugs/process
Kathy Lussier
klussier at masslnc.org
Fri Mar 13 17:02:43 EDT 2015
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:open-ils-dev-bounces at list.georgialibraries.org] *On Behalf Of
> *Kathy Lussier
> *Sent:* Friday, March 13, 2015 12:44 PM
> *To:* open-ils-dev at list.georgialibraries.org
> *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
> <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 <mailto:klussier at masslnc.org>
> Twitter:http://www.twitter.com/kmlussier
--
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/ef6fc8a4/attachment-0001.html>
More information about the Open-ils-dev
mailing list