+1.800.357.1019

+1.800.357.1019

Feel free to call us toll free at +1.800.357.1019.

If you are in the area you can reach us at +1.360.359.4400.

Standard support
6:30am - 4:00pm PST, Monday - Friday, Free

Premium support
If you own Townsend Security 24x7 support and
have a production down issue outside normal
business hours, please call +1.800.349.0711
and the on-call person will be notified.

International customers, please dial +1.757.278.1926.

Townsend Security Data Privacy Blog

Talking Drupal Security: Encryption, Key Management, & Defense in Depth

Posted by Luke Probasco on Aug 8, 2017 8:15:27 AM

Securing data in Drupal is a hot topic that Townsend Security’s Luke Probasco, Lockr’s Chris Teitzel, and Mediacurrent’s Mark Shropshire (Shrop) talk about often, including at DrupalCons, camps, blogs, and our upcoming Security By Design - An Introduction to Security webinar.  They recently met up on Mediacurrent’s Dropcast podcast to discuss modules for protecting private data in Drupal, tools developers can use to build secure sites, as well as how businesses should be thinking about security.

Security By Design WebinarShrop: Let’s talk about encryption and key management.  From your perspective, how does encryption work in Drupal?  What do you get out of the box with Core and what types of encryption should be utilized?

Probasco: First off, encryption is not in Core, but we did just see someone create an issue, which is a very good thing.  One thing that I often say is, Drupal is being brought in to a lot of enterprise projects and their security teams don’t really care what CMS is used, as long is it meets their objectives and it is secure.  Luckily, I think that Drupal really has a lot of security advantages.  I mean, we have a whole security team and a suite of security modules (of which Townsend Security and Lockr are big sponsors of), so I think we are doing a lot of really good things to give Drupal a strong security posture.

Teitzel: And to take a step back in the past, take a look at where we’ve come from.  We used to not have ANY tools for developers to implement encryption properly.  When we analyzed the technology that was out there, we realized that there were some serious gaps akin to tapeing your keys to the front door of your house and hoping that nobody breaks in.  So, out of the box, Drupal doesn’t have any encryption at the field level, or for files, or anything like that.  We, along with a whole band of community members, said “we need to do this right” and not only implemented a robust framework around making encryption strong within Drupal, but also saying, “How are we managing encryption and extending it out?”  Encryption within Drupal is no longer the expensive, complicated project that it used to be.

Shrop: So it sounds like encryption is way easier to set up.  When people say, “I don't have anything I need to encrypt.  Why do I need to worry about encryption?” I think think they are missing a valuable point.

Probasco: I think there is a lot of misunderstanding about what needs to be protected.  It is pretty obvious that if you have a credit card or social security number, that needs encrypted.  When you get to the concept of personally identifiable information (PII), a lot of the things that you wouldn’t think would be considered PII actually are.  For example, when you combine things like an email address and someone’s city, you can pretty easily form the identity of a person.  Think about your most basic marketing site that offers a white paper where someone gives up their email address and phone number and ZIP code.  It is imperative to be protecting this type of information.

Shrop: Yeah, that makes a lot of sense.  I think a lot of times, just turning it around and saying “Would I want this piece of PII out there on me?” would be huge.

Teitzel: Another thing to keep in mind is that small businesses and sites actually need to be just as concerned as the big guys.  They are actually considered more of a target because they are often less attentive to security.  Small business sites are hacked more often and in larger numbers, and so for us, if Drupal is really going to grow up, and the enterprise world is demanding encryption, we need to make it dead simple.

Probasco: You made an excellent point.  A lot of people say “I’m too small to be a target.”  Symantec recently did a study that showed mid-sized companies are actually a greater target because they typically don’t have a lot of the controls in place to prevent a data breach.  You should never have a mindset of “I’m too small” or “Nobody is paying attention to me.”

Shrop: A good point on that.  That is true for so many of the technologies that we are concerned with.  You could say the same thing for accessibility or performance.  All these things are important for everybody, no matter their size.  So what does it look like to implement encryption at the field level?

Teitzel: We have simplified the process down into a series of modules that are separate, in order to remain lean and extensible in what they do, but they really all walk hand in hand.  In order to implement encryption at the field level, you will need to download the Encrypt module (the main core of encryption), the Key module is going to be managing all of your encryption keys, and the Field Encryption module.  The three of those together will give you the basics that you will need for encryption.  The one caveat there is that in Drupal 8, you now are required to use the Real AES module.  We are also really in support of what those guys are doing with strong, standards based encryption.  However, these modules are limited in that the keys you are using to encrypt private data have to sit somewhere that Drupal can access – typically the database for the file system.  That is where Townsend Security and Lockr come in.  We say, “we are going to take your keys and store them with an external key manager.”

Probasco: One that that I would also like to add is, it is a security best practices to be storing and managing encryption keys separate from the data that they protect.  It isn’t “Oh, that would be nice” or “that’s a good idea” – industry wide, key management is a fundamental security practice, which Drupal is now able to adopt.

Teitzel: So we built all the encryption and key management modules to be extensible and easy to use.  When you start to talk about encryption, people’s eyes glaze over because it is a seemingly very difficult process and it shouldn’t be, which has been our goal.

Shrop: Something else that I wanted to bring up about encrypting fields, I know that you are talking about using the Real AES module.  I noticed that you didn’t mention coming up with your own encryption scheme.

Teitzel: No, not at all.  Real AES implements the Defuse PHP encryption library, which really just is AES wrapped in a full-proof way to ensure that you are implementing it correctly.  The core of encryption relies on the ability to make un-encrypting data impossible without the key, which is why it is important to be proven and based on industry standards.

Probasco: We have been talking a lot about encryption and key management, which is a natural segue to API key security.  Your APIs are keys within Drupal as well and need to be considered as sensitive data.  Chris, I know you have several examples of what can happen when your API keys are compromised.  When I say API keys, I mean like your link to Amazon S3 or MailChimp.  How often do we here people say “I’m not going to handle credit cards so I will use PayPal”, but what happens when those APIs are stolen?

Teitzel: When we were building the Key module we were sitting in a coffee shop in Seattle and I had this epiphany moment where I said “Why are we only looking at encryption keys?”  We have all these other secrets in Drupal that we are trying to manage.  Why not centralized API keys as well and provide the same level of security to those as we would encryption keys.  Take a look at OneLogin, which a good number of enterprises use for single sign on.  A single AWS key brought down their entire system.  Hackers were able to get in and get user data, resulting in a massive breach.  Many times the data that you are trying to encrypt is behind API keys, so it is a security hole that many people just don’t have plugged.

Shrop: One misperception out there is, once I do a site audit, my site is secure.

Teitzel: That would be great!  Security is an ever-changing landscape.  There are continually new exploits coming out.  Security is not a one-time deal, but a continual process.  Unfortunately, it is a bolt-on after the project is done or about to be shipped.  One of my favorite regulations is the European General Data Privacy Regulation (GDPR), which requires security by design.  If you have a breach, you have to show that you were taking security seriously during design and implementation, not just after the fact.  I think that is a concept that not a lot of people do right now.

Probasco:  Exactly.  GDPR is a serious regulation.  They aren’t just saying, “if you have a breach you will have a small fine.”  They are actually attaching a percentage of your company’s overall revenue.

Shrop: A lot of small companies that you are talking about are vulnerable, but aren’t able to implement all security controls because of budget.  What do you say to companies that think they are just priced out of security?

Teitzel: Shameless plug here, but that is exactly why we created Lockr.  There is a free tier of Lockr that is there for small businesses.  We did that because we feel that everybody should be able to take first steps towards encrypting private data.  By taking budgetary constraints out, we are enabling small businesses to learn about implementing security.  And there are other free services out there for small companies as well.  There are so many other services out there with free tiers as well, that it is possible for small sites to piece together security without breaking their budgets.

Probasco:  I’d also like to give a plug to the project that Shrop is working on – Guardr.  I first learned about it at DrupalCon Baltimore and was just amazed at the cool stuff he is doing.  Guardr is allowing sites to start with a strong security foundation (including modules and settings) that will position them to grow and keep data safe.

To hear this interview in it’s entirety, download Mediacurrent’s podcast “Security!” and hear Luke Probasco from Townsend Security, Chris Teitzel from Lockr and Mediacurrent’s Mark Shropshire to talk about all sorts of security concepts and improvements with Drupal, including, Guardr.

Security by Design Webinar

Topics: Drupal

Drupal Encryption: Protecting Private Data

Posted by Luke Probasco on Jul 24, 2017 1:54:25 PM

Cloudflare.  HipChat.  OneLogin.  The list goes on – and that is just companies that have suffered breaches so far in 2017.  Businesses, large and small, are losing vast amounts of intellectual property (IP) and customer personally identifiable information (PII) to data breaches.  While there is no “silver bullet” to data security, there is one tool that stands out among the rest – encryption.  Encryption can mean the difference between a public breach notification (when private data is lost) and keeping the incident to yourself (if data is encrypted, you didn’t lose any decipherable information).

Security By Design WebinarTo protect data in Drupal, encryption is deployed at the application level with modules, rather than at the database level.  This makes it much easier to encrypt specific fields, forms, user-related data, or files.  It is important to note that Drupal Core does not natively support encryption and that developers will need to look to contributed modules to secure private data.  Let’s first look at the two primary reasons for encryption.

Why We Encrypt: Protect Brand/Customers

The most recent Ponemon Cost of a Data Breach Study shows the average cost of a lost or stolen record to be $141.  This cost includes loss of customers, remediating the breach, and post data breach costs – ultimately affecting a business’s bottom line and in some cases, their ability to keep doors open.

Why We Encrypt: Compliance

While we expect businesses to deploy encryption whenever sensitive data is present, unfortunately, they often need another budge in the right direction.  That budge is handled by compliance regulations.  Both public and private organizations fall under compliance.  Compliance regulations include PCI DSS (if you take credit cards), HIPAA (healthcare), FFIEC (finance), FERPA (education), etc.  Further, aside from industry specific regulations, many states have their own data security mandates.

What Should We Encrypt?

Organizations starting an encryption project always have this question on their minds. It is a simple question, but can be hard to answer. Generally speaking, you should encrypt any information that alone, or when combined with other information, can identify a unique, individual person. This is called Personally Identifying Information, or PII. This should be your starting point, but you may need to address other information depending on the compliance regulations you must meet.  Examples include:

Social Security Number

Student ID Number

Email Address

Student Educational Records

Health Records

IP Address

Phone Number

Birth Date

 

Excuses, Excuses, Excuses

No more excuses.  If you aren’t encrypting private data, you are not applying due diligence.  Yes, learning security best practices may be something new for site developers, but by not evolving your skills, your sites and clients will be left vulnerable when bad actors come knocking.

“My clients aren’t asking for encryption.”

It may be true that your clients aren’t asking specifically for security, but they are paying you for it. Your clients expect site security, just as they expect you to anticipate and address their needs in other areas of site development. Further, by not implementing appropriate security controls, if there is a breach, you can be liable.

“I’m too small to be a target.”

It is often a surprise to small and medium sized businesses that they are actually considered a greater target than large enterprises. Why? Because hackers know that SMBs are an easy target. Symantec recently published a report confirming that three out of five cyber-attacks target small and midsize companies.

“There is no budget.”

Encryption has a reputation for being costly and causing severe impact on performance.

Today this reputation doesn’t hold true, and these common fears can, in fact, get in the way of implementing a strong security solution.

Encryption in Drupal

As mentioned earlier, Drupal Core does not natively support encryption and developers will need to look to contributed modules to secure private data. The following modules will help you get started on the right foot.

Encrypt

Encrypt creates an API for performing symmetric encryption and decryption of data within Drupal. It provides a plugin-based system for encryption methods and key providers, allowing the ability to choose how to encrypt data.

Real AES
Real AES provides an encryption method plugin for the Encrypt module.  This module offers authenticated encryption based on AES-128 CBC with a HMAC.

Field Encryption
Field Encryption encrypts Field values when stored in the Drupal database.  This module is useful for fields that site visitors may input sensitive data into.

Encrypted Files
Encrypted Files allows Drupal to encrypt files that users upload and decrypt files for download, keeping the unencrypted versions of files from ever being stored on disk.

Key Management in Drupal

Most users who are currently encrypting sensitive data are storing the encryption key locally in either a file on the server, in the database, or in Drupal’s settings file. None of these methods meet data security best practices or compliance regulations such as PCI DSS, HIPAA, etc.  In order to truly protect encrypted data, businesses need to also store and manage their keys with an external key manager.  The Key module can help with this.  Key provides the ability to manage encryption keys and define how/where keys are stored, allowing sites to meet regulatory or compliance requirements and security best practices.

At the end of the day, it is important to remember that there is no silver bullet to data security and you should take a defense in depth approach to protecting your or your clients’ web sites. Townsend Security’s dedicated Alliance Key Manager is in use by over 3,000 customers worldwide and is the only dedicated key manager with Drupal integrations. Alternatively, Lockr is the first hosted API & encryption key management for modern content management systems like Drupal and WordPress, providing affordable solutions for all sites to properly manage access and encryption keys.

Security by Design Webinar

Topics: Key Connection for Drupal, Drupal

Speaking Words of Wisdom, Let it Key

Posted by Luke Probasco on May 27, 2016 8:57:00 AM

"This article was originally posted on Drop Guard’s blog. Drop Guard automates Drupal updates to ensure security of your site within minutes after a security release."


What Data Needs To Be Encrypted In Drupal?

Encryption has gone mainstream. Thanks to the numerous data breaches (781 during 2015 in the U.S. alone) data security is a top priority for businesses of all sizes. Semi-vague language like “we ensure our data is protected” from IT teams is no longer good enough to satisfy the concerns of business executives and their customers. CEOs are losing their jobs and companies are suffering financial losses/fines that reach into the millions of dollars when poorly encrypted or un-encrypted data is lost.

Fortunately, the recent 2016 Global Encryption Trends Study shows that there is a growing shift with businesses developing an encryption strategy – Germany (61%) and the U.S.(45%) are in the lead with the primary drivers including:

  • To comply with external or data security regulations
  • To protect enterprise Intellectual Property (IP)
  • To protect information against specific identified threats
  • To protect customer personally identifiable information (PII)

Before getting too much deeper, let’s first clarify a common misperception. Yes, while the big brands are in the headlines, they aren’t the primary target of hackers. A recent threat report from Symantec found that three out of every five cyber-attacks target small and midsize companies. These businesses are targeted because they have weaker security controls and have not taken a defense-in-depth approach to security. Even though some of these businesses may be encrypting their data, chances are they are not doing it correctly.

How do you then define what properly encrypting data involves? First, it means using an industry standard encryption algorithm such as the Advanced Encryption Standard (AES), alternatively known as Rijndael. Standards are important in the encryption world. Standard encryption algorithms receive the full scrutiny of the professional cryptographic community. Further, many compliance regulations such as PCI-DSS, HIPAA/HITECH, FISMA, and others are clear that only encryption based on industry standards meet minimal regulatory requirements. Standards bodies such as NIST, ISO, and ANSI have published standards for a variety of encryption methods including AES.

But wait, my web sites don’t collect credit cards or social security numbers. Why should I care about encryption?

You would be surprised at what can be considered Personally Identifiable Information and should be encrypted. PII now includes information such as (and not limited to):

  • Email address
  • Password
  • Login name
  • Date of birth
  • Address
  • IP address

For a moment, pause and consider how many websites you have built that collect this type of information. As you will quickly realize, even the most basic marketing websites that collect a name and email address should deploy encryption.

Key Management
The second part of properly encrypting data involves key management and understanding the important role that it plays. Your encryption key is all that stands between your data and those that want to read it. So then, what good is a locked door if the key is hidden underneath the “Welcome” mat?

Security best practices and compliance regulations say that encryption keys should be stored and managed in a different location than the encrypted data. This can present a challenge for Drupal developers as the standard has been to store it on the server outside the web root. While there is a suite of great encryption modules (Encrypt, Field Encryption, Encrypted Files, etc.), they unfortunately all stash the key in similar unsecure locations – in the Drupal database, settings file, or in a protected file on the server. Once a hacker compromises a site, they can then take the encryption keys and have access to all the sensitive data.

“Let it Key”
Let’s now bring this back to one of my favorite songs by the Beatles to paraphrase a line (excuse the pun), “Speaking words of wisdom, let it key.” The Key module provides the ability to manage all keys on a site from a singular admin interface. It can be employed by other modules (like the aforementioned encryption modules) to offload key management so the module is not responsible for protecting the key. It gives site administrators the ability to define how and where keys are stored, which, when paired with the proper key storage modules, allows the option of a high level of security and the ability to meet security best practices and compliance requirements. Drupal developers can now easily integrate enterprise level key management systems such as Townsend Security’s Alliance Key Manager or Cellar Door Media’s Lockr (both of these companies have been heavy sponsors of encryption module development).

Enterprise level key managers do more than just store keys outside of the Drupal installation. In addition to safeguarding encryption keys, they manage them through the entire lifecycle—from creation to destruction. Further, a key manager will allow for:

  • Key naming and versioning
  • Key change and rotation
  • Secure key retrieval
  • Key mirroring
  • Key import and export
  • Password and passphrase protection
  • User and group control for key access 

In addition to providing NIST-compliant AES encryption and FIPS 140-2 compliant key management, an encryption key manager also allows administrators to store their API keys outside of Drupal. Private API keys are frequently used within Drupal by services like Authorize.net, PayPal, MailChimp, etc., and all these modules store their keys in the database in the clear. If your site gets hacked, so does access to the services that you have integrated into your site. For example, if your Amazon S3 API key were in your stolen database, hackers would have access to your entire offsite S3 storage. Consider how detrimental it would be for a client to find out that a hacker has gained access to their PayPal account - after all, they were using PayPal because they didn’t want to deal with the security risks and liability of hosting their own payment processing.

By routing all keys within Drupal to a central key management location, it is now possible to have total control over all encryption keys, API keys, external logins and any other value needing to remain secret. This gives developers and site builders a useful dashboard to quickly see the status of every key, and control where it is stored.

Summary
By now, I have hopefully conveyed the importance of encryption and key management. Everyone from developers to site owners need to understand the importance of data security and the proper steps they can take to keep their site, and their businesses safe. More secure encryption also has an effect on the Drupal platform as a whole. Whether Drupal is being used to create the most basic brochure site or advanced enterprise web application, encryption and API key management are critical to ongoing success. Many businesses don’t care whether their web site is built with Drupal, WordPress, Joomla, or even Microsoft Word (yes this is still possible) as long as it is secure. By integrating the proper security controls, including encryption and key management, Drupal will continue to proliferate and be the tool of choice for enterprises looking for the highest level of data and site security.

What Data Needs Encrypted In Drupal?

Topics: Key Management, Drupal

Why You Should be Continuously Delivering Drupal Updates - All the Time

Posted by Paul Taylor on May 9, 2016 7:35:00 AM

This is a special blog post written for Townsend Security by the Drupal Drop Guard team.


While developing a system to automate Drupal updates and using that technology to fulfill our Drupal support contracts, we ran into many issues and questions about the workflows that integrate the update process into our overall development and deployment cycles. In this blog post, we’ll outline the best practices for handling different update types with different deployment processes – as well as the results thereof.

The general deployment workflow
Most professional Drupal developers work in a dev-stage-live environment. Using feature branches has become a valuable best-practice for deploying new features and hotfixes separately from the other features developed in the dev branch. Feature branches foster continuous delivery, although it does require additional infrastructure to test feature branches in separate instances. Let us sum up the development activity of the different branches.

Drop guard workflow

Dev
This is where the development of new features happens and where the development team commits their code (or in a derived feature branch). When using feature branches, the dev branch is considered stable; features can be deployed forward separately. Nevertheless, the dev branch is there to test the integration of your locally developed changes with the code contributions of other developers, even if the current code of the dev branch hasn’t passed quality assurance. Before going live, the dev branch will be merged into the stage branch to be ready for quality assurance.

Stage
The stage branch is where code that’s about to be released (merged to the master branch and deployed to the live site) is thoroughly tested; it’s where the quality assurance happens. If the stage branch is bug-free, it will be merged into the master branch, which is the code base for the live site. The stage branch is the branch where customer acceptance happens.

Master
The master branch contains the code base that serves the live site. No active changes happen here except hotfixes.

Hotfix branches
Hotfixes are changes applied to different environments without passing through the whole dev-stage-live development cycle. Hotfixes are handled in the same way as feature branches but with one difference: whereas feature branches start from the HEAD of the dev branch, a hotfix branch starts from the branch of the environment that requires the hotfix. In terms of security, a highly critical security update simply comes too late if it needs to go through the complete development cycle from dev to live. The same applies if there’s a bug on the live server that needs to be fixed immediately. Hotfix branches need to be merged back to the branches from which they were derived and all previous branches (e.g. if the hotfix branch was created from the master branch, it needs to be merged back to the master to bring all commits to the live site, and then it needs to be merged back to the stage and dev branch as well, so that all code changes are available for the development team)

Where to commit Drupal updates in the development workflow?
To answer this question we need to consider different types of updates. Security updates (including their criticality) and non-security updates (bug fixes and new features).

If we group them by priority we can derive the branches to which they need to be committed and also the duration of a deployment cycle. If you work in an continuous delivery environment, where you ship code continuously,the best way is to use feature branches derived from the dev branch.

Drupal Drop Guard

Low (<=1 month):
- Bug fix updates - Feature updates

These updates should be committed by the development team and analysed for side effects. It’s still important to process these low-prio updates, as high-prio updates assume all previous code changes from earlier updates. You might miss some important quality assurance during high-prio updates to a module that hasn’t been updated for a long time.

Medium (<5 days):
- Security updates that are not critical and not highly critical

These updates should be applied in due time, as they’re related to the site's security. Since they’re not highly critical, we might decide to commit them on the stage branch and send a notification to the project lead, the quality assurance team or directly to you customer (depending on your SLA). Then, as soon as they’ve confirmed that the site works correctly, these updates will be merged to the master branch and back to stage and dev.

High (<4 hours):
- Critical and highly critical security updates

For critical and highly critical security updates we follow a "security first" strategy, ensuring that all critical security updates are applied immediately and as quickly as possible to keep the site secure. If there are bugs, we’ll fix them later! This strategy instructs us to apply updates directly to the master branch. Once the live site has been updated with the code from the master branch, we merge the updates back to the stage and dev branch. This is how we protected all our sites from Drupalgeddon in less than two hours!

Updates automation options
There are only a few ways to ensure the updates will be applied just in time and when it’s really needed, depending on the type of update. Any of those have positive and negative sides, and it’s only up to you to choose what suites you the best:

  1. Monitoring for updates manually or via one of available services or custom scripts, and once the security update is detected, process it according to the workflow defined in your organization. This approach works in most cases, but it requires someone to be ready to take action 24/7;
  2. Building a completely custom solution, which will not only detect updates, but also take care of applying them when it’s time. The only obvious drawback of this is that you have to spend a lot of time building and maintaining your custom tool.
  3. Using the updates automation service, such as Drop Guard, which will integrate seamlessly in your workflow and process updates in exactly the way you want. You don’t have to worry about being alerted all the time, or spending too much time on building your own solution, but be prepared to spend a few dollars on the 3rd party solution.

Requirements for automation
If you want to automate your Drupal security updates with the Drop Guard service, all you need is the following:

  • Code deployment with GIT
  • Trigger the update of an instance by URL using e.g. Travis.ci, Jenkins CI, DeployHQ or other services to manage your deployment or alternatively execute SSH commands from the Drop Guard server.

Also to keep in mind:

  • Know what patches you’ve applied and don't forget to re-apply them during the update process (Drop Guard helps with its automated patch detection feature)
  • Automated tests reduce the time you spend on quality assurance

Conclusion
Where to commit an update depends on its priority and on the speed with which it needs to be deployed to the live site. Update continuously to ensure the ongoing quality and security of your project and to keep it future-proof. Feature and bug fix updates are less critical but also important to apply in due time.

There are many ways of ensuring the continuous security for your website, and it’s up to you whether to go with a completely manual process, try to automate some things, or opt-in for a fully automated solution such as Drop Guard.

Topics: security, Drupal

To Key or Not to Key: That is the Question

Posted by Luke Probasco on Jan 8, 2016 8:26:00 AM

"This article was originally posted on Pantheon’s blog. Pantheon is a website management platform for Drupal and WordPress."


What Data Needs To Be Encrypted In Drupal?To keep something safe, you protect it under lock and key, right? Same is true in Drupal and WordPress. Except in these CMSs, that key is unfortunately often hidden under the “Welcome” mat called your database. Not always a very secure place for such important items. So, the question is, what can you do to keep the key safe?

Let’s back up a few steps. Why are there keys and where are they in the first place? 

Private API Keys

Private API keys are actually used frequently within a CMS by services like Authorize.net, PayPal, MailChimp, etc., and stored in the clear. If your site gets hacked, so does access to the services that you have integrated into your site. For example, if your Amazon S3 API key were in your stolen database, hackers would have access to your entire offsite S3 storage. Let’s take MailChimp, for example:  If your MailChimp API key becomes compromised, hackers could send out emails as if they appeared from you, leaving customers surprised to learn that you just got into selling Viagra.

Encryption Keys

In Drupal, for example, there are several modules (EncryptField EncryptionEncrypted Files, etc.) that allow you to encrypt various types of data. This is a very necessary step to keeping your data secure, however what happens to the key to unlock that data? Typically, developers will store their encryption keys locally in either a file protected on the server, in the database, or in Drupal’s settings file. Not very secure places. Further, for companies who fall under data security compliance requirements like HIPAA, FISMA, or PCI DSS, key management requirements are pretty clearly spelled out, and these default methods don’t even come close to being sufficient. Essentially, the compliance requirements all say the same thing: encryption keys should never reside in the same environment or server as the encrypted data. This is a technical way of saying, don’t leave your key under the doormat a hacker walks in over.

Unfortunately in WordPress, there are isolated solutions, but no plugin that provides and manages the encryption process. The team working on the Drupal encryption modules are also working to bring the same functionality to WordPress.

Now that we have established storing sensitive keys within the CMS is not secure, what should we do with them?

Key Management

Keys need to be stored outside of the CMS and developers need to consider how they’ll manage all of these keys. Most encryption modules are designed to create a new key each time the encrypted data is accessed and re-encrypted. As you can imagine, versions of keys add up quickly and managing them is quite a task—not something that you’d want to do manually (luckily your server can’t put a sticky note of keys on its hard-drive).

There are solutions and services designed specifically for key management that can run on a wide variety of platforms ranging from in the cloud, to VMware, to a physical hardware security module (HSM). These solutions can safeguard your API keys, as well as manage encryption keys through the entire lifecycle—from creation to destruction.  Additionally, an external key manager will allow for:

  • Key naming and versioning

  • Key change and rotation

  • Secure key retrieval

  • Key mirroring

  • Key import and export

  • Password and passphrase protection

  • User and group control for key access

Modules and Plugins for Key Management

Luckily, for Drupal users, there is a super easy way to integrate external key management (and follow security best practices). This can happen by way of the “Key” module. Key acts as a central routing API for keys and is easily extended to integrate with your key management vendor of choice.

These modules act as the bridge between the various encryption/API modules and an external key manager. They give site administrators the ability to define how keys are stored, which provides an increased level of security and allows sites to meet compliance requirements and security best practices. With these modules installed, users no longer need to settle for storing their keys in insecure places.

While there currently isn’t a Key equivalent for WordPress, efforts are being made to remedy this.  By early 2016, we can expect to see great progress in the way of managing encryption and API keys in via a plugin similar to that in the Drupal environment.  For now, WordPress developers need to rely on an  external service such asLockr to secure these keys.

Who Holds the Keys to Your Kingdom?

There are three important questions that need to be asked when considering your key management strategy:

  1. Do I want to manage the keys myself or use a service?

  2. Do I need to meet any compliance requirements?  

  3. What is my budget?

Your budget and needs can play a large part in determining which route you take. With a low entry price point, a multi-tenant managed key service (where your keys are stored alongside other companies’ keys on the same key manager) is a great option. These services typically operate in the cloud and allow businesses to remove their keys from under the “Welcome” mat and store them in a more secure environment. As businesses or security needs grow, managed key services can easily scale and migrate users to a dedicated, FIPS 140-2 compliant key manager that can help them meet compliance (PCI DSS, FISMA, etc.).

For users who feel more comfortable with a hands-on approach—or don’t trust anyone but themselves with their keys)—a dedicated and self-managed option may be right for them. Dedicated key managers are available virtually (AWS, Azure, VMware) or physically as a Cloud HSM or HSM, and have a wide variety of licensing options.

To Key or Not to Key?

By now the choice should be fairly obvious. Protecting keys is an important aspect of  a strong security posture. As the headlines show, data breaches are a reality—regardless of the size of your business. They can happen as a result of a hacker or disgruntled employee.  Properly protecting API and encryption keys is a very easy way to manage the risk and severity of a data breach.

Townsend Security’s dedicated Alliance Key Manager is in use by over 3,000 customers worldwide and is the only dedicated key manager with Drupal integrations. Cellar Door Media also recently launched Lockr, a managed key service for Drupal and WordPress that’s free during development, and once deployed to a site, pricing starts at $30 per month. Lockr also offers managed dedicated key service for enterprise customers.

What Data Needs Encrypted In Drupal?

Topics: Encryption Key Management, Drupal

How Secure Is Your Data in Drupal? (And 5 Essential Security Tips)

Posted by Luke Probasco on May 29, 2015 8:18:00 AM

"This article was originally posted on Pantheon’s blog. Pantheon is a website management platform for Drupal and WordPress."


“There are only two types of companies: those that have been hacked, and those that will be.  Even that is merging into one category: those that have been hacked and will be again.” – Robert Meuller, Former FBI Director

Your website will be hacked.  Your defense in depth security strategy will determine how severe the damages are.

What Data Needs To Be Encrypted In Drupal?

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.

Securing data is important (and required)

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.

Sensitive data includes more than social security numbers

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):

  • Email address
  • Password
  • Login name
  • IP address

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.

Developers need to think about security, even if the client isn’t

“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. 

Essential security

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?

What Data Needs Encrypted In Drupal?

Topics: Data Security, Drupal

Is Drupal Ready for the Enterprise?

Posted by Luke Probasco on Feb 17, 2015 10:35:00 AM

Drupal is growing up. Currently, over one million websites run on Drupal. It is the CMS of choice for the Weather Channel, American Express and the White House. And with Drupal 8 right around the corner, promising to bring new features and capabilities, it is a very attractive CMS for agencies who need to build solutions for their clients.

What Data Needs To Be Encrypted In Drupal?While these are some major wins for the platform, there is still a large segment of enterprises not quite ready to adopt Drupal. With headlines like “Drupal Sites, Assume You’ve Been Hacked” (after Drupalgeddon) it is easy to understand why there may be some hesitation. Security is a top concern for enterprises and they are scrutinizing anything that collects and stores personally identifiable information (PII) on behalf of their brand.

Increased security requirements are now trickling down via RFPs to agencies and developers who need to choose a CMS. As far as these enterprises are concerned, they don’t care what CMS is used on their project, as long as it can: (1) help manage their risk of a data breach and (2) meet compliance requirements. Enterprises know that the regulations they fall under (PCI DSS, HIPAA, FISMA, etc.) can be unforgiving in the event of a breach, especially if the proper technology was not in place.

So, is Drupal ready for the enterprise?

As a platform, yes-ish. Enterprises have security requirements that go beyond what is available in Drupal core. Fortunately, there are members within the Drupal community that understand this and have developed modules and services that easily integrate into Drupal installations. It is now up to developers to use these tools to build secure, enterprise-ready web sites and applications.

In order to win bids, developers need to not only know how to code, but also need to know security best practices. Concepts like dual control and separation of duties are now considerations when planning for web site security. Developers are also learning what compliance regulations consider sensitive information – data that they previously didn’t think twice about leaving unprotected. Beyond the obvious – credit card and social security numbers – email addresses, phone numbers, and zip codes can constitute PII that needs to be encrypted.

DrupalCon Encryption 
Slide from Hugh Forrest’s (Director, SXSW Interactive Festival) keynote from DrupalCon 2014 on the importance of encryption.

The importance of encryption and key management cannot be overstated. Encryption is the hardest part of data security, and key management is the hardest part of encryption. Storing encryption keys within the Drupal database, settings file, or even a protected file on the server, will never pass an enterprise security team’s sniff test or compliance audit. Hackers don’t break encryption, they find keys, and without key management, developers are leaving their private data open to any hacker that cares to take a look.

“We recently began talks with a Fortune 100 company regarding their platform,” said Chris Teitzel, CEO of Cellar Door Media. “Encryption was a requirement for this project. The primary question the security team brought up was how we are able to manage the keys.”

With the importance of encryption and key management realized, who is responsible for implementing it? Unfortunately, currently no major Drupal hosting providers offer it within their environments. However, it is not difficult to deploy using modules like Encrypt, Key, Form Encrypt, Field Encrypt, Key Connection, etc. These modules all have integrations with services that allow for encryption and key management outside of the Drupal installation.

It is also important to note that, while hosting providers can claim they are compliant with your specific regulation, their compliance does not extend to you, the developer. Hosting providers can attain an Attestation of Compliance (AOC) for their platform, however, it does not extend to what their customers do within their environments. Additionally, regulations like PCI DSS make it clear that in the event of a breach, it is the enterprise, not the hosting provider or development agency, that is responsible.

For Drupal to truly be a contender in the enterprise space, which it clearly is, it is prudent that members of the Drupal community understand how to secure data within their deployments, who is responsible in the event of a breach (their clients), and what they need to do to secure sensitive data in Drupal to make it a viable option.What Data Needs Encrypted In Drupal?

Topics: Encryption, Encryption Key Management, Drupal

Why Encrypt Data in Your Drupal Websites?

Posted by Liz Townsend on Oct 3, 2014 10:44:00 AM

The internet has become a portal for the transmission and storage of sensitive data. Most websites today gather information from potential or current customers, clients, and users. From credit card numbers to email addresses and passwords, few websites exist today that don’t collect some sort of personal data. Therefore, website developers are becoming more and more interested in learning how to build websites that can easily encrypt sensitive data that their client’s website may be collecting.Drupal Developer Program

Encryption isn’t as widely used at the application and module level in websites as it probably should be. Protecting sensitive data using strong encryption from the moment a website accepts a customer’s information, and throughout transmission and storage of that data is the only method to ensure that data is never compromised. This is critical for websites using commerce modules or forms that collect a person’s health information, financial information, or other personally identifiable information (PII); and for businesses who wish to avoid a data breach.

As Drupal grows and more Drupal developers are beginning to interact with larger clients, the need to provide strong security to those businesses grows as well. The need for encryption will continue to grow as potential clients ask Drupal developers for standards-based security solutions that will help them meet compliance regulations and mitigate risk.

  • Government websites, for example, will need to pass FISMA regulations around encryption.
  • Large retail websites will need to pass Payment Card Industry Data Security Standards (PCI DSS).
  • Colleges and Universities have multiple compliance requirements, as well as FERPA, to adhere with.

Helping clients meet compliance regulations will also require, in some cases, the need for encryption key management. Historically, developers only had three choices for encryption key storage: they could store the key in a file protected on the server, in the Drupal database, or in Drupal’s settings file. None of these options are secure, and would not meet several compliance regulations and general security best practices.

Encryption key management is more than a “key storage” solution. An encryption key manager protects encryption keys on a separate server (located in the cloud or as a physical Hardware Security Module (HSM) or in a (VMware) virtual environment) that implements control layers such as dual control and separation of duties. An encryption key manager manages encryption key creation, deletion, lifecycle, rollover, and archival. Key managers that are FIPS 140-2 compliant have undergone NIST validation and are based on industry standards. Choosing an encryption and key management solution based on standards will ensure your solution will stand up to scrutiny in the event of a breach.

If you are a Drupal developer, you can now join the Townsend Security Drupal Developer Program, work with our encryption and key management technology free of charge, and learn how to secure sensitive data in Drupal for your clients concerned with security.

Using Key Connection for Drupal, the first encryption & encryption key management module, Drupal developers can now build NIST compliant AES encryption and FIPS 140-2 compliant encryption key management into their Drupal websites.  

Just click below to sign up:

Developer Program Encryption 

Topics: Encryption, NIST, Developer Program, Encryption Key Management, FIPS-140, Drupal

5 Reasons to Join Townsend Security’s Drupal Developer Program

Posted by Liz Townsend on Aug 29, 2014 2:11:00 PM

Data security in Drupal is a top concern. Townsend Security recently launched our Drupal Developer Program to engage Drupal developers in building stronger, more secure websites, and to give back to the Drupal community by creating a collaborative network of Drupal developers concerned with data security and compliance regulations. Members of the Drupal Developer Program gain free access to Alliance Key Manager, our FIPS 140-2 compliant cloud key manager, as well as NIST-validated AES onboard encryption, for non-production testing and development.

Drupal Developer ProgramMany Drupal developers today run up against tricky situations when developing websites that collect sensitive data such as payment card information, personally identifiable information (PII), and user passwords--not just commerce information. Developers are asking themselves, “what compliance regulations do I face”, “which data needs to be encrypted”, and “how do I do encryption and key management right to meet compliance?”

With Key Connection for Drupal, an API designed to offboard encryption keys to a secure key server, encryption and key management is made easier than ever.  Now Drupal developers can join the Drupal Developer Program and learn how to do encryption and key management right.

Here are the top reasons to consider joining the Drupal Developer Program:

1. Encryption and key management is critical to effective data security in Drupal website development.
Today, Drupal is a top CMS for all kinds of websites. Some of these websites, such as commerce, health, and government websites collect sensitive data from users that must be encrypted under compliance regulations such as PCI, HIPAA and FISMA. These compliance regulations also have clear language strongly recommending, if not requiring, encryption and key management.
As Drupal developers take on larger clients, these compliance regulations become a greater concern. Historically, the Encrypt module could be used to encrypt any sensitive data collected; however, there was no adequate means to protect encryption keys. Today, with Key Connection for Drupal, developers can help their clients manage encryption keys away from encrypted data on a secure key server and create websites that effectively protect sensitive data.

2. Learn how to encrypt sensitive data and properly manage encryption keys
In the last year, many of the largest data breaches could have been avoided if proper encryption and key management was implemented. Within the Drupal Developer Program, Drupal developers can learn how to implement encryption and key management into their projects from the ground up. Encrypting and management encryption keys is actually quite easy now in Drupal, and learning how to use these tools will prepare Drupal developers for larger projects that require strong data security.

3. Implement strong data security in your web development projects from the ground up
Adding data security after-the-fact is difficult. Building your websites and applications using strong encryption and key management from the ground up prevents data security projects from turning into a massive headache. The Drupal Developer Program allows developers to test encryption and key management in their projects from the start to avoid a complicated project down the road.

4. Build your knowledge of compliance requirements and help to educate your colleagues
Our Drupal Developer Program is designed to educate developers on encryption and key management best practices as well as any compliance regulations you may face. We continuously offer resources to help you learn what you need to know to meet PCI DSS, HIPAA, GLBA/FFIEC, FISMA, and other compliance regulations, as well as state privacy law requirements.

5. It’s free!
There’s no charge to join our Drupal Developer Program. With free access, we hope to give Drupal Developers the freedom to learn about, test, and implement strong encryption and key management so that you will become a security thought leader in your own organization!
Drupal Developer Program Encryption Key Management

Topics: Encryption, Encryption Key Management, Drupal

What Data Needs To Be Encrypted In Drupal?

Posted by Luke Probasco on Jul 10, 2014 9:20:00 AM

"I am collecting data in Drupal. What data do I need to encrypt?"

What Data Needs To Be Encrypted In Drupal?Organizations starting an encryption project always have this question on their minds. It is a simple question, but can be hard to answer. Generally speaking, you should encrypt any information that alone, or when combined with other information, can identify a unique, individual person. This is called Personally Identifying Information, or PII. This should be your starting point, but you may need to address other information depending on the compliance regulations you must meet.

Federal/State Laws and Personally Identifiable Information (PII)

Federal and State laws vary in terms of what they consider Personally Identifiable Information (PII), but there is a lot of commonality between them. PII is any information which either alone or when combined with other information, which can identify an individual person. Examples include email addresses, first name, last name and birth date.
[Download white paper for complete list]

Educational Information Covered by FERPA

Educational institutions who fall under the FERPA regulation must protect PII as well as information like student names, student ID numbers, and family member names.
[Download white paper for complete list]

Federal Agencies and FISMA

Federal Agencies must evaluate their systems for the presence of sensitive data and provide mechanisms to insure the confidentiality, integrity, and availability of the information.  Sensitive information is broadly defined, and includes PII, as well as other information classified as sensitive by the Federal agency.  Sensitive information might be defined in the following categories: medical, financial, proprietary, contractor sensitive, or security management.[Download white paper for complete list]

Medical Information for Covered Entities and HIPAA/HITECH

The HIPAA/HITECH Act defines Protected Health Information (PHI) to include PII in addition to the following PHI: Patient diagnostic information, payment information, health plan beneficiary numbers, full facial photographs, etc.
[Download white paper for complete list

Payment Card Data Security Standard (PCI DSS)

The Payment Card Industry Data Security Standards (PCI DSS) require that merchants protect sensitive cardholder information from loss and use good security practices to detect and protect against security breaches.  If you accept or process credit card or other payment cards, you must encrypt the Primary Account Number (PAN).

Financial Data for FFIEC

Banks, credit unions, and other financial institutions must protect Non-public Personal Information (NPI) which includes personally identifying financial information.  In addition, you should protect income, credit score, etc.
[Download white paper for complete list]

Encrypting Data in Drupal

Townsend Security is helping the Drupal community encrypt sensitive data and properly manage encryption keys. Developers who need to protect sensitive data know that storing their encryption keys within the content management system (CMS) puts their data at risk for a breach. With Key Connection for Drupal and Alliance Key Manager, administrators are now able to keep their encryption keys secure by storing them remotely and only accessing them when the encryption/decryption happens.

The Key Connection for Drupal module is a plugin for the Encrypt project that allows you to easily encrypt sensitive data with NIST-validated AES encryption and securely retrieve and manage encryption keys from Townsend Security’s FIPS 140-2 compliant Alliance Key Manager. With an easy to use interface and certifications to meet compliance requirements, you can rest assured knowing your data is secure.

What Data Needs Encrypted In Drupal?

Topics: Encryption, Higher Education, Drupal

 

 

Subscribe to Email Updates

Posts by Topic

see all