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 <[email protected]
<mailto:[email protected]>> 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: [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
