Townsend Security Data Privacy Blog

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 data with encryption and protecting the encryption keys with proper key management is addressed in many compliance regulations and security best practices.

For Drupal developers who need to protect sensitive data in their (or their clients) content management system (CMS), storing the encryption keys within the Drupal CMS puts that data at risk for a breach. Security best practices and PCI DSS compliance regulations call for sensitive data to be protected with encryption and that data-encrypting keys (DEK) be physically or logically separated from the sensitive data and protected with strong key-encrypting keys (KEK).  Depending on what type of information is being stored and what industry guidance your project/company falls under, compliance regulations in addition to PCI DSS may apply.

For any company that accepts credit card payments, the Payment Card Industry Data Security Standards (PCI DSS) issues 12 requirements that must be met in order to be compliant. It can seem overwhelming at first, but the PCI council that issues PCI DSS also provides detailed reference guides and instructions on each requirement. Let’s take a high level look at all twelve items:

Build and Maintain a Secure Network and Systems

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do Not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

Requirement 3: Protect stored cardholder data*
Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Identify and authenticate access to system components
Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that address information security for all personnel

Within the latest documentation by the PCI Security Standards Council (v3.0 released November 2013) specific testing procedures and guidance is given for Requirement 3 on pages 34-43. The PCI Security Standards Council (PCI SSC) website contains this documentation along with a number of additional resources to assist organizations with their PCI DSS assessments and validations. PCI SSC also issues Cloud Computing Guidelines and additional information around virtualization of data protection solutions so you can be PCI compliant with a cloud-based solution for encryption and key management.

Requirement 3 addresses the need for encryption and key management, stating:

“Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.”

In order to address PCI DSS Requirement 3: Protect stored cardholder data; 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 cardholder 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 on board encryption.

Other compliance requirements for protecting information go beyond cardholder data (PCI focuses on PAN or the Primary Account Number specifically) and also require that personally identifiable information (PII) such as names, birthdates, email address, zip codes, usernames, or passwords be protected with encryption and key management. Check back as future blogs will cover additional data privacy compliance regulations and security best practices that impact developers and users of the Drupal CMS open source platform in regards to protected health information (PHI).

For more information on PCI Compliance, download the Whitepaper: "Meet the Challenges of PCI Compliance"

Two Factor Authentication (2FA) and a look at the compliance regulations that require identity verification for remote access.

The use of two factor authentication provides an added layer of security beyond just a username and password. Because passwords can be guessed, stolen, hacked, or given away, they are a weak layer of security if used alone. Since frequent access happens from outside of the network, remote login is considered high-risk and requires additional steps to confirm user identity. Protecting access with two factor authentication adds identity assurance and significantly reduces risk of unauthorized access in the retail, healthcare, and financial industries.

Payment Card Industry Data Security Standards (PCI DSS)

The PCI Security Standards Council has stated that they will continue to change and evolve compliance regulations over time as attacks change. In PCI DSS section 8.3 the requirement states that organizations must “incorporate two factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties.”  The objective of this requirement is to ensure that merchants implement strong access control measures so that authorized individuals with network and computer access can be identified, monitored, and traced.

Requirement 8: Assign a unique ID to each person with computer access. Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for his or her actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users.

Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data.

Requirement 8.3: Incorporate two factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties.

Note: Two factor authentication requires that two of the three authentication methods (something you know - something you have - something you are) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two factor authentication.

Health Insurance Portability and Accountability Act (HIPAA) and the Health Information Technology for Economic and Clinical Health (HITECH) Act

HIPAA was an act signed in 1996 by President Bill Clinton, meant to improve the efficiency of the healthcare system by encouraging the use of Electronic Data Interchange (EDI) when accessing Protected Health Information (PHI). Covered entities must develop and implement policies and procedures for authorizing PHI access in accordance with the HIPAA Security Rule Administrative Safeguards 164.308(a)(4) [Information Access Management: Access Authorization] and Technical Safeguards 164.312(d) [Person or Entity Authentication] and the HIPAA Privacy Rule at §164.508 [Uses and disclosures for which an authorization is required].

The HIPAA Security Rule requirements have most recently been expanded via the HITECH Act, which establishes mandatory federal security breach reporting requirements with expanded criminal and civil penalties for non-compliance. To remain HIPAA compliant and avoid fines for HITECH Act non-compliance, strict control over access to patient records must be demonstrated.

HIPAA/HITECH requirements regarding the transmission of health-related information include adequate encryption [164.312(e)(2)(ii) when appropriate, and 164.312(a)(2)(iv)], authentication [164.312(d)] or unique user identification [164.312(a)(2)(i)] of communication partners. By selecting Two Factor Authentication (2FA), users would be required to combine something they know, something they have, or something they are; thereby providing more secure access to PHI files. Protected Health Information can be account numbers, medical record numbers and geographic indicators among other private consumer information. It is important that only those health care workforce members who have been trained and have proper authorization are granted access to PHI.

Gramm-Leach-Bliley Act (GLBA) & Federal Financial Institutions Examination Council (FFIEC)

The Federal Financial Institutions Examination Council (FFIEC) is charged with providing specific guidelines for evaluating financial institutions for GLBA (Gramm-Leach-Bliley Act) regulations compliance. The FFIEC also provides guidance around the use of two factor authentication to strengthen systems in the financial industry and strengthen banking websites against financial fraud with the document, “Authentication in an Internet Banking Environment” (v.3). For banks offering internet-based financial services, the guidance document describes enhanced authentication methods that regulators expect banks to use when authenticating the identity of customers using online products and services, as follows:

• Financial institutions offering internet-based products and services to their customers should use effective methods to authenticate the identity of customers using those products and services. Furthermore, the FFIEC considers single-factor authentication (as the only control mechanism) to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties.
• The implementation of appropriate authentication methodologies should start with an assessment of the risk posed by the institutions’ Internet banking systems. The authentication techniques employed by the financial institution should be appropriate to the risks associated with those products and services.
• Account fraud and identity theft are frequently the result of single-factor (e.g. ID/password) authentication exploitation.
• Where risk assessments indicate that the use of single factor authentication is inadequate, financial institutions should implement multi-factor authentication, layered security, or other controls reasonably calculated to mitigate those risks.

The FFIEC is a government agency which works with many other government agencies to unify how financial institutions should be supervised. The guideline documents recommend banks treat the FFIEC as baseline compliance for safe online authentication and transaction verification. Since all single factor authentication techniques can be easily compromised, financial institutions should not rely solely on any single control for authorizing high risk transactions, but rather institute a system of layered security with multi-factor authentication.

Although there are varying levels of enforcement, guidelines vs. laws vs. fines, it is clear that two factor authentication plays a critical security role in both compliance and following best practices. This trend will only grow within various industries and throughout the overall data security environment.

Townsend Security offers Easy to Deploy, Cost Effective Two Factor Authentication Solution for the IBM i Platform

Alliance Two Factor Authentication brings mobile SMS and voice verification to the IBM i platform. The solution was built to solve large scale problems in a cost-effective manner and appropriately addresses the concerns raised in the various guidelines and standards listed above. Remote access to networks containing critical payment, patient information, or financial records can be protected with the Alliance 2FA solution using your mobile phone to receive authentication codes.

For more information, request our 2FA Resource Kit! 

Providing Data Security IN the Cloud

The excitement level has been palpable around our office this week as we released the first encryption key manager to run in Microsoft Windows Azure, solving the data security problem that has held many companies back from adopting Microsoft's cloud.  In preparation for this new product, we have had a number of questions to answer, so I thought we should recap a few of them and share an excellent podcast resource with our readers!

What is the main issue that Microsoft Windows Azure customers are experiencing?

The number one concern reported by companies or organizations when they think about moving to any cloud environment is security. The studies show that their biggest concerns revolve around exposure of personally identifiable information and preventing data loss. It is a big enough concern that many companies have held back from migrating mission-critical applications with sensitive data from their traditional data centers into the cloud.  

A few things that are common across many industries and compliance regulations can really help with protecting data in cloud platforms like Windows Azure:

• Use industry-standard AES encryption.
• Keep your encryption keys are separate from the data that's being protected.
• Use dual control and separation of duties to protect your encryption keys.
• Follow best practices in terms of protecting data-at-rest and data-in-motion.

What strategy do you use for deploying a key manager in Windows Azure?

When you are running AKM as a Windows Azure virtual instance it is in a standard or virtual private cloud environment (VPC) allowing for better segmentation and isolation of your key management implementation. You definitely do not want to store encryption keys in the same virtual machine or instance of Windows Azure where sensitive data is stored. That would be like taping your house key to the front door when you leave home! In fact, the core concept for key management is to always separate the encryption keys from the data they protect. 

We know key management is critical to meeting compliance regulations, but is there any guidance about securing data in the cloud?

It is very important for cloud users to protect data using good practical guidance from PCI Security Standards Council (PCI SSC) even if not storing credit card information.  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.

How does your Alliance Key Manager help protect data in Windows Azure?

Our founder and CEO Patrick Townsend says, “I'm rather proud of the fact that we have the first fully cloud-based key management solution in Windows Azure.  Our Alliance Key Manager for Windows Azure solution is a cloud instance that you can deploy directly into Windows Azure to manage encryption keys and protect data. It can be deployed in standard Windows Azure Infrastructure-as-a-Service (IaaS) environment and you can deploy it directly into a virtual private cloud.  It's the same binary code that is in our HSM which is FIPS 140-2 validated and it's running purely within that Windows Azure environment. I am proud of our development team for bringing forth our Alliance Key Manager for Microsoft Windows Azure users as an affordable solution.”

Along with Alliance Key Manager comes applications that deploy, such as our EKM provider, which gives you full protection of Microsoft SQL Server databases and the Microsoft solution applications that run on top of SQL Server. This includes:

• Custom-built SQL Server applications
• Applications in SharePoint using SQL Server as its content database platform
• Microsoft dynamics applications such as CRM and AX and GP that run on top of SQL Server

For custom applications we provide a .NET assembly that you can use to add to your applications to perform encryption either on versions of SQL Server that don't support transparent data encryption (TDE) or on unstructured data that you may be storing in the Windows Azure platform. You are also able to encrypt data going into SQL Azure as well as MySQL or Oracle or any other database that you might be running. Alliance Key Manager comes with a complete library of SDKs and sample code for developers, along with purpose built applications that are ready to plug in and perform encryption, which will get encryption projects up and running very quickly.

“The recent data breaches experienced by so many retailers just highlight the need to protect data with encryption and properly manage the encryption keys.  We really help answer the challenge of protecting data in cloud environments like Microsoft Windows Azure and we are helping people achieve that data protection that they need to feel comfortable moving to cloud platforms.”

Please download this podcast to learn more about securing data in the Microsoft Windows Azure platform:

Every few years since its inception in 2006 the Payment Card Industry Security Standards Council (PCI SSC) has revised and updated the the Payment Card Industry Data Security Standards (PCI DSS) and Payment Application Data Security Standards (PA DSS) to improve security for the payment card industry worldwide. These revisions, clarifications, and new points of guidance are based on considerations and recommendations by experts in the field of data security as well as over 700 organizations that process cardholder data. At the end of their review period, the PCI SSC concluded that revisions needed to be made based on these problematic themes in the payment card industry:

• Lack of education and awareness of how to implement and maintain PCI standards - a major problem since the improper implementation of PCI standards leads to data loss and breaches
• Weak passwords and authentication
• Lack of consistency of responsibility when implementing necessary third party security features
• Slow detection of threats
• Inconsistency of PCI assessments¹

Since the release of v3.0 in November 2013, many organizations affected by PCI DSS and PA DSS are asking: Are there new revisions regarding encryption and key management in v3.0, and what do I need to do in order to meet new recommendations, regulations, and best practices? Luckily, much of version 3.0 hasn’t changed from 2.0. However, many important clarifications have been made. In section 3 of PCI DSS (the section pertaining to encryption and management of encryption keys), version 3.0 makes clarifications regarding these aspects of encryption and key management²:

• Stricter controls around the protection and deletion of authentication data
• Key management procedures must be both implemented and documented
• The requirement of PAN masking
• The critical use of dual control and split knowledge
• The mandate that logical access for disk encryption must be managed separately and independently of the native operating system authentication and access control mechanisms, and that decryption keys must not be associated with user accounts.

Version 3.0 has also split requirement 3.5.2 into two separate requirements to emphasize the importance of both storing encryption keys in a secure location (3.5.2) as well as in the fewest possible locations (3.5.3)²

Based on the themes they found and the revisions made, it is clear that the PCI SSC is moving toward making their regulations stricter. What’s even more interesting is that in this last review, more than half of the recommendations were taken from experts and organizations outside of the United States. This is likely because the United States is farther behind other countries such as the European Union in terms of credit card data security, and since the PCI SSC sets worldwide regulations, they must set standards that meet the highest expectations.

We recommend all organizations worldwide look to the highest standards and follow best practices and recommendations (whether they are required or not) since these evolving requirements are based on current conditions and threats in the data security world and indicate future hardened regulations.

To learn more about encryption key management best practices download NIST Special Publication 800-57 “Recommendations for Key Management: Parts 1, 2 & 3” 

¹ PA-DSS & PCI DSS change highlights

² PCI DSS 3.0 summary of changes

Are You Confident You Are Meeting Compliance Requirements?

Why do we have so many different compliance regulations that affect our companies and our need to protect data? The fact is that there are people out there trying to access that sensitive information and devastating data breaches happen on a regular basis. While breaches are very difficult for companies that suffer the loss of customers, brand damage, and stiff financial penalties, it is the consumers and individuals who are most impacted by the loss of personal information, credit card numbers, or bank account numbers. Because these breaches happen and have such a catastrophic effect on individual people, state and federal and private regulations have been necessary to help motivate companies to try to protect that sensitive information and keep it out of the hands of those who would use it to commit the financial crime and fraud.

Since most companies fall under a number of compliance regulations, here is recap of the most predominant points:

PCI Data Security Standard (PCI DSS) applies to merchants, public or private, who take credit cards for payment. While PCI DSS applies to payment cards, credit cards, and debit cards (anything to do with electronic payments) there are some core components of section 3.5 and 3.6 that require encryption and proper key management:

• You must encrypt credit card numbers
• You must use an industry standard encryption (AES)
• You must provide proper management of encryption keys
• You must have dual control, split knowledge, separation of duties

PCI section 10 requires logging:

• Tracking user access to core resources
• Collecting security events in an un-modifiable log
• Consolidate the logs across all of our servers
• Monitor them for potential breaches

HIPAA/HITECH Act covers the medical segment and any partner entity under thefederal law has to comply with data protection for protected health information (PHI) of patients and must meet requirements about protecting patient information and PHI. The most recent meaningful use guidance was very clear that organizations who fall under HIPAA/HITECH must protect patient health information and we must use proper key management as a part of any encryption strategy. They were quite blunt when they said ‘don't store encryption keys on the device with protected data’... there is no gray area there!

GLBA/FFIEC applies to the financial industry (bank, credit union, trading organization, credit reporting agency). Gramm Leach Bliley Act sets standards for protecting information and consumer information. The FFIEC is responsible for publishing guidance, actually performing audits, and enforcing the standards set by GLBA around encryption and key management best practices.

Sarbanes-Oxley (SOX) applies to public traded companies (section 404 - information technology and data protection for stakeholders). SOX provides detail around data protection, guidance around cryptographic key management, and security requirements for data management. They issue very strong guidance for encrypting sensitive data of personally identifiable information (PII) that is being managed by a publicly traded company. SOX closely mirrors the National Institute of Standards and Technology (NIST) which publishes best practices guidance for encryption key management, key management lifecycles, and logging.

In the United States we have a number of state privacy laws, some of them mandate encryption, others strongly recommended it. These laws apply to both public and private organizations of all sizes and provide guidance for breach notification and penalties around data loss. There is a wide recognition that protecting data using industry-standard encryption and proper key management is a basic common safe harbor from having to do breach notification. Additionally there is a proposed federal privacy law that will eventually replace the individual state laws.

What elements do all of these regulations have in common?

• All are expecting organizations to secure personally identifiable information (anything that can be actually used to individually and specifically identify somebody) with encryption or tokenization and actively monitor their systems
• Laptops, mobile devices, removable storage, tape archives, or backup archival files must be encrypted
• Requirements that vendors, business associates, and service providers must meet the same regulations of the industry they are serving
• Multiple regulations may apply to one company (ie: a doctors office that takes credit card payments would fall under PCI DSS and HIPAA/HITECH)

One of the biggest points of audit and compliance failure is around the encryption key management strategy. While compliance regulations do not mandate FIPS 140-2 validation on a key management solution, auditors will red flag encryption or key management that's not industry-standard. They're looking for certifications like NIST validation of AES libraries or other encryption components and FIPS 140-2 validation of key management solutions. Once you encrypt your data with AES, encryption keys are the secret that you must protect. The nature of an encryption key is that it is unique to you.  It cannot be easily detected or reverse engineered from the data itself. Look to NIST for recommendations about how to manage the creation and lifecycle of an encryption key (when it should be rotated or changed).

What do auditors look for in certifications and standards?

• Standards-based encryption (AES)
• FIPS 140-2 validated key management
• Security best practices of dual control, separation of duties, and split knowledge
• Policy based security

In terms of developing a data protection strategy, apply the best and strongest data protections provably based on industry standards and security best practices to all sensitive data and remember:

• Regulations are getting more stringent and specific… not less!
• Fines and penalties are getting steeper… not cheaper!
• Define personally identifiable information (PII) broadly…not narrowly!

Also crucial when you begin to consider a data protection strategy and your data is moving across multiple operating systems, databases, and platforms is to look for a common approach to encryption and key management, it will be very helpful in reducing costs and maintenance over the long-term.

I’ve included a link to our recently recorded webinar, which focuses on the IBM i system, but is applicable across most platforms.  There is a great deal of detail and information on how we can help you address compliance regulations and the four core components of a data protection strategy (on the IBM i, or Windows, or Oracle, or a number of other platforms) for which Townsend Security provides solutions:

• Encryption
• Data at rest – AES Encryption
• Whole file encryption with PGP
• Tokenization
• Encryption Key Management
• Secure System Logging

Please request the webinar download!

Make sure you don't turn a blind eye to data security!

The basic concept of converting sensitive data into a form that could not be easily understood if it was to be seen by the wrong audience goes back as far as 500 BC (Atbash Cipher), some would even argue that in 1900 BC a simple hieroglyphic substitution was the first form of cryptography. While technology has made great advancements in recent years, it has also created an even greater need for privacy of sensitive information. Whether you are the Chief Security Officer, IT personnel, or database administrator; you should know how your company is handling sensitive data. In fact, security is the responsibility of every business owner and employee. Not using secure passwords can lead to a data breach just as not following key management best practices can provide access to people with malicious intent. When awareness around data security reaches every department and individual, then the company can not only meet compliance regulations, but can benefit from effective data security. Compliance regulations require (or strongly recommend) all industries following best practices for encryption and key management . Do you know which of these apply to you and your company? For example, if you take credit cards for any reason, you fall under Payment Card Industry - Data Security Standards (PCI-DSS). Other common regulations are:

• HIPAA/HITECH ACT requires security of Protected Health Information (PHI) in the medical sector.
• GLBA/FFIEC sets regulations for banks, credit unions, credit reporting agencies, and anyone in the financial industry.
• FISMA is for Federal US Government Agencies.
• The Federal Trade Commission (FTC) also gets involved with anyone who issues a privacy statement.
• More than 45 states also have their own privacy rules, in addition to the ones listed above, that strongly recommend encryption of any personally identifiable information (PII).

So, beyond compliance with regulations, why should you care about encryption… First of all, your customers, clients, and suppliers all expect you to protect their sensitive data. Effective encryption and key management can provide your company with a number of other benefits as well. Here are just a few basic benefits of effective encryption key management:

• Peace of Mind - While hackers and identity thieves are getting smarter and regulations are getting more complex, data protection technology is also improving at a rapid rate. Encryption and key management options are now available in virtual machines and cloud environments as well as hardware security modules(HSMs). How well would you sleep at night if you kept your house key under your welcome mat?
• Reputation - Whether information is lost due to a hacker or a hurricane, if a company loses all of it’s important data, the whole business could be ruined. However if sensitive data is lost because mechanisms for protecting it are not in place, then an organization has even bigger problems. The most effective way to secure data and ensure the integrity of a company is to deploy encryption and properly manage the encryption keys.
• Credibility - Beyond audit requirements, organizations need to consider the security of their customers Personally Identifiable Information (PII). Being able to protect your clients with strong key management practices can add a level of trust and confidence that will help grow your business.

Mobility is also great benefit! As more people move their data to the cloud or virtualized environments the need for encryption increases, and the importance of key management becomes even more evident. In order to maintain control over your data, and the privacy of your customers, information must not only be encrypted but kept secure while in motion, in use, or at rest. By properly managing your encryption keys, you are still in control of your data no matter who is sharing your infrastructure.

In this complimentary eBook, "Turning a Blind Eye to Data Security”, authors Kevin Beaver, CISSP; Patrick Townsend, and Todd Ostrander will teach you about:

• Tools and resources to begin the discussion about data security in your company
• 5 Common misconceptions about data security
• 6 Questions to ask your CIO

Going Beyond Compliance Requirements with Encryption Key Management

If you are new at protecting data in Microsoft SQL Server environments, generally compliance regulations are what drive an encryption project.   In the past, encryption has had a reputation for being difficult to do, complex, and  time consuming, we hope to show you how that has changed.  

To start us off, here are a few definitions and acronyms that may help:

• AES – Advanced Encryption Standard – this is the most common standards based encryption that is used to protect data whether that is in SQL Server or any other environment where data-at-rest is protected.
• EKM – Extensible Key Management – within the Microsoft SQL Server environment EKM is a part of the Enterprise edition 2008/2012 and higher
• HSM – Hardware Security Module – the Townsend Security HSM encryption key management product is Alliance Key Manager
• FIPS – Federal Information Processing Standard
• NIST – National Institute of Standards in Technology

Since it wasn’t thought of as something that improved the “Bottom line” by increasing revenue or decreasing expenses, encryption has historically been a project solely driven by the need to meet compliance regulations.

There are a large variety of compliance regulations that most, if not all, businesses fall under. One common misconception about compliance regulations is that they don’t equally apply to both private and public companies. To clarify, these regulations apply to all companies, of all sizes, whether they are privately-held or publicly-owned. For example, if you take credit cards for any reason, you fall under Payment Card Industry - Data Security Standards (PCI-DSS). Other common regulations are:

• HIPAA Data Security & HITECH Act of 2009 which applies to Medical Providers and the healthcare industry.
• GLBA/FFIEC apply to banks, credit unions, credit reporting agencies, and anyone in the financial industry.
• FISMA is for Federal US Government Agencies.
• The Federal Trade Commission (FTC) also gets involved with anyone who issues a privacy statement.

More than 45 states also have their own privacy rules, in addition to the ones listed above, that strongly recommend encryption of any personally identifiable information (PII).

So, beyond compliance with regulations, why should you care about encryption… and what is it anyways?  First of all, your customers, clients, and suppliers all expect you to protect their sensitive data.  Hackers and data thieves are targeting mid-sized companies because, as larger companies get better at securing sensitive information, the hackers see smaller companies as better targets.  Financial fraud and data breaches become more common in those businesses that might not be as prepared without the resources to have an internal security team. Data loss can have a big impact on a company's reputation as well as their financial health.

AES encryption is a mathematical formula for protecting data.  It is based on a proven, well-known algorithm and standards published by NIST.  But since that formula is a open and vetted standard use, it is not the mathematical algorithm that is the big secret.  It is what happens with the “Key” that locks and unlocks the data that all the fuss is about.

Key management is so important because the encryption keys are THE secret that must be protected.  Without access to the key, a hacker that accesses encrypted data has no way to read it.  Industry standards and best practices for encryption key management, as well as compliance regulations that require proper encryption key management, all state that storing encryption keys on the server with the protected data is a poor security practice.  Encryption keys are unique and cryptographically secure, and once created, protecting the key is the core practice that will protect the sensitive data.  It will not be defensible in the event of a data breach if the keys were stored in the same server as the data.  (Akin to leaving the key to your house in the door lock and being surprised that someone has entered uninvited!)

Our solutions help Microsoft SQL Server customers really protect their data.  Alliance Key Manager, our encryption key management hardware security module (HSM), is FIPS 140-2 certiied.  This means it meets Federal standards that private enterprises expect around key management.  We provide encryption key management solutions for every version and edition of SQL Server starting with SQL Server 2005.

Please join our founder and data security expert, Patrick Townsend, in this 30-minute webinar that will cover encryption and key management best practices with Microsoft SQL Server!

As always, your comments and feedback are appreciated! 

The updates to the HIPAA/HITECH Act Meaningful Use standards were recently released and indicate a stronger urgency by Health and Human Services (HHS) to encourage healthcare companies to encrypt sensitive patient data in order to protect that data and avoid data breach notification.

I recently sat down with Patrick Townsend, CEO & Founder of Townsend Security, to discuss what these meaningful use updates mean and how healthcare organizations should respond to the recommendations:

If you’re a healthcare organization, and you are wondering if you should be encrypting your electronic data, the straightforward answer is yes. Patient information should be encrypted at rest and in transit, and HHS will really start to bring down the hammer in terms of fines and penalties for those who have a data breach and have not encrypted data. We live in a time when a data breach is no longer a matter of “if” but “when,” and encryption is really an insurance policy to protect your organization when a data breach happens to you.

HHS still does not mandate that health care organizations encrypt sensitive patient data, but the meaningful use updates reiterate that they should encrypt their data.

The original HIPAA law and HITECH Act of 2009 did not mandate encryption of electronic patient information. However, HHS has the ability to set rules in a number of areas, and they have added stricter rules around data privacy by mandating that all data breaches must be reported to HHS. Data breach notification typically results in hefty fines and other financial losses associated with brand damage and credit monitoring for affected patients. HHS has been very clear that the only way to avoid breach notification and the impacts of a data breach, is to encrypt patient data. In these most recent updates, they reaffirmed that the only safe-harbor from breach notification is encryption.

Many organizations believe they can prevent a data breach by using strong passwords and other network security tactics such as access control lists. It's true that those actions fall within the purview of the law, but they will not help you avoid breach notification.

Another piece of the update of meaningful use concerns encryption keys. Encryption keys that are used to protect data should not be stored on the same server with encrypted patient information. HHS is trying to give better and clearer guidance on this to the best of their ability while staying within the law.

To learn more about encrypting protected health information (PHI) and achieving safe-harbor from data breach notification, download our podcast, “HIPAA/HITECH Act Breach Notification Meaningful Use Update.”