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.
Shrop: 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.
