We all know that in today’s climate of information technology, the steps we take to secure sensitive data must go beyond simply using passwords and firewalls. However, many organizations are still hesitant to adopt encryption and encryption key management, even when it’s mandated by industry regulations and is the strongest safeguard against a data breach. In our new eBook, we’re asking, “What’s preventing you from implementing strong data security?”

Encryption and encryption key management have a reputation for being costly and difficult. This reputation causes organizations a lot of fear. Many people ask themselves, will an encryption and key management project overtake my time and resources? Will it consume my budget? Will it slow down my systems? The good news is, with evolving technology these fears are now based simply on misconceptions. For many organizations, especially those using the cloud, the cost and ease of an encryption and key management project has been greatly improved due to reduced complexity of the Technology. Also, the idea that encryption and key management severely affect performance is usually a misconception of how encryption and key management work in an IT environment, and with proper key management technology, the fear of losing an encryption key is nearly void.

To learn how to overcome the top five most common fears of implementing encryption and encryption key management, check out the excerpts from the new eBook below!

1. Will encryption & key management affect performance on my systems?

One of the most common fears about encryption and encryption key management is that encrypting data will severely impact system performance. It’s true that encryption will have some impact on performance, but if done right, encryption should rarely impact your performance more than 2-4%. Performance impacts can also vary based on the amount of data you’re encrypting and whether you’re doing whole disk, column and field level, or application level encryption. Because encrypting data at any level is difficult to get right, many organizations that attempt “do-it-yourself” encryption solutions see a much higher performance impact…

2. Encryption & key management is too complicated

In the past, managing encryption keys was incredibly complicated as well as costly and time consuming. Specialized solutions had to be developed for an organization’s specific IT infrastructure in order to provide access as well as limit control to certain users. These projects would take months of development to complete and be complicated for an administrator to manage.

Today encryption and key management is easy with SDKs, sample language libraries, and ready-to-use client side applications provided by key management vendors. Little-to-no programming is required by the user at all, and keys can be automatically generated so that complex configuration steps are entirely eliminated...

3. What if I lose a key?

One of the greatest fears of encryption is key loss. If an organization encrypts data and then loses the encryption key, unless they’ve made a backup of the key or restore access to the key, the data becomes permanently unusable. This could be a nightmare for those encrypting millions of pieces of data, such as customer credit card information that needs to be read and retrieved daily in order to complete transactions and maintain business continuity.

While the fear of losing a key is legitimate, the keystone of a successful encryption solution is encryption key management, which is the primary solution for managing, storing, and most of all, protecting encryption keys...

4. Encryption key management is too expensive

Today, a reputable encryption key management vendor will never overcharge you or have hidden fees or costs, and will provide you with information to help you find the right solution, free of charge.

The climate of data security is always changing. However, one thing we know for sure is that hackers are never going away. Hacking is a profitable and growing industry. Firewalls and strong passwords are no longer considered adequate means for protecting sensitive data...

5. My IT staff is too small!

Another common fear is that an organization’s IT department is too small to handle a project like implementing encryption and encryption key management. Encryption key management has a reputation for being incredibly difficult to implement, and many administrators assume that the time and manpower that must be diverted to complete an encryption key management project isn’t worth doing the project at all.

Although this reputation held true ten years ago, encryption key management today has become so simple that in many scenarios it can be implemented in just a few minutes…

To continue reading, download "Overcome the Top 5 Fears of Encryption and Key Management" today.

Data security in Drupal is a top concern. Townsend Security recently launched our Drupal Developer Program to engage Drupal developers in building stronger, more secure websites, and to give back to the Drupal community by creating a collaborative network of Drupal developers concerned with data security and compliance regulations. Members of the Drupal Developer Program gain free access to Alliance Key Manager, our FIPS 140-2 compliant cloud key manager, as well as NIST-validated AES onboard encryption, for non-production testing and development.

Many Drupal developers today run up against tricky situations when developing websites that collect sensitive data such as payment card information, personally identifiable information (PII), and user passwords--not just commerce information. Developers are asking themselves, “what compliance regulations do I face”, “which data needs to be encrypted”, and “how do I do encryption and key management right to meet compliance?”

With Key Connection for Drupal, an API designed to offboard encryption keys to a secure key server, encryption and key management is made easier than ever.  Now Drupal developers can join the Drupal Developer Program and learn how to do encryption and key management right.

Here are the top reasons to consider joining the Drupal Developer Program:

1. Encryption and key management is critical to effective data security in Drupal website development.
Today, Drupal is a top CMS for all kinds of websites. Some of these websites, such as commerce, health, and government websites collect sensitive data from users that must be encrypted under compliance regulations such as PCI, HIPAA and FISMA. These compliance regulations also have clear language strongly recommending, if not requiring, encryption and key management.
As Drupal developers take on larger clients, these compliance regulations become a greater concern. Historically, the Encrypt module could be used to encrypt any sensitive data collected; however, there was no adequate means to protect encryption keys. Today, with Key Connection for Drupal, developers can help their clients manage encryption keys away from encrypted data on a secure key server and create websites that effectively protect sensitive data.

2. Learn how to encrypt sensitive data and properly manage encryption keys
In the last year, many of the largest data breaches could have been avoided if proper encryption and key management was implemented. Within the Drupal Developer Program, Drupal developers can learn how to implement encryption and key management into their projects from the ground up. Encrypting and management encryption keys is actually quite easy now in Drupal, and learning how to use these tools will prepare Drupal developers for larger projects that require strong data security.

3. Implement strong data security in your web development projects from the ground up
Adding data security after-the-fact is difficult. Building your websites and applications using strong encryption and key management from the ground up prevents data security projects from turning into a massive headache. The Drupal Developer Program allows developers to test encryption and key management in their projects from the start to avoid a complicated project down the road.

4. Build your knowledge of compliance requirements and help to educate your colleagues
Our Drupal Developer Program is designed to educate developers on encryption and key management best practices as well as any compliance regulations you may face. We continuously offer resources to help you learn what you need to know to meet PCI DSS, HIPAA, GLBA/FFIEC, FISMA, and other compliance regulations, as well as state privacy law requirements.

5. It’s free!
There’s no charge to join our Drupal Developer Program. With free access, we hope to give Drupal Developers the freedom to learn about, test, and implement strong encryption and key management so that you will become a security thought leader in your own organization!

Encrypting data in Microsoft SQL Server is easy to do, yet often difficult to understand because of the different encryption options offered in various versions.

It used to be said that “encryption is the hardest part of data security, and key management is the hardest part of encryption”. While that may have been true a few years ago, we are constantly working to make affordable, easy-to-use, defensible solutions that meet security best practices and industry compliance regulations. Separating and managing the encryption keys from the data they protect is still one of the biggest challenges in terms of doing an encryption project right, so let’s take a look at what encryption & key management options are available for SQL Server users.

If you are running the Enterprise Edition of SQL Server, version 2008 or newer, you have access to Microsoft’s architecture for encryption called Extensible Key Management (EKM). This provider interface allows for third-party key management systems to be easily incorporated in order to separate encryption keys from the encrypted data they protect. A key management solution should provide Windows client libraries, guidance, and sample code within the solution.

The SQL Server EKM architecture supports:

Transparent Data Encryption (TDE)
With TDE, the entire database table (including the logs you are collecting) is encrypted.  It is a very easy mechanism to use for encryption and since it is transparent, no application level changes are needed, it only takes a few commands to implement. TDE protects data at rest, including backups and log files.

Cell Level Encryption
Also known as column-level encryption, this allows for you to selectively encrypt certain columns of information in your database. This option makes sense if you have large databases of information, and only access encrypted columns periodically.

If you are running older versions of SQL Server (pre-2008), or using non-enterprise editions such as standard, web, or express; you do not have access to TDE or EKM. You still have good options for protecting your data with encryption, just remember the encryption key needs to be separated from the encrypted data it protects.

When you don’t have the EKM architecture, another option for encrypting data in your SQL Server database is to perform encryption and decryption at the application layer using .NET-based encryption. All editions of SQL Server support the ability to perform encryption from within the .NET framework with very straightforward code functions.

C# and VB.NET Application Encryption
If you are developing in .NET you only need to plug in the client side application and implement a few lines of code for your encryption and decryption calls.

Column Level Encryption
Another approach would be to combine User Described Functions (UDFs) with triggers and views to help automate the encryption and decryption at the column level.

Moving SQL Server Data to the Cloud

As more companies migrate their applications and data to the cloud, there are security issues to consider before making that move. Microsoft Azure SQL Database (MASD) -which has also been called SQL Azure, SQL Server Data Services, SQL Services, Windows Azure SQL Database- is a cloud-based service from Microsoft offering database capabilities as a part of the Azure Services Platform. The service is easy to use and readily available, just know that there are some constraints and some features of EKM that are not available when using MASD.  

Most businesses migrating to the cloud will choose to run virtual machines that contain the Windows OS and a full implementation of the SQL Server database. By using a virtual machine, encryption and key management, including EKM with TDE, can be fully supported and provide the level of security you expect and compliance regulations require!  

You have many options still available for your key management solution when your data has been moved to the cloud. Our NIST validated, FIPS 140-2 compliant Alliance Key Manager solutions are available as:

• Hardware Security Module (HSM) - a hardened appliance that you can rack up in your own data center
• Cloud HSM - dedicated hardware device in our hosted cloud environment
• VMware - deploy as a virtual appliance
• Cloud - deploy in Windows Azure, Amazon Web Services, or IBM Cloud as a standard cloud instance or virtual private cloud

To learn more about encrypting data on SQL Server, managing encryption keys, and how we are helping companies protect their data with Alliance Key Manager, download the podcast on Encryption Options on SQL Server.  

Security is the biggest barrier to cloud adoption, and encryption of sensitive data is the hardest part of security. Once you decide to encrypt your sensitive data, getting encryption key management right is the biggest challenge. Storing an encryption key in the same cloud instance with the protected data is faux security, and won’t pass the sniff test in any audit or review of security best practices. So, where do you store the encryption keys?

In Amazon Web Services (AWS), you now have a new key management option that perfectly fits the AWS architecture and usage model, enables security best practices such as Separation of Duties and Dual Control, and provably meets industry standards such as FIPS 140-2.

Alliance Key Manager for AWS extends our Cloud Service Provider support to the popular Amazon platform alongside our existing cloud support for Microsoft Azure, IBM Cloud, and VMware vSphere cloud platforms. For cloud users who need dedicated key management HSMs, our existing Alliance Key Manager Cloud HSM solution will serve AWS customers.

Alliance Key Manager for AWS uses the same FIPS 140-2 compliant technology as our network-attached hardware security module (HSM) solution. You can deploy the Alliance Key Manager AMI directly from the AWS Marketplace, and have a functional encryption key management solution dedicated to you and ready to use in SECONDS with an automatic 30-day evaluation license. You do not share any part of your key management with anyone else, and you have exclusive management of encryption keys. There is no aspect of key management administration that is under the control of Townsend Security, the cloud provider, or anyone else. There is no part of your encryption key that is shared with Townsend Security, and no dependence on any encryption service outside of your key management AMI.

Customers who register with Townsend Security get access to our encryption applications, SDKs, customer support, extended documentation, developer program, and optional Premium support. It’s the perfect AWS key management solution for both small organizations and large enterprises who want to deploy an affordable key management solution based on industry standards and certifications.

In addition to traditional key management, Alliance Key Manager for AWS implements Encryption-as-a-Service. You don’t have to retrieve an encryption key, perform encryption in your application, and then zero the encryption key. To minimize the chance of exposing the encryption key to loss, you can directly send data to the key manager and have it encrypted and returned to your applications. You leverage Alliance Key Manager’s NIST-validated AES encryption and the key never leaves the key manager.

Until now Amazon Web Service customers had no access to simple, affordable, and compliant encryption key management solutions. All of that has changed with Alliance Key Manager for AWS.

Enjoy.

Patrick

Implementing strong data security to protect sensitive data is a top priority for many businesses. Not only does processing and storing sensitive data put you at risk for data loss or breach, it also means that you must meet certain industry regulations and possibly undergo periodic data security audits. Encryption and key management is required if not strongly recommended by many industry regulators such as the Payment Card Industry (PCI) and HIPAA; however, these technologies have a reputation for being difficult, costly, and causing severe impact on server or application performance.

Today this reputation doesn’t holds true, and these common fears can, in fact, get in the way of implementing a strong security solution.

Fear #1 : Encryption & Key Management Will Affect Performance On My System and Applications
One of the most common fears about encryption and encryption key management is that encrypting data will severely impact system performance. It’s true that encryption will have some impact on performance, but if done right, encryption should should never impact your performance more than 2-4%. Performance impacts can also vary based on the amount of data you’re encryption and whether you’re doing whole disk, column and field level, or application level encryption. Because encrypting data at any level is difficult to get right, many organizations who attempt “do-it-yourself” encryption solutions see a much higher performance impact.

Application level encryption is considered the best way to encrypt sensitive data as well as the most difficult. Within an application, an administrator can be selective about which types of data should be encrypted, and which data can be stored in the clear. Therefor the encryption is targeted and only performed on necessary data, which reduces overall performance impact. If done properly, application level encryption will not interfere with your applications.

Fear #2: What if I Lose an Encryption Key?
While the fear of losing a key is legitimate, the keystone of a successful encryption solution is encryption key management, which is the primary solution for managing, storing, and most importantly, protecting encryption keys. Unlike a “key storage” solution, a cryptographic encryption key manager is typically a NIST FIPS 140-2 compliant hardware security module (HSM) or virtual machine in the cloud that manages key storage, creation, deletion, retrieval, rotation, and archival. Many key management solutions are also produced in pairs, with one located in a different geographical location for high availability. If doing encryption key management right, you will never lose an encryption key.

Fear #3: Encryption Key Management Is Too Expensive
Perceived cost is a common barrier for many organizations. However, cutting corners and choosing a third-rate solution is a lot like choosing the cheapest and least reputable car insurance policy: it might get you through the day, but should you ever have an accident, you’ll deeply regret it. Data breaches are no longer a matter of “if,” but “when,” and when a breach happens, it might be the kind that costs you your entire business. Luckily, strong, certified encryption key management solutions are becoming less costly as demand rises and data moves to the cloud. Cost should never be a barrier to good security, and choosing a subscription-based cloud key management solution might be your best way to overcome any cost barriers.

Fear #4: My IT Staff is Too Small
Another common fear is that an organization’s IT department is too small to handle a project like implementing encryption and encryption key management. Encryption key management has a reputation for being incredibly difficult to implement, and many administrators assume that the time and manpower that must be diverted to complete an encryption key management project isn’t worth doing the project at all.

Although this reputation held true ten years ago, encryption key management today has become so simple that in many scenarios can be implemented in less than ten minutes. Of course, ease of implementation always varies depending on your IT infrastructure, platforms, and applications; however, a reputable encryption key management vendor knows that IT departments vary and can work with a variety of platforms in multi-platform environments.

To learn more about encryption key management, download the eBook, Encryption Key Management Simplified.

Understanding Options and Responsibilities for Managing Encryption in the Microsoft Azure Cloud

In this latest white paper, authored by Stephen Wynkoop (SQL Server MVP, Founder & Editor at SSWUG.ORG), Stephen will address how “data at rest is data at risk”, specifically looking at the Microsoft Azure Cloud as a selected platform.  The author covers a wide array of information, and discusses in detail how critical it is to do the important work of protecting information in a way that works both with your applications and with the compliance regulations & requirements that impact your company and industry.

Each of the key topic areas below are addressed in detail in the white paper:

Architecture Decisions Drive Technology Approach

The options range from fully-managed data storage and access (Windows Azure SQL Database, WASD) to setting up a SQL Server with a Virtual Machine instance. Each certainly has its place, but there are big differences in options they support.

• Virtual Machines
• Key Decision Points, VMs
• Windows Azure SQL Database  (WASD)
• SQL Server and Data Encryption Choices

Impact of Encryption

Encryption, and the impact of encryption on your systems, is a big area of concern for those deploying it. Three different areas are important to consider when impact on systems is considered.

• Performance
• Backup and Restore Operations
• High Availability

Key Management Fundamentals

There are core best practices to consider while you’re deploying your selected solution. Some are procedural while others are software/hardware implementations. Keep in mind that the key is to protect your most important secret: the encryption keys. You must provide for protection of the encryption keys, while still providing for access, updates and rotation (key management) of those encryption keys throughout their lifecycle.

• Segregation of Duties
• Dual Control & Split Knowledge
• Key Rotation
• Protection of Keys
• Access Controls and Audits, Logging

The author also covers how Townsend Security’s Alliance Key Manager provides answers to these challenges of working with the Microsoft Azure Cloud, securing information with encryption, and the critical need to manage the keys. For more information on Alliance Key Manager for Windows Azure, download our solution brief or get started with a complimentary 30-day evaluation

Author Bio: Stephen Wynkoop

Stephen Wynkoop is the founder and editor for SSWUG. ORG – the SQL Server Worldwide User’s Group where he writes a column and maintains the site overall. SSWUG features a weekly video programs about the database and IT world, webcasts, articles, online virtual community events and virtual conferences several times a year. Stephen is a Microsoft SQL Server MVP and the author of more than 10 books, translated into at least 7 languages. Stephen has been working with SQL Server since the very first version, with a prior experience in database platforms that included dBase and Btrieve. Stephen can be contacted at swynk@sswug.org.

Is there more to encryption key management than just storing my encryption keys?

There is far more to encryption key management than just storing the encryption key somewhere… as it turns out, there is a whole encryption key lifecycle that is (or should be) handled by a certified encryption key management solution. Generally, a key storage device only provides storage of the encryption key, and you need to create the key elsewhere. Also, just storing your encryption keys “somewhere” doesn’t work very well for compliance regulations. With an encryption key manager, there is a whole set of management capabilities and a suite of functions that provide dual control, create separation of duties, implement two factor authentication, generate system logs, and perform audit activities, along with managing the key life cycle (including storage). There is a very real need, and very specific guidelines that require you to store and manage your encryption keys away from the data that they protect.

The Encryption Key Life Cycle

Beyond storing the encryption key, a cryptographic key manager manages the entire key life cycle. Some of the most important functions the key management administrator performs are the actual creation and management of the encryption keys. The keys are generated and stored securely and then go through the full cycle to become active, go into use, expire, retire (post-activation), and then be backed up in escrow, and then deleted (the “destruction” phase). Let’s take a closer look at the phases of a key life cycle and what a key management solution should do during these phases:

Key Generation & Pre-Activation:
First, the encryption key is created and stored on the key management server (which can be a hardware security module (HSM), virtual environment (VMware) or a true cloud instance). The key can be created by a sole administrator or through dual control by two administrators. The key manager produces the AES key through the use of a cryptographically secure random bit generator and stores the key, along with all it’s attributes, into the key storage database (which is also encrypted). The attributes stored with the key include its name, activation date, size, instance, the ability for the key to be deleted, as well as its rollover, mirroring, and key access attributes. The key can be activated upon its creation or set to be activated automatically or manually at a later time. The key manager should also be able to create keys of three different sizes: 128, 192, or 256-bit. The encryption key manager should also track current and past instances, or versions, of the encryption key. You can also choose whether or not the key can be deleted, mirrored to a failover unit, and by which users or groups it can be accessed. Your key manager should allow the administrator to change many of the key’s attributes at any time.

Key Activation through Post-Activation:
The key manager should allow an activated key to be retrieved by authorized systems and users for encryption or decryption processes. It should also seamlessly manage current and past instances of the encryption key. For example, if a key is rolled every year and the version is updated, then the key manager should retain previous versions of the key but dispense only the current instance for encryption processes. Previous versions can still be retrieved in order to decrypt data encrypted with such versions of the key. The key manager should use transport layer security (TLS) connections to securely deliver the encryption key to the system and user requesting it, which prevents the key from being compromised. The encryption key manager will also expire the key either through a previously established schedule or manually by an administrator.

Key Expiration & Revocation (Escrow):
An administrator should be able to use the key manager to revoke or deactivate a key so that it is no longer used for encryption requests. In certain cases the key can continue to be used to decrypt data previously encrypted with it, like old backups, but even that can be restricted. A revoked key can, if needed, be reactivated by an administrator, although this would be more an exception to the rule than common practice.

Key Destruction:
If a key is no longer in use or if it has somehow been compromised, an administrator can choose to delete the key entirely from the key storage database of the encryption key manager. The key manager will remove it and all its instances, or just certain instances, completely and make the recovery of that key impossible (other than through a restore from a backup image). This should be available as an option if sensitive data is compromised in its encrypted state. If the key is deleted, the compromised data will be completely secure since it would be impossible to recreate the encryption key for that data.

Crypto Period:
This encryption key life cycle, which is defined by the National Institute of Standards and Technology (NIST), also requires that a crypto period be defined for each key.  A crypto period is the length of time that a key should be used and is determined by a number of factors based on how much data is being protected and how sensitive that data is. While NIST has defined and provided some parameters on how to establish crypto periods (see special publications 800-57 - there are 3 parts) and provided guidance on best practices. Each key management administrator needs to determine how long a particular encryption key should be actively used before it is rotated or retired.

These are a few of the factors that go into establishing the crypto period for a key (which maybe a few days or weeks or longer up to one or two years it really depends on the data that you're trying to protect):

• How is the data being used
• How much data is there
• How sensitive is the data
• How much damage will be done when the data is exposed or the keys are lost

You can see that there is a significant difference between a key storage device and an encryption key management solution. Remember to always look for NIST validated and FIPS 140-2 compliant solutions to meet compliance requirements and follow security best practices!

To learn more about encryption key management download our ebook on Encryption Key Management Simplified.

 

Encryption and key management continue to be perceived as challenges for .NET developers as more compliance regulations and state laws require the physical separation of encryption keys from the data they protect.

In the past, .NET developers might have used the Windows DPAPI to store encryption keys, or might have stored them in a SQL Server database. That approach does not meet the requirements for dual control, separation of duties, and split knowledge required by security best practices and compliance regulations such as PCI DSS, HIPAA/HITECH, GLBA/FFIEC, and others.

Historically, Microsoft .NET developers expected to experience some heartburn with an encryption key manager because:

• Key management vendors were historically not responsive to the needs of a .NET developer and failed to provide interfaces that work naturally in this environment
• Complex DLL implementations required special .NET wrapper code
• Poor integration with the existing .NET encryption APIs
• The absence of quality sample code which made life difficult for the Microsoft  .NET developer or slowed down application development

There have been a lot of changes that now make it easier on Microsoft .NET developers to approach encryption and key management. A key manager solution should:

• Provide a .NET assembly key retrieval library that integrates naturally in all of the Microsoft development languages.
• Provide for key retrieval directly into .NET applications so that developers can use the native .NET encryption libraries.
• By not forcing server-based encryption or the use of special encryption libraries, you decide the best approach to encryption once an encryption key is retrieved to the application (this approach also supports Microsoft’s Managed Code architecture)
• Offer vetted sample code to help speed development! You can install a working .NET GUI application that retrieves encryption keys from the server, and the install includes the Visual Studio project and source code
• Integration of encryption key retrieval routines with the Windows certificate store and native Windows communications facility.
• When a Windows application authenticates, the certificates used for the secure TLS connection are under Windows security and control. The TLS communications is done with native Windows communications APIs. This reduces the chance of loss of certificates and private keys, supports the MMC management of certificates, and integrates with Microsoft’s patch update strategy.

As a developer, you might have applications written in a .NET language that update non-Microsoft databases, or which work with unstructured data. These technical hurdles should not stop you from using an encryption key manager to meet compliance requirements for protecting encryption keys.

• Look for a .NET Assembly and DLL that you can add to your .NET project to retrieve encryption keys from the HSM. A few lines of C# or VB.NET code and you are retrieving the encryption key from the HSM.
• Make sure sample code is provided on the product CD to get you up and running quickly. There should be sample applications with source code that you can use as a starting point in your projects.
• The .NET Assembly should work with any .NET language. It should also work with the Common Language Runtime (CLR) environment, and with Stored Procedures. Make sure you can mix and match your .NET languages, databases, and OS platforms.

The combination of NIST validated encryption and an affordable FIPS 140-2 compliant key management solution with solid support for the Microsoft .NET developer makes our Alliance Key Manager a great option for users who need to meet security best practices and compliance regulations for key management. It is time to change your encryption strategy to incorporate solid encryption and an external key manager, whether that is an HSM, Cloud HSM, or virtual environment.

Download our white paper, Key Management in the Multi-Platform Environment, for more information on securing your encryption keys.

Compliance regulations and security best practices require the encryption of sensitive financial data and the protection of encryption keys with proper key management.  

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. For business owners, database administrators, or developers who need to protect their customers’ sensitive data with encryption; storing the encryption keys within the same database puts that information at risk for a breach.

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.

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 provide a certified key management system (Alliance Key Manager) which provides secure key storage and retrieval options for a variety of Enterprise and open source platforms.  Now when nonpublic personal and financial information is collected or stored in a database it can easily be encrypted and the encryption keys properly managed.

To learn more, download the ebook: Encryption Key Management Simplified

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)

Many compliance regulations and security best practices require the encryption of sensitive data and the protection of encryption keys with proper key management.

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). Anyone who needs to protect sensitive data in their database, needs to know that storing the encryption keys within the same location puts data at risk for a breach.  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 brief 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 (http://www.pcisecuritystandards.org) contains this documentation along with a number of additional resources to assist organizations with their PCI DSS assessments and validations.

* 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.”

The PCI Security Standards Council also issues their Cloud Computing Guidelines (https://www.pcisecuritystandards.org/pdfs/PCI_DSS_v2_Cloud_Guidelines.pdf) 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.

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 properly with encryption and key management. To meet the growing need for NIST validated and FIPS 140-2 compliant solutions, the data security experts at Townsend Security provide a certified key management system (Alliance Key Manager) which provides secure key storage and retrieval options for a variety of Enterprise and open source platforms.  Now sensitive information can easily be encrypted and the encryption keys properly managed. 

For more information on encryption, download the latest eBook, The Encryption Guide: