"Securing Your Installation" section of Installation Guide could cover ongoing security, advisories, private discussion

[pdurbin]

There's already a "Securing Your Installation" section of Installation Guide at http://guides.dataverse.org/en/4.4/installation/config.html#securing-your-installation but its focus is installation time, not ongoing security.

How should institutions who run Dataverse be alerted that they should upgrade as soon as possible to new versions of Dataverse that have security fixes?

Both @Venki18 and @lwo have mentioned that perhaps there should be some sort of mailing list that they and others could subscribe to who are interested in security (I'm looking at you @donsizemore).

Should the mailing list be "announce" style where people can't reply? This would be the Dataverse team sending security advisories. If the list is private, perhaps a pre-release announcement could be made that a security hole has been found and that a fix is being tested. This would give sysadmins a heads up that they should upgrade soon, once the release comes out.

Should the mailing list be "discussion" style instead, where subscribers could privately share findings related to security, such as results from security scans? (These should absolutely be sent first to security@dataverse.org to open a private ticket as explained in CONTRIBUTING.md to start some tracking around the issue. This was originally discussed on the dataverse-community mailing list.)

Should there be a page at http://dataverse.org dedicated to security that the Installation Guide links to? That's really what this issue is about... what resources to link to about ongoing security, how to subscribe to advisories, etc.

First we need to decide if we should create any of the mailing lists or pages mentioned above. I'm sure others have ideas as well. Please leave comments here if you have any thoughts or suggestions!

[lwo]

I like the approach of the Drupal security board at https://www.drupal.org/security

Likewise, the IQSS could setup a read only, authoritative public page one can subscribe to. So
when a security issue arises via other channels (security@dataverse.org), the IQSS can prepare the fix and then use the page to describe the security issue, the versions affected and a date for when the fix is published; or if not a fix then ways to mitigate against the problem before it is repaired.

A date will give sysadmins time to plan in maintenance (so get people) and announce downtime.

[Venki18]

I too like the idea of having a security page where IQSS can detail the steps in plugging the hole if the patch is not available immediately and also if the user cannot upgrade to the latest version.

I wanted to mention about how Microsoft issues security bulletin but I liked the idea of Lucien Van Wouw.

Thanks Phil for asking.

Regards
Venki

On 22 Jul 2016, at 12:46 AM, Lucien van Wouw notifications@github.com wrote:

I like the approach of the Drupal security board at https://www.drupal.org/security https://www.drupal.org/security
Likewise, the IQSS could setup a read only, authoritative public page one can subscribe to. So
when a security issue arises via other channels (security@dataverse.org mailto:security@dataverse.org), the IQSS can prepare the fix and then use the page to describe the security issue, the versions affected and a date for when the fix is published; or if not a fix then ways to mitigate against the problem before it is repaired.

A date will give sysadmins time to plan in maintenance (so get people) and announce downtime.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #3215 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ASs_ciWDn0bf86jWuotToGM2WptieiU7ks5qX6J7gaJpZM4JR5Ra.

[pdurbin]

I still like this idea but people aren't exactly clamoring for it. Thanks for your feedback @Venki18 and @lwo . Closing.

[pdurbin]

"Open source’s comparative advantage is in security: security is among the the most important features when using any kind of software (86% extremely or very important)." http://opensourcesurvey.org/2017/

[pdurbin]

@djbrooke this is the issue I mentioned this morning.

[pdurbin]

@djbrooke as I mentioned, I'm thinking that as a first step, we could document our existing process somewhere around http://guides.dataverse.org/en/4.7.1/installation/config.html#securing-your-installation

[whorka]

I had some comments on app security updates from a SysAdmin perspective which I shared with @pdurbin, and he suggested I log them here:

• I like the idea of a security announcement (announcements only) mailing list.

  • A merged announcement+discussion list could work for small installations where the service admin is also responsible for security, but a separate announcement list will elevate the visibility of security announcements and would be more useful to larger installations with a separate SecOps or InfoSec team.
  • Email announcement is still the standard for security updates. See e.g. the Oracle quarterly patch updates for Glassfish et al. Also, there's evidence that Danny's previous email security announcement was taken to heart by its recipients; see e.g. Glassfish admin console directory traversal exposes file system resources jhu-sheridan-libraries/dataverse-ansible-role#1

• In-app security checks are also a popular way to announce updates (e.g. Chrome and Firefox). For web apps, I like the way that Jenkins does it: it periodically checks for updates in the background (both core and plugins), and if you log in as an admin it shows a notification area which informs you about available updates (and even gives you a 1-click upgrade option for all the installed plugins). The notification shows as a red icon at the top of every page near the "logout" link.

• How you announce updates is also a serious consideration. For instance, if you've been following the KRACK vulnerability, it was discovered months ago but kept under wraps to allow developers time to make patches. OpenBSD wasn't happy with this arrangement, however, and pushed out a patch early, which could have spilled the beans to the whole world. Now the discoverer says they won't be giving OpenBSD advanced notice in the future.

  • Targeted disclosures like this are the norm when disclosing vulnerabilities about other developers' products, but the same can apply when announcing vulnerabilities in your own product. Using Jenkins as an example again, they recently sent out an email to their security announcement list, giving all subscribed Jenkins admins a 1-week heads-up that there was a major security update. That was really helpful, since it gave us some time to plan ahead and schedule.

Hope that helps.