Townsend Security Data Privacy Blog

Securing data with encryption and protecting the encryption keys with proper key management is enforced by many compliance regulations (and recommended as a security best practice).

When working with private schools, colleges, and universities, Drupal developers who need to protect their customers’ sensitive data with encryption know important compliance elements include the following:

• Awareness of how records are managed by the institution.
  … (Do you know who will have access?)
• Awareness of relevant regulations/laws.
  … (Do you know what they need to follow?)
• Approach to complying with each item.
  … (Do you know what they should do to follow the law?)
• Management of institutional records.
  … (Do you know what they need to keep and for how long?)

It is important to remember when developing a higher education framework, the ultimate core of higher education is information. Each institution gathers, stores, analyzes, retrieves, and secures the information necessary for proper functioning. Without continued and uninterrupted access to that information, as well as assurances that the information is secure and reliable, they would be unable to fulfill their educational, research, and service missions.

For entities in the education sector, it is important to note that data security and IT solutions for colleges and universities also fall under some of the more familiar compliance regulations due to the various programs offered by each institution:

• PCI DSS will come into play with accepting payments from tuition, books, food services, and housing
• GLBA/FFIEC covers the student loan and financial offices at most institutions
• HIPAA/HITECH is also important to consider as most higher education institutions have their own health centers

Driven by student privacy concerns and the need to comply with regulations such as the Family Educational Rights and Privacy Act, educational institutions must also make sure to secure sensitive data and protect their networks from data loss even when that information must be shared.

Family Educational Rights and Privacy Act (FERPA)
Statute: 20 U.S.C. § 1232g Regulations: 34 CFR Part 99

The Family Educational Rights and Privacy Act (FERPA) is a federal law that affords parents the right to have access to their children’s education records, the right to seek to have the records amended, and the right to consent to the disclosure of personally identifiable information from education records, except as provided by law. When a student turns 18 years old, or enters a postsecondary institution at any age, the rights under FERPA transfer from the parents to the student (“eligible student”).

The Higher Education Information Security Council (HEISC), actively develops and promotes awareness and understanding, effective practices and policies, and solutions for the protection of critical IT assets and infrastructures. HEISC also produces the Information Security Guide: Effective Practices and Solutions for Higher Education, an excellent resource for anyone involved in securing student information with encryption.

Drupal adoption in higher education has skyrocketed with over 71 of the top 100 US Universities and educators around the world publishing websites in Drupal. Arizona State University alone hosts over 800+ websites built in Drupal CMS!  To meet the growing need for NIST validated and FIPS 140-2 compliant encryption and key management, the data security experts at Townsend Security partnered with Chris Teizel, CEO of Cellar Door Media and Drupal developer to create the Key Connection plug-in for the Drupal Encrypt module. Key Connection for Drupal provides a secure key management system (Alliance Key Manager) outside of the Drupal installation in order to provide secure key storage and retrieval options. Now when personally identifiable information (PII) is collected or stored in a database it can easily be encrypted and the encryption keys properly managed. Key Connection for Drupal allows developers and users to choose whether they retrieve a key and encrypt/decrypt locally or to send the data to Alliance Key Manager to perform on board encryption.

For more information, download the Drupal Compliance Matrix:

Securing data with encryption and protecting the encryption keys with proper key management is addressed in many compliance regulations and security best practices.  

For business owners, database administrators, or Drupal developers who need to protect their customers’ sensitive data with encryption; storing the encryption keys within the Drupal CMS puts that data at risk for a breach. Depending on your industry, different regulations and standards will require you to implement safeguards on some or all of the information contained within your applications.

The financial industry includes banks, credit unions, and other financial organizations, including venture capital firms, private equity firms, investment banks, global investment firms, bank holding companies, mutual funds, exchanges, brokerages, and bank technology service providers, among others. In order to meet compliance regulations, information security programs must be in place to ensure customer information is kept confidential and secure, protected against potential threats or hazards to personal information (cyber-attack, identity theft) and protected against unauthorized access to or use of a customer's personal information.

If you fall within the financial sector, the following will apply:

The Gramm-Leach-Bliley Act (GLBA) - 15 USC 6801 - of 1999 first established a requirement to protect consumer financial information.
TITLE 15 , CHAPTER 94 , SUBCHAPTER I , Sec. 6801. US CODE COLLECTION
Sec. 6801. - Protection of nonpublic personal information

(a) Privacy obligation policy

It is the policy of the Congress that each financial institution has an affirmative and continuing obligation to respect the privacy of its customers and to protect the security and confidentiality of those customers' nonpublic personal information.

(b) Financial institutions safeguards

In furtherance of the policy in subsection (a) of this section, each agency or authority described in section 6805(a) of this title shall establish appropriate standards for the financial institutions subject to their jurisdiction relating to administrative, technical, and physical safeguards.

The Federal Financial Institutions Examination Council (FFIEC) supports the GLBA mission by providing extensive, evolving guidelines for compliance and evaluating financial institutions. Financial services regulations on information security, initiated by the GLBA, require financial institutions in the United States to create an information security program to:

• Ensure the security and confidentiality of customer information
• Protect against any anticipated threats or hazards to the security or integrity of such information<
• Protect against unauthorized access to or use of customer information that could result in substantial harm or inconvenience to any customer

Federal Reserve Board Regulations - 12 CFR - CHAPTER II - PART 208 - Appendix D-2
-- Interagency Guidelines Establishing Standards For Safeguarding Customer Information--

… III. Development and Implementation of Information Security Program
… C. Manage and Control Risk
Each bank shall:
… c. Encryption of electronic customer information, including while in transit or in storage on networks or systems to which unauthorized individuals may have access.

Enforcement of these financial industry compliance guidelines fall to five agencies: the Federal Reserve System (FRB), the Federal Deposit Insurance Corporation (FDIC), the National Credit Union Administration (NCUA), the Office of the Comptroller of the Currency (OCC), and the Office of Thrift Supervision (OTS). In collaboration, these agencies have developed a series of handbooks that provide guidance, address significant technology changes and incorporate a risk-based approach for IT practices in the financial industry. The "Information Security Booklet" is one of several that comprise the FFIEC Information Technology Examination Handbooks, and references encryption in detail. (Resource Links listed below)

Summary: Financial institutions should employ encryption to mitigate the risk of disclosure or alteration of sensitive information in storage and transit. Encryption implementations should include:

• Encryption strength sufficient to protect the information from disclosure until such time as disclosure poses no material risk
• Effective key management practices
• Robust reliability
• Appropriate protection of the encrypted communications endpoints

To meet the growing need for NIST validated and FIPS 140-2 compliant encryption and key management, the data security experts at Townsend Security partnered with Chris Teizel, CEO of Cellar Door Media and Drupal developer to create the Key Connection plug-in for the Drupal Encrypt module. Key Connection for Drupal provides a secure key management system (Alliance Key Manager) outside of the Drupal installation in order to provide secure key storage and retrieval options. Now when nonpublic personal information is collected or stored in a database it can easily be encrypted and the encryption keys properly managed. Key Connection for Drupal allows developers and users to choose whether they retrieve a key and encrypt/decrypt locally or to send the data to Alliance Key Manager to perform on board encryption.

For more information, download the Drupal Compliance Matrix:

Additional Resources:

Federal Financial Institutions Examination Council (FFIEC)

FFIEC Information Technology Examination Handbooks

Gramm-Leach-Bliley Act (GLBA)

Federal Reserve System (FRB)

Federal Deposit Insurance Corporation (FDIC)

National Credit Union Administration (NCUA)

Office of the Comptroller of the Currency (OCC)

Office of Thrift Supervision (OTS)

Securing data with encryption and protecting the encryption keys with proper key management is addressed in many compliance regulations and security best practices.

Let’s take a look at the Security Rule and Omnibus Rule (update to HIPAA/HITECH compliance regulations) that cover Protected Health Information (PHI) and the data security requirements that affect Drupal developers or users.  When dealing with the healthcare industry, Personally Identifiable Information (PII) is a subset of PHI, and refers to information that is uniquely identifying to a specific individual. Protected Health Information is specific to medical and health-related use and generally refers to demographic information, medical history, test and laboratory results, insurance information and other data that is collected by a healthcare professional to identify an individual and determine appropriate care. To better understand the recent changes in HIPAA/HITECH regulations, here are a few key rules that provide guidance:

The Security Rule

The Department of Health and Human Services (HHS) and the Centers for Medicare & Medicaid Services (CMS) provide guidance around the protection of sensitive data and PHI based on a security series of seven papers, each focused on a specific topic related to the Security Rule. The rule is officially titled “Security Standards for the Protection of Electronic Protected Health Information” (45 CFR Part 160 and Part 164, Subparts A and C) but is commonly known as the Security Rule.In the Security Rule standards on Technical Safeguards [164.304 as “the technology and the policy and procedures for its use that protect electronic protected health information and control access to it.”], encryption and decryption requirements regarding the transmission of health-related information are covered in sections 164.312(a)(2)(iv) and 164.312(e)(2)(ii).

HHS offers the following guidance to render Protected Health Information as unusable, unreadable, or indecipherable to unauthorized individuals:

Electronic PHI has been encrypted as specified in the Security Rule by “the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key” (45 CFR 164.304 definition of encryption) and such confidential process or key that might enable decryption has not been breached. To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt. 

The Omnibus Final Rule

On January 25, 2013, the Office for Civil Rights (OCR) of the U.S. Department of Health and Human Services published the Omnibus Final Rule, entitled “Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules under the Health Information Technology for Economic and Clinical Health (HITECH) Act and the Genetic Information Nondiscrimination Act (GINA); Other Modifications to the HIPAA Rules” (Omnibus Rule), 78 Fed. Reg. 5566. The Omnibus Rule was effective on March 26, 2013, with a compliance period of 180 days, requiring compliance as of September 23, 2013.

The Omnibus Rule Summary:

• Finalizes modifications to the Privacy, Security, and Enforcement Rules to implement the Health Information Technology for Economic and Clinical Health (HITECH) Act, proposed in July 2010
• Finalizes modifications to the Privacy Rule, proposed in July 2010, to increase the workability of the Privacy Rule
• Modifies the Breach Notification Rule, adopted by interim final rule in August 2009
• Finalizes modifications to the Privacy Rule to implement the Genetic Information Nondiscrimination Act of 2008 (GINA), proposed in October 2009

Within the Omnibus Rule, HHS makes it clear that certain provisions of the HIPAA Rules are now applicable to business associates. HHS has expanded the definition of “business associate” (45 C.F.R. § 160.103) to include patient safety organizations (PSOs), health information organizations (HIOs) and subcontractors. Also included as business associates are health information entities, e-prescribing gateways, other persons that provide data transmission services or facilitate access to health records, and vendors of personal health records provided on behalf of covered entities. HHS considers this subcategory to encompass data transmission services requiring routine access to PHI and services that provide personal health records access on behalf of a covered entity. Also, subcontractors (or agents) that perform services for a business associate are also considered business associates to the extent their services require access to PHI. For example, a vendor providing data storage would be considered a business associate if the data included PHI. This would require subcontractors to have HIPAA compliant business associate agreements in place and under the Omnibus Rule, business associates are now directly liable for compliance with the Security Rule. This means they must comply with the Security Rule’s requirements for (1) administrative, physical and technical safeguards; (2) policies and procedures; and (3) documentation in the same manner as covered entities. The protection of PHI falls on a wider set of requirements and more businesses and organizations will be affected by the Security Rule and Omnibus Rule for HIPPA/HITECH compliance.

“This final omnibus rule marks the most sweeping changes to the HIPAA Privacy and Security Rules since they were first implemented,” said HHS Office for Civil Rights Director Leon Rodriguez. “These changes not only greatly enhance a patient’s privacy rights and protections, but also strengthen the ability of my office to vigorously enforce the HIPAA privacy and security protections, regardless of whether the information is being held by a health plan, a health care provider, or one of their business associates.” [excerpt from 2013 HHS press release]

Another important change should be clarified around Safe Harbor. The Omnibus Rule eliminates the Safe Harbor Status, which previously protected a covered entity from a HIPAA violation based on misconduct by a business associate, now holding all parties liable. This is very different from Safe Harbor for Breach Notification that is still in effect if you encrypt sensitive data. As documented by the HHS “We encourage covered entities and business associates to take advantage of the safe harbor provision of the breach notification rule by encrypting limited data sets and other protected health information pursuant to the Guidance Specifying the Technologies and Methodologies that Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals (74 FR 42740, 42742). If protected health information is encrypted pursuant to this guidance, then no breach notification is required following an impermissible use or disclosure of the information."

To address these changes, the security experts at Townsend Security partnered with Chris Teitzel, CEO of Cellar Door Media and Drupal developer to create Key Connection for Drupal in connection with the existing Drupal Encrypt module. In order to provide secure key storage and retrieval options, Key Connection for Drupal provides a secure key management system (Alliance Key Manager) outside of the Drupal installation. Now when protected health information is collected or stored in a database it can easily be encrypted and the encryption keys properly managed. Key Connection for Drupal allows developers and users to choose whether they need to retrieve a key and encrypt/decrypt locally or to send the data to Alliance Key Manager to perform NIST validated on board encryption.

Stay tuned for our next look at data privacy compliance regulations and security best practices that impact developers and users of the Drupal CMS open source platform in regards to protection of financial and educational information. For more information about encryption and key management, download our eBook Encryption Key Management Simplified.

Securing Sensitive Data in Drupal made possible through partnerships!

The Drupal content management system may have started-out in a dorm room, but it has become a very successful open source platform that is being adopted at the Enterprise level. Drupal is running everything from small business websites, universities, robust e-commerce environments, Fortune 100 sites, to projects like WhiteHouse.gov! As Drupal developers build out these large-scale installations, the need to keep them secure becomes more apparent due to the volume of information being collected. Sensitive data such as credit card numbers and protected health information (PHI) fall under industry data security regulations such as PCI-DSS and HIPAA/HITECH and must be encrypted. Requirements for protecting information go beyond just credit card numbers & expiration dates, but includes names, email addresses, ZIP codes, usernames, passwords… any stored data that can personally identify an individual.

Drupal developers and users who need to protect sensitive data know that storing encryption keys within the content management system puts data at risk for a breach, yet storing encryption keys locally in either a file protected on the server, in the database, or in the Drupal settings file has been the norm. None of these methods meet data security best practices or compliance regulations such as PCI DSS, HIPAA/HITECH, or state privacy laws.

While additional compliance regulations may apply depending on industry, this is a basic list of good practical guidance around web-based and virtual environments:

• PCI Security Standards Council (PCI SSC) has issued Cloud Computing Guidelines as well as guidance around virtualization of data protection solutions, so you can be PCI compliant with a cloud-based key management and encryption solution.
• The Cloud Security Alliance (CSA) has also issued good guidance around security in cloud environments in version 3 of their documentation (domain 11 applies to encryption and key management).
• National Institute for Standards and Technology (NIST) also has produced a guidance for security in cloud environments(NIST Special Publication 800-144) which provides excellent guidance for people looking to move into cloud platforms and protect data there.

The Drupal community collaborates to develop modules for the platform, sharing knowledge, experience, and creativity. The developers try to avoid duplicate functionality, so the existing Drupal Encrypt module was used as the first step to protecting sensitive data, however the plug-ins for the Encrypt module did not provide secure key retrieval options as the encryption keys were all still found within that same server. Security best practices tell us that personally identifiable information needs to be protected with industry standard AES encryption and that protecting the encryption key away from the data is critical. It became apparent that a key management system that was outside of the Drupal installation was required.

Working together to solve the Drupal data security problem, the security experts at Townsend Security and Drupal developers at Cellar Door Media have released the Key Connection for Drupal solution, which addresses the need for strong encryption and encryption key management within the Drupal framework. Now personally identifiable information collected during e-commerce checkouts and user account that contain names and e-mail addresses can be easily encrypted, and the encryption keys properly managed, by organizations that collect and store that sensitive information.

Drupal developers and Drupal users share a concern about multiple compliance requirements and the liability that goes along with being audited for correctly protecting personally identifiable information. When designing an environment, there is a need to know what methods of encryption you are using, that the encryption key management is implemented correctly, and how secure will the data collection and storage processes be. The Key Connection for Drupal module allows designers to either retrieve a key and encrypt locally, or send the data to Alliance Key Manager (AKM) to perform on board encryption. They have the choice to use the Alliance Key Manager strictly as a key manager, or they can use it as an encryption service as well.

A few benefits of this new Key Connection for Drupal module are:

• Access to remote key retrieval
• NIST compliant on-board encryption
• Encrypting data locally in your database
• Using a built-in function to allow for PCI compliant encryption to be done off the web server

To learn more, I encourage you to listen to this special podcast to hear Chris Teitzel; CEO of Cellar Door Media, Rick Hawkins; owner of Alchemy Web Solutions, and Patrick Townsend; CEO of Townsend Security, talk about encrypting sensitive data in Drupal. They will also discuss how a Drupal site builder or developer gets access to Key Connection for Drupal, the Alliance Key Manager, and what options are available.