My site needs to be secure. How will you address this?

That's the essence of a question I got today. And it's not one that can be answered easily, because there's no such thing as a site being "secure." It's not an either/or question, it's really a "how much" type of question. How hot is it today? Let's take a look at the temperature -- hot for you may well be different than hot for me. I'm from Alaska, after all...

First let me answer by saying, "hot." Drupal, out of the gate, has a great security record. We have seen Drupal sites hacked -- but not cases where Drupal was to blame. The cases that come to mind were either due to (very) weak admin passwords, or an exploit uploaded to the server via FTP or another more vulnerable content management system.

Competitors like to point to the high number of Drupal security notices that get sent out, but fail to recognize that this is a good thing, for two key reasons:

1. The security notices cover ALL of the contributed modules that have a stable release on Drupal.org. There are thousands of them. Word Press, Joomla, and other content management systems also have thousands of third-party add-ons, but they don't get reviewed on any consistent basis by any single security team. Drupal, to my knowledge, is the only widely deployed system that regularly provides security notices of its add-ons for common security vulnerabilities.
2. The vast majority of Drupal security notices are for very minor issues. A huge number of them require some level of administrative access to exploit -- the general public can't just use them to break into your site. Drupal provides some excellent anti-attacker programming interfaces that make it easier to create secure modules than do it yourself. Security reviews often ding module authors for trying to do their own data sanitization, instead of using the accepted, hardened, tested Drupal functionality.

In short, by running Drupal you're well ahead of the curve when it comes to having a secure site. We've seen far more hacked Joomla and Word Press sites than Drupal.

But security doesn't stop with the application. Perhaps more important, you need to consider the hosting environment. Having the most secure Drupal site ever won't keep the bad guys out if your web designer uploads a design change using FTP at the local coffee shop. Because FTP allows you to upload code to the server, and because FTP passwords can be VERY EASILY SNIFFED, we refuse to run FTP on our servers. Anywhere. FTP is still the standard way of uploading your site to a shared host, and much better alternatives have been around for well over a decade now. This to us borders on insanity.

For us, for regular every day sites we manage, we think the minimum precautions that need to be done include:

• No plain-text access to the server.
• Strong passwords on all admin accounts.
• No 3rd party access to a server (which means, we don't allow customers direct access to our shared servers -- only Freelock employees and designated vendors can access files directly on the server).
• Historical, redundant backups and file integrity checking to detect files that change.
• Web server cannot write to locations where programs are allowed to execute.

But that's just the baseline. Two other questions come to mind:

• What is the "street value" of the data you need to store?
• What risks are you trying to mitigate?

We've locked all the doors, and drawn the blinds. A teenager looking to make trouble in the neighborhood is far more likely to go for the house with the unlocked backed door. There's far more teenagers out there trying to open doors just to see if there's something there to steal, than those out to get you in particular.

On the other hand, if you have a $2000 plasma tv sitting in your window, or a briefcase of cash lying around, suddenly you might be a bit more of a target. The thief may try to pick your lock or break a window instead of just checking to see if it's unlocked.

Some data is just more valuable than others. If you have a database with 50,000 credit card numbers, with corresponding name and address info, you're a target if the wrong people realize it. Suddenly you have a bit more of a security problem on your hands -- you have some high value data. Likewise, a database with social security numbers and other data that might allow somebody to forge an identity has real value on the black market. Or blueprints for crowd control weapons. Anything like that? If so, you're going to need to spend a whole lot more for security. And still, even the CIA gets hacked.

So when deciding how much security you need, think about what's at risk. If it's credit card numbers, there's a relativly simple thing to do: don't store them. Our e-commerce sites encrypt credit card numbers during the transaction, and delete them once they've been transmitted to the merchant account. That means we don't have a big list of credit card numbers on any of our servers -- making us much less of a target. We still have to maintain a secure environment to prevent somebody from installing software that might eavesdrop on the connection after it's been decrypted, but that's a lot harder to do than to snoop around a bunch of files after you've compromised a server. Which means if you're trying to steal a bunch of credit card numbers, you have to do a lot more work for a lot less reward. Easier to go someplace else.

So if you're concerned about security, know that when you work with us, we've got your back. We will warn you if we think you are taking unnecessary risks with your data, we will do everything we can to protect the sensitive things you need to store, and if you have any questions, we'll happily discuss what we're doing to keep your site safe, and what other things could be done to further protect your data.