When thinking about the security of a site based on a system like Drupal, it's valuable to decide if your site is a gazelle or a bank; that can help you prioritize your actions related to security, and determine a strategy for securing your site. This article starts by explaining the bank vs. gazelle categories, and then gives ideas for how to protect your site depending on which kind you have.

The Asymmetrical Nature of Security

The first thing to consider when running a site is that as the site owner you have to be proactive in keeping your site 100% secure. An attacker only needs to find one vulnerability. This asymmetry creates one of the biggest challenges in running a secure site and often leads developers and operations teams to take extreme measures to protect their sites. It's not uncommon to hear about combinations of preventive and detective protection in multiple layers. Just one example I'm aware of: a site that uses a Denial Of Service prevention tool at the DNS layer, a CDN with a built-in web application firewall (WAF), and a WAF on the read-only-publicly-accessible staging server, all of which are in front of the actual content entry server which is only accessible on a private VPN. Lots of protection, right?

Are You a Gazelle or a Bank?

Let's start with the idea that your site is a bank, as it's the easier metaphor. A bank site, for the purposes of this categorization, is one where you really need to take extra efforts to secure your site because it contains highly valuable content someone might want to attack.

Examples of a bank site are:

• a bank (obviously);
• a high-profile corporate .com site;
• a well-regarded journalism site, especially with an active community of commenters;
• an e-commerce site;
• an intranet or extranet, especially if you store confidential material on it;
• a site such as a non-profit organization or NGO doing work under an oppressive regime.

In each case it should be obvious that it would be disastrous for the site owner to have a security vulnerability that opened the site to attack AND that there is something of value inside the site that would make an attacker analyze the site. If you are a bank then you have to be proactive in doing typical and additional security measures for your site.

The gazelle end of the spectrum is a bit simpler: the site has little explicit value to an attacker and is unlikely to draw their attention. I choose "gazelle" to describe it based on the Christopher McDougall quote:

Every morning in Africa, a gazelle wakes up. It knows it must outrun the fastest lion or it will be killed. Every morning in Africa, a lion wakes up. It knows it must run faster than the slowest gazelle, or it will starve. It doesn't matter whether you're the lion or a gazelle — when the sun comes up, you'd better be running.

While analogies are risky, I think this does a decent job of explaining how security works for common sites. Most widespread exploits are performed after there is already a release that fixes the vulnerability. A gazelle site doesn't have to worry about being the target of an attack; it just needs to be faster than the attackers by staying up to date with new releases from the "upstream vendor" (i.e., the broader Drupal community).

Examples of a gazelle site are:

• a personal blog with non-controversial material;
• a site for a restaurant that doesn't handle e-commerce;
• a "brochure" site where nobody can log in and all posts are public;
• a personal photo gallery site;
• a doctor's office site that accepts no user input and has no articles of advice for the world;
• a site with relatively few contributed modules that has a custom theme that only includes CSS files, and is based on a popular base theme.

In most of these cases there is very little risk of having the site hacked aside from the broad problems of being abused for distributing malware, having spam links in your site, etc. There is still some "private" content on these sites even if they don't think so: e-mail addresses of any users and some commenters, IP addresses of visitors, hashed versions of passwords (which are likely used on other sites). That information can be somewhat sensitive.

Of course these two descriptors are just end-points on a spectrum and some sites have elements of both, but it's useful to think of your site from these perspectives to consider how far you should be taking security.

Now that you have a sense of what kind of site you are, let's look at advice tailored to your situation.

Being a Good Gazelle: Secure Configuration and Keeping Up with Updates

This advice applies to gazelle sites and bank sites, but is critically important to gazelles.

When building your site, be sure to follow best practices in module selection and configuration:

• Use as few modules as possible, whether in core or contrib.
• When choosing contrib modules, choose stable, popular modules from well respected maintainers as a simple way to reduce risk.
• Drupal's default configurations are usually safe; if you change them make sure you know why.
• Confirm your site's configuration follows the tips for secure configuration.
• Use a tool like Acquia's Insight or the Security Review module to remove common mis-configurations.

Not to be overly analytical, but there are two key steps to updates:

1. knowing about them
2. doing them

There are several ways to learn about security updates for Drupal. You can subscribe to a broadcast channel like the RSS Feeds, @drupalsecurity Twitter stream, and the Drupal Security mailing list. Or you can use the update.module in Drupal core to get site-specific information. Both have value, but if you find the broadcast channels have too much noise about modules you don't use on your site, consider using e-mail notifications from within your site by going to Administration >> Reports >> Available updates >> Settings and adding your e-mail address. See image for a suggested configuration.

NOTE: Be sure cron is running on your site since this mechanism relies on cron running regularly to work. It's good practice to periodically login to the site to confirm cron is running and there are no updates.

To actually DO the updates, there are lots of choices. The most important thing is that you choose a method that is efficient for you and that you commit to doing it. Some suggested techniques:

• If you update your site via SFTP/SCP/FTPS, you can just download the latest version and upload it to your site.
• If your host offers updates for you (such as Pantheon does for Drupal core or Acquia's Remote Administration service does for core and contrib) then coordinate with your service provider to get updates.
• If you have shell access and like drush, consider using drush upc, drush updb, and drush deploy.
• If you have shell access and like revision control as a deployment mechanism, consider "git fetch && git reset –head" to make it as atomic as possible

Here are some tips to make the update smoother, regardless of your method:

• Have an automated backup plan for database, files, and code. One of the biggest problems is that the upgrade goes wrong and you need to restore from a backup. If you already have a backup being made automatically, then that's one less thing to worry about.
• Have a test environment where you can practice the upgrade.
• Have at least some automated tests, e.g. using something like Simpletest or the Selenium IDE, that ensure the highest priority workflows on your site still work after the test upgrade.

The Drupal Security Team releases security patches every Wednesday (at least it's Wednesday in many parts of the world, so adjust dates/times of day to your location). If you block out some time on your calendar for 15 minutes every Wednesday afternoon to review those releases you can spend that time confirming whether they affect your site and testing the deployment. Schedule an hour every Wednesday evening or Thursday morning to test out the release, review the release notes and project issue queue for recent bugs in the code, and then actually perform the update. Most weeks you won't need that time and you can go back to whatever you were working on, but some weeks you will need it and you'll be happy you've got it.

Being a Bank Site: Tips for Additional, Proactive Security

Okay, you've got a critical site with some content or resources an attacker is likely to want. You need to take additional steps to protect your site and add logging for auditing after the fact. It's also a great idea to get a security audit from an independent party. (Full Disclosure: my main job at Acquia is leading a team of people who perform security audits.) A security audit can be delivered by a peer developer, a "cyber-security" team in your organization, an external auditing company — or all three, depending on your level of risk and paranoia. An audit also provides a great opportunity for training. When you get the report or feedback from your peer about mistakes in a site or a module, use that as a point to further your knowledge about how to identify and fix those problems. Take a day or two to attend some security training.

Modules for Extra Security

There are three different lists of modules for extra security to draw ideas from. The most broad is the list of projects on drupal.org tagged with “Security”, which currently contains 400 items. The second is the Drupal.org handbooks on modules for security, which contains dozens of sub-pages full of installation and configuration instructions. The third, and most concise list is on DrupalScout.com.

One other source of contributed modules to protect your site is the the Hardened Drupal Project. This new project aims to be a study in how to combine some of the best contributed modules to add features that are expected in high security environments. In the first release the profile includes:

• Acquia Connector – for the Insight tool, which includes automated analysis of your site including security issues. These automated tests come from the years of experience of Acquia's support and security auditing staff.
• E-mail Confirm – to help ensure that users actually have access to any address they set in their account page.
• Login History – which is useful for users to know if their account has been hijacked and can be very useful in auditing a site that has been hacked.
• Mollom – to help block spam and brute-force attacks.
• Paranoia – to reduce the damage an attacker can do to the server if they are able to get access to an administrative account.
• Password Policy – to encourage users with advanced rights to use high quality passwords and change them often.
• Real Name and Username Enumeration Prevention – which, when used together, are a way to hide the username of users on the site. This helps reduce the chances of an account being brute-forced.
• Security Kit – which includes lots of features supported by some modern browsers to increase security of sites, such as preventing click-jacking by busting a site out of iframes.

Operations for Extra Security

Read your logs and save your logs. Monitor your site using tools like Nagios and Security Review module/Acquia Insight. What kinds of things should you be monitoring?

• The usual suspects: CPU, RAM, Network IO, e-mails sent, most popular file downloads, largest file downloads, most popular pages
• Drupal values: number of nodes, comments, users, terms, watchdog entries

Spikes in any of these indicators are worth investigating: was that spike in e-mails sent a result of a marketing campaign or a PHP execution vulnerability being abused for spam?

For more details on operations and monitoring, consider watching the video and reading the slides from "Keeping The Lights On — Operations and Monitoring Best Practices" at Drupalcon Denver.

Conclusion on Security

Before taking any steps to secure your Drupal site, you should first decide whether that site is a bank site — where tempting goodies are stored (bank and credit card information, for example) and will require the most extensive, proactive security measures — or a gazelle site (like a personal blog or restaurant-menu site), where security measures, while still well-maintained and up-to-date, can be less extensive. Once you figure out the kind of site you are you can move on to creating a plan for how to manage your site to match those needs.