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

[Justin Hopkins]

I think that the proposal put forward by Galen, and now having been 
slightly refined is pretty solid. That said, I'll share the model of 
another open source community that I'm fond of:

https://www.drupal.org/security-team

You'll see that the Drupal team has hit on a lot of the same points as 
we have in our discussion so far. The one thing I'd highlight is the 
disclosure policy:

" The security team follows a Responsible Disclosure policy: we keep 
issues private until there is a fix OR until it becomes apparent that 
the maintainer is not addressing the issue in a timely manner. Public 
announcements are made when the threat has been addressed and a secure 
version is available. When reporting a security issue, observe the same 
policy. Do not share your knowledge of security issues with others."

The definition of "timely manner" is probably flexible and would depend 
on the severity of the problem. I'd imagine that the Evergreen security 
team could reach a consensus on what is appropriate for each issue.

Justin

On 3/16/15 7:59 AM, Galen Charlton wrote:
> Hi,
>
> On Fri, Mar 13, 2015 at 5:02 PM, Kathy Lussier <klussier at masslnc.org 
> <mailto:klussier at masslnc.org>> wrote:
>
>     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.
>
>
> One thing to consider is that a frank discussion of how to fix a 
> security bug will necessarily involve discussing how it can be 
> exploited, and sometimes even writing code that exploits the bug.  For 
> that matter, sometimes a report of a security bug will be accompanied 
> by a sample program that exploits it.
>
> Consequently, I am not in favor of opening up the security team to 
> every person, trusted or otherwise, who simply wants information about 
> potential vulnerabilities -- the more folks who have access to 
> exploits, the higher the chances that an exploit will be released 
> prior to the fix.
> This is why the proposal strongly emphasizes that members of the 
> security team should be on it to actively work on fixing bugs.
>
> On the other hand, Evergreen sysadmins have a very legitimate interest 
> in keeping their systems protected.
>
> How to square the circle?  In my view, we members of the security team 
> should adopt a procedure for handing security bug reports that includes:
>
> - faster turnaround on initial reports
> - a preference for classifying issues as *public* security issues 
> rather than private ones
> - a commitment to publishing within (say) 72 hours to open-ils-general 
> announcements that explain how to mitigate a security issue that has 
> been reported, though in some cases the nature of the bug may need to 
> be kept back until a fix is available.  This commitment probably can't 
> be absolute, as some security issues are such that simply describing 
> the bug is enough to suggest an obvious way to exploit it, but 
> exceptions should be rare.
>
> 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

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