Townsend Security Data Privacy Blog

Encryption key management is the cornerstone of an effective encryption strategy. Without key management, encryption stands alone as only half of a solution. When you leave the keys to unlock your sensitive business and customer data exposed, then you expose your entire organization to the risk of data loss or theft. Luckily, MongoDB was born in the age of modern data security and developed their no-SQL database with the forethought and insight to incorporate strong encryption and key management solutions. This means that today, with MongoDB Enterprise, MongoDB customers can meet encryption and key management best practices fairly easily through implementing native encryption and deploying a third-party enterprise key management solution.

In order to enable customers to seamlessly implement enterprise encryption key management, MongoDB integrated a universal encryption key management protocol called the Key Management Interoperability Protocol (KMIP). Unlike many other legacy databases who have floundered over the years trying to help customers do strong key management, MongoDB enables customers to protect encryption keys out of the door with a number of tested and validated enterprise key management partners. To know if you’re encryption key management solution is compatible with MongoDB, check to see that it has implemented KMIP.

What is Enterprise Encryption Key Management?

Enterprise encryption key management includes both technological and policy-based controls that integrate to provide the highest level of security of an organization’s encryption keys. Both types of controls are important to protecting encryption keys.

On a technological and physical level, encryption keys should be stored in a logically or physically separate hardware or virtual key server, dedicated to performing key generation, storage, and distribution. Keys should be generated with a FIPS 104-2 validated pseudo-random number generator and stored in a secure key database. Keys used for encrypting data (data encryption keys, or DEKs) should be key-wrapped and encrypted using key encryption keys (KEKs)--these keys are only used to encrypt DEKs inside the secure key database.

Once encryption keys are generated and in use, they should be distributed for use over a secure Transport Layer Security (TLS) session using certificates to authenticate the user requesting the encryption key. An enterprise key management server should use the most recent, recommended version TLS--1.2--as vulnerabilities were discovered in TLS 1.1 and TLS 1.0.

Lastly, enterprise key managers should perform real-time backup and high availability functions to prevent downtime and ensure business continuity. This means that each key server should perform active-active mirroring to one or more high availability server as well as perform routine, automated backups to secure storage drives.

All of these functions are critical to meeting best practices and securing encryption keys. However, beyond the technology, an enterprise key manager should implement user rules and administrative options that enforce particular policies and policy-based best practices.

A critical administrative component to encryption key management is the ability to manage the complete encryption key life cycle. The encryption key lifecycle is defined by the National Institute of Standards and Technology (NIST), which outlines all aspects of a key’s life including key generation, pre-activation, activation, distribution, revocation, post-activation, backup, and deletion.

The administrative console that allows access to these functions should also give the IT or security administrator the option to designate key users or user groups as well as set keys to automatically rotate after a certain number of days, months, or years. This is just one requirement for organizations who fall under security standards for some regulated industries such as the payment card industry. The Payment Card Industry Data Security Standard (PCI DSS) outlines key management requirements for card holders or processors that can typically only be met using an enterprise-level encryption key management solution.

To learn more about PCI-DSS and encryption key management, view this webinar.

Beyond managing the key lifecycle, an enterprise key manager should actively audit and log all activity and functions performed on the key management server and record these logs to an external event monitoring or logging server so that malicious activity can be detected in real time. Your key management solution should be compatible with common event monitoring solutions and export logs in standardized formats in real time.

Lastly, your key management solution should inherently enforce policy-based security functions that meet key management best practices such as separation of duties and dual control. Separation of duties ensures that no single person is in control of multiple key management procedures such as the client request and subsequent distribution of an encryption key. The person requesting the key and the person distributing the key should be two different people. Dual control prevents any key management process to be controlled by a single person; for example, two security administrators should be needed to authenticate access to the key server. While these policy-based controls are sometimes optional, they should always be available and easy to implement in your encryption key management solution.

MongoDB Likes Centralized Key Management

When MongoDB decided to implement KMIP, the decision was likely a deliberate strategy to help users to either leverage the enterprise key management solution they already have, or to use common key management solutions that are KMIP-compatible. The power of KMIP is that it enables users to truly achieve centralized key management. A historical problem surrounding key management was the difficulty of an organization to store and manage encryption keys across multiple platforms, operating systems, and often departments. By implementing KMIP, MongoDB continues to make implementing key management across an organization more and more easy and effective, and therefore more user-friendly, which is what MongoDB is best known for.

Without deploying a strong encryption key management solution, encryption of sensitive data on its own is considered ineffective. In the age of the cloud, deploying a key management solution alongside your data is equally important, and therefore having options for where you deploy it is an important factor in your key management strategy. An effective key management solution should not only be centralized across your organization, but it should meet your data where it’s at, whether that is the cloud, a virtual environment, or on-site hardware.

KMIP also enables MongoDB customers to choose their own KMIP compliant key management solution and maintain complete custody of the key management server, and therefore the keys. Whether deploying the key manager in the cloud, in a virtual environment, or on-site, owning a third-party KMIP compliant key manager allows users to retain total control of their keys without sharing access with cloud service provides or software vendors.

Lastly, when researching professional or enterprise key management solutions, check to see if the vendor has validated their solutions with NIST such as to the NIST FIPS 140-2 standard, uses standardized technology, and has been validated to meet PCI DSS or other regulatory certifications. These validations ensure that the technology has been tested by independent labs to the highest security standards.

In combination with a robust database encryption solution from MongoDB, your encryption key management solution will elevate your security position and total level of control.

HIPAA regulations regarding data security for patients are hard for a layperson to understand, and are even difficult for administrators and technologists who work in the healthcare industry. This is especially true for smaller organizations, partly due to the complexity of the HIPAA law itself, and the HITECH regulations that followed it. Let’s try to clear up some of the misunderstanding around HIPAA and encryption, and clarify what you should do regarding data protection for patient data.

The first confusion about the protection of patient data is that encryption of this data is a strong recommendation, but that it is not a mandate. It is what is termed an “addressable” requirement. The word “addressable” has very specific meaning in the context of HIPAA. If implementing encryption of patient data is not feasible, a healthcare organization under HIPAA regulations, can implement equivalent protections. So, if your software vendor or IT department thinks that encryption is not feasible you have the option to implement other equivalent security controls to compensate for that. The reasons why you think it is not feasible must be documented in writing, and must be reasonable and valid.

Encryption is not a mandate under HIPAA law. And unless the law changes, it is probably not possible for HHS and its Office for Civil Rights (OCR) to make it mandatory.

But there is much more that you need to know. While HHS and OCR cannot mandate the encryption of patient data, they do have the ability to make it painful if you don’t. And that is exactly what they are doing. For example, if you claim that you can’t encrypt patient data, document your reasons, implement compensating controls, and THEN have a data breach, you are likely to be penalized for the lack of effectiveness of the compensating controls. Your data breach is clear evidence that your compensating controls were inadequate.

I like to call this a “Backdoor encryption requirement”. That is, there is probably nothing you can do in the way of compensating controls that are equivalent to encryption. But you won’t discover that until you have a data breach.

Lacking the ability to mandate encryption, HHS and OCR have taken to the strategy of increasing the penalties for lost patient data. I’ve heard recently from many organizations in the healthcare segment of increasing concern about the potential fines related to a data breach. This is driving a new interest in encryption and the related requirement to protect encryption keys.

This last point is crucial when implementing encryption for HIPAA compliance - your encryption strategy is only as good as your encryption key management strategy. Encryption keys are the secret that has to be protected. If you lose the encryption key, the cybercriminals have the ability to access patient data. Storing encryption keys in a file, in application code, or on mountable drives or USB storage will certainly fail a best practices review. Use a professional, certified key management solution in your encryption deployment to protect patient data.

If you are going to do encryption of patient data, get it right the first time! Use good key management practices.

Patrick

Most IBM i customers struggle to provide more IT services to their organizations with an ever-shrinking set of budget and human resources. It is natural, then, that IBM i customers would look to a variety of automation and management tools to buttress their existing IT service infrastructure. IT Service Management (ITSM) tools are a great place to start.

The clear leader in ITSM is ServiceNow. ServiceNow is the Gartner Magic Quadrant leader in ITSM with more than double the market share of its closest competitor. It is easy to see why - building on its IT Service Support Management (ITSSM) tools ServiceNow has had a singular focus on the IT service management space for some time. It has a well-designed interface that makes integration with other platforms easy, and it deploys as a web-based SaaS solution. It is easy to start with Incident management and add a wide set of automation and service features. You can find a good overview here.

Here at Townsend Security we have been looking at ways of making life easier for our IBM i customers and especially IT management and Security Administrator professionals. Integrating ServiceNow with our Alliance LogAgent solution was a natural step. With a handful of customers cheering us on, we committed to ServiceNow integration and providing an open path for ServiceNow integration outside of our SIEM integration product. Our first steps focused on some critical IT and security areas.

Administrative User Access

Security professionals understand how critical it is to control and monitor administrative access to the core business systems. Administrative user access to an IBM i server should be rare and well-controlled. Cyber-criminals attempt to gain administrative privileges in order to steal sensitive data or cause havoc. Monitoring administrative user access to your IBM i is now a critical security requirement.

Alliance LogAgent can now automatically and in real time create a ServiceNow incident when a highly privileged administrator logs onto your IBM i server. This notification to ServiceNow leverages our earlier enhancements that dynamically identify a high level of privilege including those privileges inherited from Group and Supplemental profiles. Your IT security team can react quickly to unexpected administrator access. Of course, fully reporting to your SIEM solution is included.

Disabled User Profiles

IBM i users have implemented strong password controls to strengthen system security. Unfortunately this means more IT support for users who forget their password and disable their user profile. Wouldn’t it be great to get a real-time notification when a user profile is disabled? You can now do that with Alliance LogAgent. A disabled user profile will generate a ServiceNow incident record and your IT support team can pro-actively reach out to help your user. An additional security benefit is that you can detect automated attacks on your IBM i servers that result in a number of disabled user profiles.

Library and IFS Object Changes

Attackers often attempt to modify applications and configuration files as a part of an attempted breach of your system. This might include access to application configuration files and programs in a library, or it might be an attempt to modify a web configuration file in the IFS file system. Alliance LogAgent now allows you to selectively report these object and file changes to ServiceNow in real time.

ServiceNow User and Application Integration

I’m leaving the best for last! In addition to the automatic events that Alliance LogAgent raises as a ServiceNow incident, there is also a new command that lets you integrate ServiceNow into any application on your IBM i server. The new Create ServiceNow Incident (CRTSVNINC) command gives you the ability to create ServiceNow incidents from your own applications.

Is an ACH payment over the usual limit being initiated?

Log it to ServiceNow.

Is a mortgage loan being originated that violates bank policy?

Log it to ServiceNow.

Has a credit card transaction been refused due to fraud?

Log it to ServiceNow!!!

I’m sure you get the idea. Automating these types of events are now fully under your control.

If you already have a SIEM integration tool or notification system, don’t despair.Alliance LogAgent can co-exist with existing tools from third-party vendors. And you can use the new ServiceNow integration command without using the SIEM and system logging components of Alliance LogAgent. Of course, if you want to upgrade to a more advanced tool you should contact us. There’s a great competitive upgrade plan waiting for you.

The IBM i server is a great platform and we are fully committed to providing leading-edge enhancements to our IBM i solutions. You will be hearing more from us about new innovations for the IBM i in the days and weeks ahead.

Patrick

Not all cyber attacks result in the loss of sensitive data. The astounding Equifax data breach is on all of our minds right now, but sometimes a security breach results in unrecoverable damage to critical systems. These attackers are not looking to perpetrate financial fraud - they are looking to damage the operational status or reputation of an organization. That happened to TNT (a FedEx division) recently.

TNT/FedEx suffered the loss of critical systems that inflicted severe financial pain. John Pescatore of SANS expressed it this way:

“When numbers like this come out, they are great data for convincing your management that, almost invariably, fixing known security problems (even if it causes business disruption) is almost invariably cheaper than enduring an incident. FedEx acquired TNT Express in 2016 fort $4.4B, and the estimates for TNT's 2016 profit were about $150M. So, NotPetya essentially cost FedEx *two years* of TNT's profit. Even if mitigating the Windows SMB vulnerability back in March would have required TNT to shut down all revenue operations for an entire day, the impact would have been about $7M in revenue or in the range of $350K in profit, or about .1% of what enduring NotPetya has cost, so far.”

At Townsend Security we usually focus on encryption technologies to help prevent the loss of sensitive data. But it is good to remember that the loss may be in critical IT infrastructure.

How to recover from that?

You need to have current backups of all critical systems. Yep, old fashioned, off-line backups that cannot be damaged by the attacker. Too many modern backup systems are based on shared storage that appear as mounted drives. These are very easy to damage by a NotPetya or similar attack. It seems old-fashioned, but you really need to have backups on removable media in a safe location. There is just no substitute for that.

Of course, the tape backup should be encrypted to protect the data on the way to offsite storage, in storage, and on the way back. Tape backup systems are very inexpensive these days. We happen to like the system from Quantum, who are one of our partners on the encryption key management front. But you can find good solutions from a number of vendors. More information about Quantum here.

Patrick

Alliance LogAgent for IBM i now instantly records critical system events and integrates line-of-business applications with ServiceNow, the leading cloud-based solution for IT systems to instantly record critical system events.

Townsend Security today announced support for integration of IBM i servers and applications with ServiceNow, the leading cloud-based solution for IT system support problem tracking and resolution. Leveraging the ServiceNow REST web interface, Townsend Security’s Alliance LogAgent solution can now instantly record critical system events as ServiceNow Incident reports. Additionally, Alliance LogAgent also exposes an API command to allow IBM i customers the ability to integrate line-of-business applications with ServiceNow. When business applications encounter critical events or errors, these can be immediately visible to the IT administrative and security teams for rapid response and resolution.

“IBM i customers want to leverage the best of the new generation cloud-based service offerings. This new release of Alliance LogAgent gives them that ability right out of the box. Existing ServiceNow customers have all they need to record critical incidents in real time. IBM i users who are not currently ServiceNow customers can rapidly subscribe to ServiceNow and start enjoying the benefits of this leading IT Systems Service Management (ITSSM) solution,” said Patrick Townsend, CEO of Townsend Security.

“The power and stability of the IBM i system can integrate with the best of the cloud-based ITSSM solutions. It’s an easy win for IBM i customers, and those with existing system logging solutions will be happy to know that Alliance LogAgent can co-exist with existing technology, or IBM i customers can take advantage of our competitive upgrade program,” continued Townsend.

New ServiceNow features in Alliance LogAgent include:

Privileged User Access
Monitoring administrative access to IBM i servers is a critical compliance and security best practice. Alliance LogAgent can identify in real-time the privilege level of a user signing on to the system and report it to ServiceNow and to any SIEM solution. Alliance LogAgent is unique in its ability to dynamically identify the true privilege level of a user by examining the native authority of the user as well as authorities inherited from Group and Supplemental profiles. Cyber criminals often use privilege escalation as a starting point in an attack. Alliance LogAgent can now identify privileged user logons and raise a ServiceNow support incident.

User Profile Disabled
A common labor-intensive task for IT administrators is managing user accounts that are disabled due to an excessive number of password failures, or which are disabled due to a brute force attack. Alliance LogAgent will now automatically identify disabled user profiles in real-time and create a ServiceNow incident report. This gives the IBM system and security administrator rapid visibility and resolution for disabled profiles. Additional system security is provided by an out-of-band notification via ServiceNow of a potential attack in progress.

File or Object Change
An attacker often modifies a program or file on the IBM i server as a part of compromising sensitive data. For example, an attacker might modify the IBM i web server configuration file to direct users to malware on infected sites. IBM i customers can now identify both library and IFS objects for monitoring by Alliance LogAgent with reporting directly to ServiceNow. Early detection of modified programs and files can help an IBM i customer avoid a data breach.

Application Integration with ServiceNow
IBM i developers can now easily integrate business applications and processes with ServiceNow through a new command named Create ServiceNow Incident (CRTSVNINC). By embedding this command into user applications the IBM i developer can provide a wide set of incident creation capabilities. This new command builds on the ServiceNow REST interface without requiring complex communications or API logic in the business application. Using the ServiceNow command does not require the SIEM integration components of Alliance LogAgent. IBM i customers can use just the ServiceNow integration component, or combine its use with Alliance LogAgent SIEM integration.

Alliance LogAgent is licensed on a Logical Partition (LPAR) basis. Both perpetual and subscription licenses are available. Volume discounts are available. Additional charges apply to the ServiceNow application. Alliance LogAgent can be downloaded from the Townsend Security website for a free 30-day trial of the fully functional solution. ServiceNow integration requires a subscription license from ServiceNow. Trial subscriptions are available from their website at http://servicenow.com.

An excerpt from the White Paper "Introduction to Encrypting Data in MongoDB".

In fewer than ten years, MongoDB has risen to become a top player in nonrelational database providers, outcompeting and upsetting database monoliths such as OracleDB and Microsoft SQL Server. Built on a model of low up-front operational costs alongside improved performance, MongoDB has become one of the most widely growing databases for organizations across retail, financial, healthcare, and government entities.

Beyond cost and performance, a key component of MongoDB’s toolset is a robust plan to help customers achieve strong data security through encryption of data in flight and at rest, along with options to secure and manage encryption keys to meet industry compliance requirements and meet data security best practices.

If you are an organization who routinely considers security and compliance when purchasing third-party software, built-in security solutions can be hugely beneficial to your security and compliance strategy. However, like any new software, questions around deployment and how to get the most out of native encryption tools may still be a barrier to your success.

In order to paint both a broad and in-depth picture of how to best deploy encryption and encryption key management in MongoDB, let’s first start by discussing your options to encrypt data in your MongoDB database. If you’d like to first learn the fundamentals of encryption and key management before diving in, check out The Definitive Guide to Encryption Key Management Fundamentals.

Encrypting data in MongoDB

If you choose to encrypt your data, MongoDB offers solutions for encrypting data in motion as well as at rest.

Data-in-Motion Encryption

For securing data in motion, all versions of MongoDB support TLS (Transport Layer Security) and SSL (Secure Socket Layer) to send and receive data over networks. TLS and SSL are the types of encryption commonly used to secure website traffic and file sharing. They are cryptographic protocols that secure data while it is traveling from one point to another; however, before the data is sent and after the data arrives at its endpoint, the data appears unencrypted, or “in the clear”. MongoDB provides ample documentation on how to configure TLS and SSL protocols using certificates and public and private key pairs, also called asymmetric key systems. (Resource: TLS/SSL Configuration for Clients)

When considering encryption, enterprise customers must be aware of governmental and private regulations that require protecting sensitive information. For example, the Payment Card Industry (PCI) requires that credit card numbers be encrypted in storage. The HIPAA medical regulations require protection of Electronic Protected Health Information (ePHI). And there are many other regulations that require proper protection of Personally Identifiable Information (PII). A challenge for MongoDB users is that it is often difficult to know when sensitive information is being added to the database. The safe security strategy is to always encrypt the MongoDB database and use proper key management.

Data-at-Rest Encryption

To encrypt data at rest, MongoDB Enterprise offers native storage-based file symmetric key encryption, which means that users can use transparent data encryption (TDE) to encrypt whole database files at the storage level. First offered in version 3.2, MongoDB utilizes the Advanced Encryption Standard (AES) 256-bit encryption algorithm, an encryption cipher which uses the same secret key to encrypt and decrypt data. MongoDB also provides the option to turn encryption on in “FIPS mode”, which means the encryption you use in MongoDB is built to meet the highest standard and meet compliance. The Federal Information Processing Standard (FIPS) is a National Institute of Standards and Technology (NIST) validation that demonstrates your encryption algorithm has undergone rigorous tests. The NIST FIPS validation is often required for government and Department of Defense contractors; however, today NIST-validated AES encryption is considered an industry standard and is typically recommended or required by most industry-based compliance regulations. Data at rest encryption is only available on MongoDB Enterprise and Atlas editions using the required WiredTiger storage engine.

When encrypting data natively using TDE, it is important to know how encryption keys are stored in MongoDB. When a database file is encrypted, a unique, private encryption key is generated. Each encrypted database file generates a new private symmetric key, and all keys in your storage device are encrypted using a master key. While the database keys are stored alongside the encrypted data, the MongoDB never allows the master key to be stored on the same server as the encrypted data. This means that the database or security administrator must identify a secure storage location for the encryption key. MongoDB strongly recommends a third-party enterprise key management solutions; however, users have the option to store the key locally using a keyfile. This second option is extremely risky, and almost never recommended for key protection.

For even more information, view our Definitive Guide to MongoDB Encryption & Key Management.

To download this White Paper in it’s entirety, download “Introduction to Encrypting Data in MongoDB” and learn about Encrypting data-at-rest and in-motion in MongoDB, MongoDB vs SQL encryption, encryption performance, and what is key management.

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.

You should be concerned about storing encryption keys in the cloud, but probably not for the reason you think.

One of the most common questions I get about cloud encryption key management is “Who has access to my encryption keys?” As customers migrate to Microsoft Azure and Amazon Web Services (AWS), it is really good to understand the policy implications of cloud service provider encryption key management services. And it is not a topic that cloud service providers like to discuss very much.

The truth is that common key management services such as Microsoft Azure Key Vault and Amazon Web Services Key Management Service (KMS) are under the control and management of Microsoft and Amazon. The user interfaces and APIs available to customers on these cloud platforms are easy to use and very inexpensive, or even free. So they are very attractive to new cloud customers.

So what is the problem?

First, I don’t feel there is a problem with the security implementation of key management services by these cloud service providers. They have great security teams and I believe they take care in both the implementation of the security systems as well as in the hiring and management of the teams that support the key management systems. And you can’t really argue with the cost model of key management services. Cheap or free is always attractive.

The problem originates in the fact that the cloud service provider creates, manages, and owns the actual encryption keys that protect your data. This means that they are subject to law enforcement warrants and national security letter requirements to surrender your data and encryption keys. And you may not be notified of these actions. This is not an issue just in the United States. Many national governments have various legal rules that require cooperation by cloud service providers. Many cloud companies try to be transparent about these law enforcement activities, but transparency can be blocked in many cases.

Should cloud service providers refuse to obey lawful requests for information about their customers? Of course not. We all live in a nexus of laws and regulations that are largely designed to protect us. If a law enforcement warrant is lawfully obtained a cloud service provider would be acting responsibly by complying with a request for copies of your data and your encryption keys. And they may not be able to inform you of that action.

And there is the problem. You might not know what is happening to your information stored in the cloud.

Any responsible executive team in a business or organization would want to know if there was a potential problem with an employee, group of employees, company policy, or operation in a local, federal or international environment. Executives want to be aware of potential problems and respond to them as quickly as possible. In fact, this is a core governance requirement. And they can’t act quickly and responsibly when they are not aware of a problem. And that’s the rub. If you give your cloud service provider access to your encryption keys you may lose the ability to know when a problem arises.

Is there a solution to this problem?

By deploying a third-party encryption key management solution in the cloud or on-premise in your own data center you retain exclusive ownership to the encryption keys and data they protect. Cloud service providers cannot respond to law enforcement and intelligence service actions because they have no administrative access to the encryption keys. This doesn’t mean that law enforcement and intelligence services won’t be interested in obtaining your information. But it does mean that they will have to notify you of their desire to obtain your data. Of course, as a responsible business you will want to comply with these requests. But you will do so with full knowledge of the activity and will the full advice of your own legal counsel. And the process will probably provide you with some clues as to the reason for the action. That’s something you will really want to know.

Retaining custody of your encryption keys means retaining control of your organization’s governance and risk-management controls. And that’s a good thing.

Knowing is better than not knowing.

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

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

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.

It can be difficult to identify IBM i users who have administrative privileges. This is because of the unique nature of IBM i user profiles. An IBM i user has an explicit level of privilege that is easy to determine, but that user can adopt additional privileges through a Group Profile and through any number of profiles defined in a Supplemental Group.

I recently sat down with Patrick Townsend, Founder and CEO, and discussed how to determine the true level of authority of a user profile, control and monitor administrative level users, and set email alerts to include critical job and security information.

Cyber criminals attempt to escalate their level of privilege by stealing and using administrative credentials. Because IBM i servers are accessed from user PCs across internal and external networks, credential stealing from these exposed PCs and networks is the preferred mechanism for compromising an IBM i server.

That’s right.  An attacker will typically compromise a user’s PC and use that as a platform to attack an IBM i server. While it is possible to attack an IBM i directly, I think that is a pretty unusual case.  Normally an attacker will try to determine who in your organization is likely to have elevated privileges and then, using standard attack vectors like phishing emails or poisoned web links, get access to that user’s PC. From that point, it is not difficult to piggyback on that user’s credentials into the IBM i platform – and that gives them access to data from the IBM i, especially if they have elevated privileges.  On the IBM i server, we have a particularly difficult challenge in identifying exactly who has a lot of privilege.  It is quite surprising how many regular users end up with a high level of privilege – and that is because of the hierarchy (Group Profile  and Supplemental Groups) that can be related to  a user profile on the IBM i platform.  If any of those groups that the user is a member of has elevated privileges, so does that user.

To determine a user’s actual level of authority, an IBM i security administrator may have to research dozens of additional accounts. That sounds like a daunting task.

It is.  IBM gives us some security commands to help print information about users, but unfortunately they don’t drill down and give you all the information that you need in one place.  You need to use multiple commands and look specifically at a particular user – which becomes an administrative headache.  Imaging multiplying that by hundreds or thousands of users on an IBM i server and you have got a major challenge in front of you.  At Townsend Security, we are giving the IBM i administrator some new tools in Alliance LogAgent that make this job a whole lot easier.  We will actually chase down those highly privileged users, resolving all of the adopted authorities that they have through group profiles and supplemental groups, and then alert system administrators when a highly authorized privileged user signs on to the IBM i server.  Alerts are sent via email notifications or by special events to your SIEM.   We think we have done a pretty good job of helping the IBM i administrator see and resolve problems with adopted authorities.

That is really cool.  How does it work?

We look at a user profile or a selected subset of user profiles, and for each one we look at what authorities each one has.  Do they have All Object authority?  Do they have control over jobs or audit capabilities?  What authorities do they have?  Then, we drill down into the group profile and ask the same questions.  What authorities are additive to the ones that you natively have? With this information, we start to build a matrix. If a user picks up authority with a group profile, we’ll tell you.  We take the mystery out of where the level of privilege comes from. This makes it easier for an IBM i security administrator to say “Oh my goodness, I have a user profile here who has All Object authority.  That shouldn’t be there!” and make it easier to reign in the number of highly authorized users.

Aside from reporting to a SIEM, there is an email-alerting component as well, right?

Yes.  We send an email in real-time when a highly authorized user signs on to the IBM i server or starts a job (either interactive or batch).  The notification contains information on the name of the user and job – enough information so that a security administrator can easily identify the system where the job is starting.  This gives security administrators a real fast alerting process so that they can identify when a highly authorized user signs on to the system.  That means that they can detect a brute force attack, somebody who has stolen credentials, or even when someone is signing on at an odd time.  If you find yourself saying “Bill in the shipping department has a high level of authority and signed on at 2:00am, there might be a problem here” – you now have a way to see and react very quickly.

What else would you like to tell us about Alliance LogAgent, your log and event monitoring solution?

Alliance LogAgent is a very rich and mature system logging and notification solution and is designed to integrate with any SIEM (IBM Security QRadar, Splunk, LogRhythm, etc.).  Additionally, we do File Integrity Monitoring (FIM) and can pick up changes to a database, even on a field by field basis.  FIM is a part of PCI DSS, for example, and other compliance regulations.  It really allows you to put a very detailed focus on the sensitive data sitting on the IBM i.

Additionally, the security audit journal is not the only place on the IBM i that collects important security information.  We monitor many exit points on the IBM i (FTP, ODBC, etc.) and capture activity and send it to your SIEM.  The communications are all built into Alliance LogAgent – syslog, UDP, TCP, and TLS encrypted sessions to move data in real-time off of the IBM i platform to your SIEM.  The solution allows you to bring your IBM i fully into a continuous monitoring SIEM view of security events on the IBM i.

To hear this interview in it’s entirety, download our podcast “Identify Escalated Privilege Attacks on IBM i” and hear Patrick Townsend, founder and CEO of Townsend Security, further discuss determining the true level of authority of a user profile, controlling and monitoring administrative level users, and setting email alerts to include critical job and security information.