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

[Dan Wells]

> 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.

If someone is willing to do any or all of that, then I’m assuming they are not joining “simply as a means of gaining early access to information about security vulnerabilities in Evergreen.”

So… they’re in!  ☺

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 5:03 PM
To: open-ils-dev at list.georgialibraries.org
Subject: Re: [OPEN-ILS-DEV] Questions about security bugs/process

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<mailto: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<mailto: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/db69e7b9/attachment-0001.html>