Would you hand a stranger the keys to your car with an unlocked briefcase filled with money and personal information open in the back? Probably not. So why would you have an insecure website sit in parking lot with the windows open? Well you probably wouldn't knowingly do that either. Yet virtually every Drupal site we've reviewed has been at least somewhat insecure. One of the primary reasons for this is, Drupal is at least somewhat insecure out of box, especially if your site isn't using the latest version.
In the first installment of this article, we'll discuss some of the basic steps you can take to at least roll up the windows and lock the car. Future installments will cover more advanced preemptive actions you can take such that potential hackers would likely move on to an easire target (with all apologies to the easier targets).
You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, . (Source: the Drupal security team)
Step 1: Upgrade Drupal Core, Contributed Modules, and Themes
This step seems the most obvious, but is often overlooked or postponed until a more "convenient" time. If you found out your infant's stroller had been recalled due to a critical safety issue, would you wait for a convenient time to take it back? Of course you wouldn't! Your Drupal website can only be as secure as your most insecure code. That being said, I can virtually guarantee you can pick three random Drupal sites and note that two of them are probably using outdated Drupal core code.
Why on earth then would you wait to apply critical secuirty updates to your Drupal site? If you have the proper Drupal upgrade workflow in place, there's really no excuse. Simply upgrade the development site, run your tests, then apply the update to the testing environment and have the content owners run their tests before applying the updates to production. If you don't have development and test environments, you'll want to backup you're database/files (always recomended regardless of the flow used), then apply the upgrade (preferrably using Git/Drush) to the production environment directly when your site's traffic is at it's lowest. Unless your site is incredibly simple, a proper deployment/test environment is highly encouraged.
More coming soon...