Townsend Security Data Privacy Blog

Excerpt from the eBook "2016 Encryption Key Management: Industry Perspectives and Trends."

Encryption and key management should move from an IT project to an integrated and seamless part of the IT infrastructure. Organizations need to be able to deploy encryption with ready-to-use infrastructure so that encryption ceases to be a barrier. In order to accomplish this encryption and key management solutions must be embedded in the IT infrastructure and enabled by policy. Key management solutions must implement the automation infrastructure that enables this type of deployment. All aspects of the provisioning of an encryption key server from network configuration, system logging, user administration, generation and distribution of credentials, key mirroring, backup and restore, and encryption key management must become API driven through standard web services.

Unfortunately, standards bodies and vendors have been slow to address this critical aspect of key management. While there is some movement to de ne some aspects of encryption key management through web services or add-on solutions like Chef, the net- work and services aspects of key managers have not been adequately addressed. This will continue to make it difficult to move key management into the realm of seamless and invisible critical infrastructure.

Take Aways

• Ask your key management vendor how they implement APIs for server configuration, deployment and management.
• Understand the key management vendor’s road- map and plans for key management automation.
• Ask the key management vendor for examples of customers using their Web services features.
• Understand any vendor licensing restrictions for installing management utilities.

There is No Single Source for Best of Breed Security

Understandably, customers long for a single vendor who can solve all of their security needs. Currently the process of deploying best of breed security involves working with multiple vendors whose products do not interoperate. It means spending a lot of IT resources managing a large variety of vendor products and services. While there are a handful of larger vendors attempting to provide a complete set of products, their marketing language does not match reality and there is no indication that it will for some time to come. 

Looking ahead, organizations should expect to work with a number of security vendors in order to deploy best of breed security for their sensitive data. It is unlikely that this will change in the near future. Smart organizations will identify best of breed applications that are easy to use, and make the resource investments needed to acquire and manage these solutions.

Take Aways

• Always try to deploy the best of breed security solutions and understand that this means dealing with multiple vendors.
• Prioritize your security needs according to risk, and tackle the highest priority items first.
• Understand and empower your IT organizations to acquire and deploy the best solutions. It is always more cost effective to prevent a problem than remediate it after the fact.

CISOs often can have an arduous time getting budget. To top it off, they are tirelessly thinking about how to improve security programs, justify what they are currently doing, and getting the budget they need for next year. When it comes to improving budget, CISOs need to trade their technology hat with a colleague in the sales or marketing department.

When it boils down to it, a CISO is not technology provider, but rather business solution provider. This can sometimes be a hard realization to make. Especially after spending the first part of your career immersed deep in the technology weeds. For the new CISO, and even seasoned veterans, it can be a challenge to learn to sell and market your ideas (and get funding from) the various stakeholders within the company. It is imperative for the CISO to market and sell the security side of the house to the business at large to get what they need.

Speak Their Language
Not too long ago, the CISOs job was to walk to the C-suite and say, for example, “Hey, we need encryption and key management. Give me the budget and I will go make that happen.” Back in the day, they would usually get the money. Now it is more about building relationships and having a business problem to solve.

With times changing, now it is important to better understand what technologies the stakeholders are hearing about and how you can leverage their knowledge of current security events to bolster your security program. Many of the stories that in the past would have been exclusive to publications like CSO Online and Krebs on Security are now showing up in places like Forbes, Businessweek, and the Wall Street Journal – places where your stakeholders go to get information.

When we look at what is being covered by the mainstream media, it is stuff that security professionals have had to deal with for years, but was relatively unknown to the upper echelons of the company. When security admins talk about data breaches, they talk about SQL injections or the best practice for data protection and how to manage a database – IT vernacular.

It is important to remember that the executive team doesn’t speak your language. When they talk about someone impersonating the CEO via email and exposing W2 information, they don’t know that this is called a “phishing attack.” Security professionals know this, but that isn’t what they call it in USA Today. You have to understand how to make those connections and draw those lines for people.

Sell and Market Your Program
You will have an opportunity from time to time to engage stakeholders for 30-seconds to 2 minutes. When you have those chances for an interaction, you need to sell your program. You need to practice it and have it come across very natural and as you would normally talk. Some suggestions:

• Talk about the great things that you are doing and that you want to do more of it
• Make sure that they understand your successes
• Don’t talk about stuff that doesn’t matter – that is not how you get a budget

It is also important to have various elevator pitches, depending on who you are going to be talking with. For example, if you have 30 seconds with a CIO or director, the pitch is going to be different for each one, because they care about different things. Remember, when you talk with them, it has to be about something that they care about. The secret to success is to sell your program and the services of your group. Don’t just talk about building a security kingdom, but rather business solutions.

Often, when you think about selling, you think about selling to the CFO or even the board. You don’t often think about it, but you do in fact have to sell to the SOC (Security Operations Center) manager or other teams or lines of business within the organization. You may not be asking them for funding, but you need to get them on board so that when you do go to whoever you need to make the big pitch to, they will have your back. It is a much easier sell when there is a choir of voices saying, “Yeah, this is what we think that we need. This is the solution that we want. We have already bought into the fact that this is what we need.” If you can get 3 or 4 other directors from different lines of business backing you, you will be much more successful at actually getting funding than if you were to say “This is what I think is needed” and the board replies “What does the SOC manager think?”

If your funders still need more convincing, compliance regulations can often help your cause. Regulations like PCI DSS and HIPAA (as well as others) are constantly evolving, going through review and update, and bringing in stronger language and more stringent security demands. PCI DSS, in particular, carries a big stick. Whether you love it or hate it, it can often get you what you need because your business has to comply if they want to take credit cards.

External audit findings can also help propel your security program forward. When they come back negative, business risk has been identified – and business risk speaks very loudly to the C-suite. It is in their charter to acknowledge business risks and take appropriate actions.

Finally, and unfortunately, there will be times that you are simply told “No, there just isn’t budget for _______.” But what you can do, because you are a smart CISO, is go into your backup pitch. Just because you didn’t hit a “grand slam” doesn’t mean that getting a “single” or a “walk” is out of the question. Your “walk” should be the absolute bare minimum needed to move your cause forward, at least a little. Even the guy that gets walked is going to score from time to time. If you can take a “walk” and deliver something with it, you are going to further gain the trust of your funders and establish a positive track record for delivering on time and on a budget.

Excerpt from the eBook "2016 Encryption Key Management: Industry Perspectives and Trends."

The evolution of computing and delivery platforms continues at a rapid pace and this presents substantial challenges as organizations of all sizes attempt to deploy data protection strategies. Security professionals now know that Data Centric Data Protection, or encryption, is crucial to their security strategy. Deploying encryption means properly protecting encryption keys. This is the biggest challenge organizations will face with their encryption strategy. The large investment required to develop defensible key management implementations, the importance of key management to critical data infrastructure, the rush to cloud and hybrid implementation.

Encryption Finally Takes Off

Encryption of sensitive data, sometimes called Data Centric Data Protection, has not been a high priority in many organizations. Investments in security have focused on deploying endpoint protection such as anti-virus and data leak protection, active monitoring and alerting of system logs, and other security features. While encryption is a core security requirement, it has not had as much attention and many organizations are lagging in this key security control.

The large data breaches over the last two years and the resulting impacts on the executive teams, along with resulting brand damage, has changed all of that. Customers, employees and all other stakeholders expect the highest levels of executive management to be pro-actively involved in the protection of sensitive data. When CEOs lose their jobs over a data breach, the industry is poised for change. Encryption and data protection are now considered cornerstones of a company’s governance, risk management, and compliance regime. Failures in data protection are now perceived as failures at the highest levels of management. Additionally, the State of California’s recent guidance that a minimum reasonable level of security requires the full implementation of the CIS Critical Security Controls, will force organizations to fully adopt encryption protections. This is leading to a rapid re-focus of the security strategy on data protection with strong encryption and key management. This will continue in the months and years ahead.

Take Aways

• Review your defense-in-depth security strategy and move quickly to protect sensitive data with strong encryption and key management.
• Be sure your IT department has a clear inventory of sensitive data across all of you internal systems, cloud solutions, and service providers. Know what is protected and what is at risk.
• Prioritize your encryption projects to address the most sensitive and exposed data.
• Every implementation of encryption needs good encryption key management. Start a remediation plan for any current encryption implementation that fails to properly protect encryption keys.
• Communicate your security strategy to your customers, employees and stakeholders. Let them know that data protection is important.

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

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 (Encrypt, Field Encryption, Encrypted 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.

This is a guest blog by Nick Trenc, CISSP, QSA, PA-QSA, VCP.  Nick is an IT Security Architect at Coalfire Labs.

In any environment where potentially sensitive data is stored using Microsoft’s SQL Server, one of the key issues is how to best protect that data. Microsoft SQL Server does offer several security controls natively, but almost all of them require some sort of extensive configuration and management in order to be done according to security best practices. Additionally, SQL Server’s own security controls do face some shortcomings.

If using SQL Server’s own encryption tools, database encryption keys are stored right next to the data they are used to protect. This makes it easier for would be malicious users to capture both the protected data and the keys used to protect that data.

This is where Townsend Security’s Alliance Key Manager (AKM) comes in to play. Utilizing the built-in SQL support, IT administrators can generate, store, and manage keys within AKM away from the data those keys are used to protect. This enables separation of duties and dual control which are both best practices and requirements of several compliance frameworks.

Alliance Key Manager utilizes the Extensible Key Management (EKM) functionality of SQL Server (Enterprise Edition 2008 and newer) to centrally manage encryption keys. In addition, AKM also includes native support for SQL Server Transparent Data Encryption (TDE) which can be used to encrypt all of the tables within SQL Server. Finally, AKM includes support for SQL Server Cell Level Encryption (sometimes called Column Level Encryption), integrates directly with the Windows Certificate store, and includes features for key caching and mirroring for high availability.

For more information on using AKM to specifically meet PCI DSS compliance within a virtual environment (but also applicable to most environments), please see the VMware Product Applicability Guide for PCI 3.0 published by Coalfire Systems with collaboration with Townsend Security and VMware.

This is a guest blog by Nick Trenc, CISSP, QSA, PA-QSA, VCP.  Nick is an IT Security Architect at Coalfire Labs.

For those protecting the front lines of our credit card data in merchant environments, few other things keep those in charge (as well as IT administrators) awake at night than the threat of a breach. Questions often arise along the lines of: Will my company be able to survive? What can I do to protect myself? How do I prevent my company from being next? And how do I limit any losses should it happen to us?

One of the key components to the protection of cardholder data at any merchant location is the use of strong cryptography along with just-as-strong cryptographic key management procedures. PCI DSS Requirement 3 outlines what the PCI council believes to be the baseline for strong cryptographic key management procedures and is a key element of any PCI DSS audit.

Successful key management with a strong cryptographic algorithm is the best place to start with getting encryption of your cardholder data correctly protected while it is contained within your environment. But key management can be confusing, difficult and downright impossible depending on the size of your environment. Figuring out if your keys are strong enough, or if they are rotated often enough or if they are protected from would-be hackers. On top of that, figure in the ever-increasing complexity of today’s business systems to include cloud, virtual computing, data mining, and others, the ability to quickly and easy manage encryption keys across several platforms and environments becomes key for PCI DSS compliance.

This is where a tool like Townsend Security's Alliance Key Manager (AKM) comes in to play. Available as a physical hardware security module (HSM), a cloud HSM, a virtual appliance (VMware) or in the cloud (AWS, Azure), Alliance Key Manager can help merchants meet PCI DSS requirements for encryption key management by creating, managing, and distributing AES 128-bit, 192-bit or 256-bit encryption keys all without the risks involved with clear-text key administration.

As a QSA, it is certainly encouraging to see a complete encryption solution that removes some of the worries of traditional manual clear-text key management procedures. AKM can relieve pressure to meet portions of PCI DSS Requirement 3 such as the need to render Personal Account Numbers (PAN) unreadable using strong cryptography with associated key-management processes and procedures (PCI DSS 3.4). It directly meets PCI DSS Requirement 3.5.2 to store keys within a secure cryptographic devices such as a HSM along with additional encryption requirements such as 3.6.2 – Secure Key Distribution, and 3.6.3 – Secure Key Storage. In addition, AKM can make PCI DSS Requirements 3.6.6 for Split Knowledge and Dual Control not applicable as there are no manual key-management operations involved. This (virtual) device is a useful cost-effective tool to help meet your PCI DSS compliance.

For more information on using AKM to meet PCI DSS compliance specifically within a virtual environment (but also applicable to most environments), please see the VMware Product Applicability Guide for PCI DSS 3.0 published by Coalfire Systems with collaboration with Townsend Security and VMware.

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

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?

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.

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.

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.

"I am collecting data in Drupal. What data do I need to 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.

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.

Google is doing it.  Amazon is doing it, too.  Apple, Microsoft, Facebook, and Twitter have also been using it.  What is stopping you from deploying two factor authentication on your IBM i?

How do you stop a hacker who has just accessed a username and password that allows them *ALLOBJ authority on your IBM i?  Despite your best efforts at locking down user accounts, including enforcing complex and unique passwords, your most restricted credentials are now in the hands of hackers.
 
For companies who have deployed a two factor authentication solution on their IBM i, the situation is less dire.
 
While the IBM i is generally considered a very secure platform, it is still susceptible to hackers.  Most users access the IBM i via a PC, which are constantly being targeted with Malware.  Malware on a PC can easily capture usernames and passwords, send that information to a hacker, and in turn, open your systems up to a data breach.  Other points of attack include:

• Memory scraping
• Stolen vendor credentials
• Stolen user passwords from external web services

Fortunately, there is still a way to stop hackers who have your top credentials – with two factor authentication.  By requiring two of the following for their users, businesses can easily enhance their security in a cost-effective way:

• Something you know, such as a password
• Something you have, such as a phone or fob
• Something you are, such as a fingerprint

In Verizon’s “2014 Data Breach Investigations Report”, the company found that of the 63,437 total security incidents that occurred in 2013, “stronger passwords would help reduce the number of incidents, but larger organizations should also consider multiple factors to authenticate third-party and internal users.”  The report continued, “Two-factor authentication will help contain the widespread and unchallenged re-use of user accounts.”

Choosing a Two Factor Authentication Solution
Historically, companies used physical tokens (something you have) to provide authentication on the IBM i beyond username and password.  Unfortunately, tokens increasingly do not make fiscal sense for enterprise IT departments who have to deploy, manage, and troubleshoot these tokens.  Further, tokens are not foolproof as the recent attack on RSA proved.

Innovative solutions, such as Alliance Two Factor Authentication, that leverage the phone as a reliable means of out-of-band authentication have emerged. For example, instead of tokens, businesses can simply send an SMS or voice message containing a one-time authentication code to the IBM i user’s phone. This means cyber criminals cannot log into the IBM i without physical control of the actual phone.

Mobile-based two factor authentication solutions have become the preferred choice for businesses who don’t want the added expense of security tokens and the overhead of deploying and maintaining an appliance.  By deploying a two factor authentication solution on the IBM i, businesses can protect their critical data and operations, as well as their reputation, by adding an additional, cost-effective layer of security.

For more information, download the white paper Two Factor Authentication on the IBM i – Security Beyond Usernames and Passwords to learn more about why the IBM i may not be as secure as you think, the need for authentication on the IBM i, and how to meet compliance requirements with two factor authentication.