"This article was originally posted on Pantheon’s blog. Pantheon is a website management platform for Drupal and WordPress."
Your website will be hacked. Your defense in depth security strategy will determine how severe the damages are.
This was the basis of “Defense in Depth: Lessons Learned from Securing 100,000 Drupal Sites”– a session presented by Nick Stielau (Pantheon), Chris Teitzel (Cellar Door Media), and myself (Townsend Security) at DrupalCon 2015.
No company wants to see their name in the headlines for a data breach. A breach can mean loss of money (lots!), loss of customers, and loss of jobs. Data breaches are a very real thing and aren’t a matter of if, but when. As a Drupal developer, building security into web sites and applications needs to be a priority from the beginning, not something that can be “saved for phase two."
If the business risks aren’t convincing enough, we found that nearly everyone in our DrupalCon 2015 session fell under one compliance regulation or another – sometimes multiple. Take colleges and universities for example (a group that represented a large segment of the room). They often fall under PCI DSS because they process payments with credit cards; HIPAA because they have a student wellness center; and FERPA simply because they are an educational institution.
As a security company, one problem that we often observe is that developers don’t always know what information needs to be protected (or that they need to protect anything at all). Sensitive data extends beyond the obvious credit card or social security number. Personally Identifiable Information (PII) now includes information such as (and not limited to):
And hackers are great aggregators, so even losing what seams like trivial information can have magnitudes of impact. By knowing your first pet’s name or your mother’s maiden name, hackers are well on their way to hacking your account or ultimately breaching your web site.
“My client isn’t asking for security.” They might not be, but a good developer would inform their client of their risks and requirements (and budget impacts) and put all the proper security controls in place. In the event of a breach, the client is ultimately responsible but you can be sure that they will be pointing fingers at you and asking why their site wasn’t secure. As the developer, you don’t want to have a breached site tarnishing your reputation. When in doubt, err on the side of more security rather than less.
In the past, security has had a reputation for being difficult but things are getting easier. Still, there is no “silver bullet” and developers need to take a Defense in Depth approach to securing their Drupal sites. This means that multiple layers of security controls are in place.
Here are a few essential security tips that were discussed in our session at DrupalCon 2015.
1) Back It Up
Backups are going to save you. If something catastrophic happens to your site, you need to be able to roll back to the latest functioning version. (Depending on your situation prior to backup, there may be additional steps that you must take.) Every organization should have a backup process as part of their site operation guidelines. Additionally, the backups should be stored securely on a different server – if your server is breached, you can no longer trust any data contained on it and you want to be confident that you are restoring your web site from a secured backup. Services like NodeSquirrel can help.
2) Use Version Control
Use a source code management tool like Git so that in the event of a breach, you can view any files in your source that may be altered and revert your Git repo if needed. Git gives you a detailed control on what files have been changed, where they have been changed, and how they have been changed. While this may clear up many of your issues temporarily, you will want to follow procedure as if the site is still infected. Without source control you would have to go line by line through the entire Drupal core and contributed/custom modules to find what changes the attacker made.
3) Use Secure Passwords & Two Factor Authentication (2FA)
Do not repeatedly use the same password. When your email gets hacked, you don’t want that to be the same password that you use for logging in to your financial institution. Instead, use a tool like 1Password, LastPass, or KeePassX to create and manage unique passwords for all of your logins. Additionally, use Two Factor Authentication (2FA) whenever possible. Two Factor Authentication is something you know (password) and something you have (like a unique number sent to a cell phone or key fob). While it can be more cumbersome, it is easier to deal with than a data breach due to stolen credentials. Just ask Target.
4) Encryption
With nearly every compliance regulation calling for encryption, it is no longer an optional control. Luckily, there are several modules available that will leave you with less gray hair. Encrypt, Encrypt User, and Field Encrypt have made encrypting sensitive information easier than ever. The important thing to remember is, never leave your encryption key on the same server as your encrypted data, which leads us to…
5) Key Management
Encryption is said to be the hardest part of security and key management the hardest part of encryption (hackers don’t break encryption, they find your keys).
However, times are changing and key management doesn’t need to be difficult. Encryption, as well as API keys (PayPal, Authorize.net, MailChimp, etc.) should never reside on the same server as your Drupal installation. Rather, use an external key manager to manage your encryption and API keys. With modules like Key and Key Connection, key management is now almost “plug and play.”
There are more security tools available than ever, but it is up to the Drupal community at large to embrace best practices and take a defense in depth approach to data security. Just because a client didn’t ask for it, doesn’t make it optional. Breaches are not a matter of if, but when. What are you doing to prepare your site for the inevitable hack?