Drupal Security

Drupal uses an open security model, to publish vulnerabilities, issue patches for known vulnerabilities and get independent audit of security issues using third party tools and its vast community.  With over 4000s contributed modules, the practices of Drupal.org, with it’s open security model, make it one of the most secure platforms to do business online and leverage community contribution toward a secure platform.

For the average Drupal site all that needs to be done is to keep its modules up-to-date and also the Drupal core version, which as of this writing is Drupal 6.12 and 5.18. Some deployments of Drupal have massive changes to the core, which should be an expecption managed by the client (that engages in the development effort, understands risks and alternatives)  – that if changes are made to the core or to a contributed module, then there is an strategy in place to test the site for various security issues, independently of Drupal.

Nate at Lulabot makes an interesting article that compares two software approaches to security – open and closed reporting of security. The independent Security advisory reporting site Secunia, for Drupal has 80 reports, while ExpressionEngine has 1, over a three year period.  Secunia specifically states "The statistics provided should NOT be used to compare the overall security of products against one another."

In his article, Nate shows three vulnerabilities - a simple XSS attack, unauthorized deletion of private message files, and allowing of arbitrary code execution (dangerous enough that he e-mailed the developers  at ExpressionEngine directly). Unsurprisingly, none of these issues were reported to Secunia.

Drupal believes in an open security policy. Because all the source code is available at all times, attempting to cover-up security problems by discreetly slipping it into an update isn't viable, because all the changes between versions can be tracked. The fixing of the bug usually happens through a special security process, where the security team is notified via e-mail. The problem is fixed in the source code, then an announcement is made as quickly as possible that an update needs to be applied.

This explains the 80+ vulnerabilities listed by Secunia on Drupal, because every security problem is handled in a public manner. Websites running insecure versions of modules are notified via the Update Status module, strongly encouraging administrators to update the module as soon as possible.

While there is nothing wrong with discreetly fixing bugs, doing so can make it more difficult to find the exact exploit. Since most web applications are delivered in a parsable scripting language (such as Perl, Python, PHP, JavaScript, ASP, etc.) the full source code of these applications is available to anyone that has ever installs the software. It only takes a single, well-informed user (hacker) to read through the code, and expose potential threats. The "security by obscurity" approach, while always dangerous, has even less effectiveness when the source code is readily available.

Dries in his blog makes the case for how every module maintainer can become responsible for managing their own security issues and publishing their own security advisories. By distributing the workload, we scale the security team to work within any size community, and we move the security team -- and Drupal's security model -- to the next level.

Here are list of 10 things to ensure a secure, scalable deployment:

1. Keep your Drupal installation on the latest Drupal release (i.e. have a plan to keep your production instance current)
2. Update modules to the latest version with patches as deployed
3. Manage the security privileges to anonymous and authenticated users under Drupal user management
4. Set the permissions on who can create accounts – is administrator oversight necessary prior to new account creation?
5. Create an independent security plan, if you are making modifications to Drupal core or significantly altering a module, where future releases cannot be updated
6. Ensure that the firewall settings for database server and the web server are setup to allow access only on an as needed basis
7. Run independent audits against your installation using products like Acunetix
8. Consider enabling mollom for spam management
9. Consider Acquia for production support of your instance
10. Alter passwords for Drupal user 1, super admins, database, ftp and other privelleged accounts once every 90 days at a minimum – create a security policy to manage this.

Overall, Drupal is one of the best secure CMS for the web. If Barack Obama is using it for recovery.gov which is a US government site, it does give this argument a rest, in my opinion.