From our page in the handbook The security team's stated goals are:
- Resolve reported security issues.
- Provide assistance for contributed module maintainers in resolving security issues.
- Provide documentation on how to write secure code.
- Provide documentation on securing your site
I think we should revise these a bit with the first step being to brainstorm different goals. The second step (I'll start a new wiki) will be to synthesize all the goals into the highest priority goals we can actually commit to and actually want to commit to. At this point I'm fine listing out both general goals and specific goals. I started thinking of this after reading "Software Vulnerability Management" from Microsoft which is interesting reading throughout.
- Protect sites from attacks
- Minimize disruption for site maintainers
- Promote adoption of security best practices
- Educate maintainers and contributors
- Promote overall Drupal security
- Work in a manner consistent with values the Drupal community (transparency, a pragmatic mix of meritocracy & do-ocracy)
- Promote coordinated disclosure (until/unless the vulnerability is being exploited in the wild)
- Reduce the time-to-deploy as much as possible via easy update notification mechanisms, auto-update mechanisms, and reliable patches
Comments
A couple of fleeting thoughts
Education is the no. 1 sales tool. Effective, usable tools work too. Predefined, semi-automated workflows, guidelines, processes and procedures all work. Security best practices are often willingly adopted with a spoon full of honey because nobody wants their site hacked. The challenge is to sell it right. Vendor buy-in could certainly be a major factor. The companies hosting and maintaining distros have a chance to shine here.
I like Greg's ideas. Things
I like Greg's ideas. Things seem to be working, but there's room for improvement. Personally I prefer to give vendors 30 days to fix something before going the full-disclosure route, but I don't think that's necessary with Drupal as the security team seems to be on top of this and aren't trying to hide things. I'd love to see more visibility given to Drupal security - I consider it a job well done, but I don't think people weigh this (responsiveness of the security team, strength of default security config) enough in their mind when they pick a platform.
Grape's comments ring fairly true - I've been developing a secure Drupal hosting offering which I'm releasing out of beta test in the next week or two. How you think about operational security for a hosting provider is different than a company using Drupal - addressing module status/testing/updates across 100 sites is a different ball of wax. Just something to keep in mind.
Protected Industries
How you think about
Definitely and I think we want to keep in mind both groups: our ultimate goal is getting patches deployed and everything we can do to make that process easier for folks the better.
knaddison blog | Morris Animal Foundation
Blue sky...
I'll blue sky a bit here.
IMO one of the biggest sources of potential vulnerability is contrib. Core is well controlled and reviewed and has relatively few important issues that come up for a project this large. On the other hand, the contributed modules can be subject to XSS and friends if people forget to sanitize input, etc.
Perhaps one of the automated workflows for testing and reporting on potential issues in contrib? I have a good relationship with most of the major app security firms. Perhaps they would sponsor the use of a commercial assessment tool for this purpose, with a feedback loop to maintainers with potential issues. Similar to how the issue queue works with patch testing.
Libraries are another potential source of vulnerability and they could fly completely under the radar. IE, install wysiwyg+ckeditor, and then an issue comes up with the editor. A central libraries registry that was version-aware would be excellent and make that easier to manage. Makes it easier to tell if a patch or update is applied and/or available.
The update portion that starts complaining about out-of-date modules could also send daily emails to the admin with the same information. It could prompt someone to take action on a site where they may not log in every day.
The more we can do to stop both developers and site admins from shooting themselves in the foot based on lack of maintenance the better off we are.
FWIW I think the Drupal security team does a good job now, both with notifications and fixes.
The core update module
The core update module already has the functionality to notify you by email:
/admin/reports/updates/settings
Learn more at iRolo.net.
Sure, using automated tools
Sure, using automated tools seems like a great idea. In my experience generic automated tools don't find many holes in typical Drupal modules which creates a bit of a chore verifying the problem. Please do contact those vendors to see what they can provide!
Your feedback feels a little bit specific. If we try to talk about it more generically:
knaddison blog | Morris Animal Foundation