Townsend Security Data Privacy Blog

Microsoft has announced that the October Windows update will change Windows support for certain RSA key sizes.  Our customers have asked:  How will this affect our use of your encryption key manager? Do we need to worry?

No, you don’t need to worry. Here’s why:

Microsoft operating systems will remove support for RSA keys smaller than 1024-bits. The use of 1024-bit and larger keys will still be supported without change. So, only RSA keys that are SMALLER than 1024 are affected.

Alliance Key Manager, our encryption key management HSM, enforces the use of 2048-bit keys and does not allow they use of keys smaller than 1024 bits. NIST has recommended that applications migrate to larger RSA key sizes for some years, and we built Alliance Key Manager to meet those key size best practices. Today, no application should be using an RSA key that is less than 1024 bits.

Our existing customers will not be affected by this Microsoft change. If you are using Alliance Key Manager for Microsoft SQL Server Transparent Data Encryption (TDE), Microsoft SQL Server Cell Level Encryption, Microsoft SharePoint 2010 with SQL Server TDE, Microsoft Dynamics CRM, or our Microsoft Windows .NET client applications, you will not be affected by this change.

We simply do not allow the use of insecure RSA key sizes.

Download our podcast "Encryption Key Management" to learn more about encryption key management and what auditors are looking for and how to easily manage your encryption keys.

Patrick

If you're struggling to understand encryption key management, trust me, you're not alone. If you are just beginning your research, here is the first step to lead you in the direction of a comprehensive key management plan that meets all data security compliance regulations.

Let’s start with the basics:

1. You must manage your encryption keys separate from your encrypted data.

Storing your encryption keys on the same device as your encrypted data is like taping your house key to the front of your door. It’s just a bad idea! Plain and simple. Whether you’re a DBA, IT Admin, or Auditor, PCI DSS section 3 addresses encryption keys and states that keys should be managed with Dual Control and Separation of Duties. This means the keys must be stored on a separate system designed to manage the keys.

2. Manage your keys using split knowledge, separation of duties, and dual control.

This means using multiple people to manage parts of the keys so that no one person has entire control of the keys. PCI DSS section 3 also speaks directly to this protocol. Without separation of duties and dual control, storing your keys on a separate device isn’t much better than “hiding” your key under the welcome mat.

The other day I spoke with a prospect in the healthcare industry who believed the tools he had in place for key management were sufficient, until he found out they were not.  This prospect was using Software as a Service (SaaS) to manage their encryption keys. While using SaaS is a great replacement for some aspects of our work lives, it will not work for key management if you’re managing your keys on same server as you store your encrypted data.

In the healthcare industry, the HIPAA HITECH act states simply, “… covered entities and business associates should keep encryption keys on a separate device from the data that they encrypt or decrypt”.

There are some people out there still storing their keys on their database server, thinking that they are meeting compliance regulations. What they don’t realize is that they are not PCI DSS compliant and will likely fail a security audit if they are audited. My last word is this: When it comes to regulations like PCI, HIPAA/HITECH, or state privacy laws, you must physically separate encryption keys from the data they protect.

If you want to learn more about key management and PCI compliance, listen to Patrick speak about current best practices and encryption key management in the webinar, “Key Management Best Practices: What New PCI Regulations Say.”

I often speak with organizations that need to employ encryption and external key management for multiple relational databases they are using to store encrypted data.  Often this is a combination of Oracle and Microsoft SQL Server databases.   

Transparent Data Encryption (TDE) is used within both the Microsoft SQL Server and Oracle Database universes to provide encryption services at the tablespace level.  Many companies employ TDE and external encryption key management to meet the concept of "Separation of Duties" as required by PCI DSS and other compliance regulations.  Also, TDE is often easier to implement than column level encryption that may require programming changes to your application layer.  

In Microsoft's SQL Server Enterprise edition 2008/2012 you have access to Extensible Key Management (EKM).  When EKM is enabled, SQL Server users can use encryption keys stored on external key managers, as opposed to accessing local key stores, which doesn't line up with compliance requirements.  Also, another benefit of using EKM is that you can easily take advantage of TDE as your database encryption approach.  

If you're running versions of Microsoft SQL server that don’t support EKM, don't worry.  You can still take advantage of the added features and security of using an external key manager with our encryption key management HSM, Alliance Key Manager (AKM).  AKM fully supports the entire Microsoft SQL Server product line.  You’ll just have make some programming changes to your application code to perform the necessary API calls to the key manager and you'll be set up to do key retrieval.   To help you with the process, we provide sample code and the .Net key retrieval assemblies to add to your project.  Additionally, we have C# and VBNET sample code that shows how to retrieve a key from the key server.

Much like Microsoft SQL Server, in the land of Oracle you need to be running Oracle Enterprise Edition with the Advanced Security option.  This can often be a pricey upgrade and I find that quite a few organizations would rather do column level encryption due to this fact.  AKM fully supports the path to column level encryption within the Oracle 10g and 11g environments.  Again your approach will include making coding changes to your application layer to perform key retrieval from AKM.  To help you with this on the Oracle front we provide some PL/SQL sample code for you to work from.

For more information on the importance of encryption key management, download our white paper "Key Management in the Multi-Platform Envrionment" and learn how to overcome the challenges of deploying encryption key management in business applications.

Townsend Security recently hosted a webinar titled “Protecting PHI and Managing Risk – HIPAA/HITECH Compliance” that focused on how members of the healthcare industry can achieve a breach notification safe harbor if they are properly encrypting their Protected Health Information (PHI).  PHI can be stored in many different places – from Electronic Medical Records (EMR) in a database to healthcare claims stored on a laptop by a health insurance company.  With fines for data breaches averaging into the millions of dollars, it is more important than ever to protect your PHI.  We received some great questions during the webinar that we would like to share with our blog readers.

How is encryption used to protect PHI?

Encryption solutions are used in a variety of places.  Basically those of us that are encryption vendors tend to think of encryption in two ways.  The first is encryption of data in motion.  For example, if you open a web browser and go to a website that uses HTTPS and the “lock” comes on, you are encrypting your data as it is “in motion.”   Typically, SSL or TLS encryption is being used.  These technologies protect any information that flows between your web browser and that endpoint – making it safe to send PHI like a social security number or medical records online.

Second, we think about securing data at rest.  This typically means data that is in a database. When you go to the doctor and he interviews you and puts his results into the computer, that data is landing in a database and it needs to be protected.  AES encryption and proper key management are necessary to protect this data.

Our database software has encryption options.  Why would we need a third party software?

Lets start with an example.  Encryption is part of the package when you purchase Microsoft SQL Server 2008 Enterprise Edition or Oracle 11g with Advanced Security.  So you might say to yourself, “Why do I need something else if Microsoft offers encryption?”  In these cases, you are sitting in a good place for the cryptographic portion, but still need encryption key management to meet any compliance regulation.

To line up with industry standards for encryption best practices, you need to have dual control and separation of duties.  To do this you need to physically separate the encryption keys from where the protected data lives (Your SQL Server or Oracle database).  It is great when a vendor provides encryption as part of their database software, but it only gets you halfway to where you need to be.  An encryption key management Hardware Security Module (HSM) will bring you in line with best practices for dual control and separation of duties, allow you to pass your audit, and achieve safe harbor status in the event of a breach.

View our webcast “Protecting PHI and Managing Risk – HIPAA/HITECH Compliance” to learn how your organization can manage their risk of a data breach and achieve breach notification safe harbor status.

So you've decided to purchase an encryption key management HSM to help you pass a QSA audit and meet PCI DSS compliance.  Unfortunately just showing the auditor your paid receipt and key manager is not enough to satisfy requirements.  You have to actually be using them in a production environment.  Fortunately this is a fairly simple process to get started with Alliance Key Manager, our encryption key management HSM.  

Once the appliances are assigned IP addresses and reachable on your network, there are three fundamental tasks that you should complete prior to going into production.

First you'll want to setup and configure mirroring to your H/A failover server.  This is as easy as toggling on outgoing mirroring in the AKM.conf file of your primary server.  Next you'll want to have one of your Security Admins log into the Java based AKM Admin console for the production server and point it towards the failover server that will be receiving all the mirrored commands.  The final step to complete mirroring requires logging into the failover server and defining the incoming mirror details in the AKM.conf file for that appliance.  You'll also want to be aware of any firewalls in your network that could inhibit traffic and add exceptions accordingly.

The second part to deploying an encryption key management appliance involves defining your log collection of system logs for audit purposes and meeting section 10 of PCI DSS.  Alliance Key Manager supports transferring system logs via syslog-ng to a log collection server that is running a SIEM solution.  This is configured in the standard syslog manner by defining a log source, destination, and path.

The final and surprisingly perhaps most overlooked step to appliance setup is the creation of system backups.  Within Alliance Key Manager you will create two different types of backups from the outset.  The first will be a backup of your key encryption keys and configuration settings.  This backup needs to really only be run once during the setup of the device as there won't normally be changes to these settings going forward.  The second backup will be of the primary key management database, which will contain all your data encryption keys used by key retrieval clients.

During the backup process you'll be asked where you want these backups stored and define a backup destination.  Your choices include a local directory on the key server itself or sending it to an FTP server using SSL or SSH.  We  recommend sending your backups to a secure FTP server off the appliance in the event of a hardware failure and you can't reach the backup directory you'll still have access to these crucial images elsewhere for restoring purposes.

To make life easier on your network team we provide a scheduling facility that allows you to automatically create and transmit these backups at any specified time of your choosing.

Tackling these three tasks while setting up your Alliance Key Manager HSM will help you well on your way to passing that QSA audit.  The deployment team at Townsend Security can help you breeze through these steps as well as provide you documentation that covers these items in further detail.

For more information on the importance of encryption key management, download our white paper "Key Management in the Multi-Platform Envrionment" and learn how to overcome the challenges of deploying encryption key management in business applications.

Over the last few years we’ve seen attempts by the US Congress to pass new federal privacy notification laws. There are good reasons to do this as the current mix of state privacy notification laws are inconsistent and it is hard for organizations of any size to know if they are in compliance with the more than 45 state-level regulations. Businesses would appreciate some simplification and clarity, and one federal law would be preferable.

Both the House of Representatives and the Senate have seen proposed legislation pass out of committee. But no consolidated legislation has passed Congress and been signed into law.

The latest attempt is proposed Senate Bill 3333.

This legislation is similar to many state laws in how it defines Personally Identifiable Information (PII), how it proposes that breach notification take place, and how it levies fines for the loss of sensitive information. Like HIPAA legislation, it charters the Federal Trade Commission with enforcement responsibility.

Unfortunately, it won’t have much of an impact on reducing data breaches and identity theft.

First, the definition of Personal Information is too narrow in today’s consumer and Internet world. To qualify as a breach, the proposed act requires that the data loss include a first and last name combined with a social security number, or financial account information. The breach that happened to LinkedIn would not even qualify under this definition. And yet it was a serious security breach. The bad guys are really good at aggregating data like this, so the new law wouldn’t have helped. And it will give companies an excuse for hiding this type of loss.

When it comes to protecting sensitive data it leaves a gaping hole. Here is how the proposed legislation describes the approach to protecting sensitive data:

Personal information does not include information that is encrypted, redacted, or secured by any other method or technology that renders the data elements unusable.

Without a requirement to use encryption, AND clear guidance on protecting the keys used for encryption, we will continue to see significant data breaches taking place on a daily basis. Without this clear guidance, we will actually take a step backwards. In today’s world, security auditors and professionals already understand the need for good encryption key management systems and practices. They know that encryption keys stored with the sensitive data is equivalent to taping your house key to the front door when you leave in the morning. PCI data security auditors, SOX auditors, and almost all other security professionals now require that encryption keys be protected by HSMs designed for that purpose. But we don’t see mention of this in the legislation.

Rather than provide clarity around protecting sensitive data, this legislation will continue the confusion around how personal information should be protected, and even what constitutes a data breach. It will not provide the clarity and guidance that businesses hope for. It won’t stem the loss of sensitive information, and it won’t stop the terrible financial impacts of identity theft.

Let’s hope this bill gets strengthened before the final version is passed.

Patrick

For more information on the importance of encryption key management, download our white paper "Key Management in the Multi-Platform Envrionment" and learn how to overcome the challenges of deploying encryption key management in business applications.

The recent email and password breaches at LinkedIn and Yahoo have exposed how severe the loss of this information can be.  A large majority of people use the same email account and the same password to authenticate to multiple web sites and services. For this reason, the breach of any one site compromises the security of the others.  And the fact that Facebook, Google, and other sites make it easy to share authentication makes the impact of a loss that much greater.

Because of these losses, I’ve been getting a lot of questions from CIOs and database administrators about protecting email addresses and email passwords in their databases. While the techniques used to protect information in databases are different than the techniques used to protect login credentials, you should definitely put this type of information under data protection controls.

Here are some steps you can take to protect this important personally identifiable information in your databases:

• Be sure to encrypt BOTH the email address and the password.  I often find that companies only encrypt the password. It turns out that end users frequently use weak passwords and they are easy to guess. Even if the password is protected using strong encryption, the password can often be discovered through a dictionary attack. So encrypt BOTH the email address and the password.
• Don’t decrypt an email address and password if you don’t need to. I’ve noticed that many applications automatically decrypt a password when a row is read from a database even if it is not needed. This just creates an unnecessary exposure point.
• Use strong, industry standard encryption methods to protect the email address and password. I recommend using 256-bit AES encryption which is the most widely accepted standard for protecting data at rest.  Never use home grown or non-standard encryption.
• Use good key management practices. Store the encryption keys on a key server HSM designed for this purpose. Storing the encryption key on the same server is like taping your house key to your front door when you leave in the morning.
• Store passwords on a key server HSM and not in the local database. Many key server HSMs provide the option to import raw information like passwords to the key server, and then retrieve them only when needed.
• Most important! Don’t be discouraged about the effort required to implement good encryption and key management. I’ve seen security efforts defeated before they begin because companies think that the effort will be too complex and too expensive. It’s probably easier than you might think.

Database vendors like Microsoft, IBM, Oracle, and others have done a lot over the last few years to make this effort easier. And security vendors (we are one) have also made progress in making encryption and key management faster and more affordable. Encryption is widely viewed as hard to do and expensive. That’s no longer true - times have changed!  Download a free 30-day evaluation of our NIST-certified AES encryption and see how easy it is to encrypt usernames, passwords, and other PII on your systems.

Patrick

In part one of Meeting PCI-DSS Requirements for Encryption Key Management I discussed Separation of Duties and Dual Control, two critical components necessary towards meeting Section 3 of PCI DSS for encryption key management compliance.  Equally important to meeting section 3 are the notions of Split Knowledge, Audit Trail Logging and Strong Key Usage and Protection.

Section 3.6.1 of PCI DSS v2.0 states that your encryption solution must generate strong keys as defined by PCI DSS and PA-DSS using "strong cryptography."  On our Alliance Key Manager (AKM) all data encryption keys, key encryption keys, and authentication keys are generated using a NIST approved and certified cryptographically secure random number generator.  This meets NIST requirements for strong encryption key creation and establishment.  Furthermore in regards to Key Encryption Keys and Authentication Keys that protect your data encryption key database, the former keys are protected by a 2048-bit RSA key.  Since AKM is FIPS 140-2 certified and meets NIST requirements, you're covered on how keys are stored in a protected format, detection of key corruption, and the separation of data encryption keys from your key encryption keys.

Split Knowledge can also play a crucial role in protecting your data encryption keys.  Parts of the security standard state that you shouldn’t export a key in the clear from the AKM database and that the key needs to be protected.  For this to occur, you'd first have to have your Admin latch up to the key server utilizing a secure TLS connection with the proper credentials and authenticate to the server.  Once the connection is established, the admin is free to export or import symmetric keys, however upon export they will be required to protect the symmetric key with a RSA key. No manual establishment of keys in the clear is supported. By default this is out of the box functionality; we ensure this requirement by setting a configuration option for PCI-DSS mode.

Finally, there is the important item of collecting your system logs and transmitting them over your network to a waiting log collection server.  This waiting log server would ideally be running a SIEM product that monitors and analyzes log messages looking for malicious activity or critical errors. Specifically, AKM writes logs to four different log files; audit, error, backup, and trace logging, when enabled.  The key manager comes with Syslog-ng built in and ready to be configured.  You simply select your sources and define your destination of the collection server to begin transmission of your log files.  You can configure your SIEM product to send out alerts when certain events or errors occur that you want to be on the lookout for.

Want to learn more?  You can view a pre-recorded webinar titled "Encryption Key Management Simplified" and learn how encryption key management can be easy, why encryption key management is important, and what the barriers are to good encryption key management.

There are are a few major components of PCI-DSS that need to be addressed when implementing an external key manager into your data encryption equation.  Separation of duties for starters, simply states that those who have access to the sensitive data, such as card holder details or credit card numbers cannot also have access to the encryption keys that protect them.  Conversely, the same can be said for the individuals that are responsible for managing data encryption keys -- they should not have access to the sensitive data for which the keys they are creating are used to protect.  Quite simply, separation of duties is the concept of dividing critical data protection processes between different individuals. This helps reduce the opportunity and likelihood of fraud when processing sensitive data.

I often talk with companies who've until recently considered encryption key management as an afterthought to their security infrastructure.  Often times they would store encryption keys on USB sticks or locally, alongside the encrypted data.  This approach allows individuals within the organization access to both the keys and data, directly conflicting separation of duties.  Utilizing an external encryption key manager to house your encryption keys, as well as implementing a policy where your security team are the only ones managing those keys and your DBA's and users are the only individuals accessing the data, will help move you in the direction of PCI compliance.

But of course there are other pieces to PCI that one should be aware of when it comes to proper encryption key management.  While separation of duties is good practice, there is an additional level of security that can be implemented on the encryption key management side called dual control.  Dual control is a process that requires the involvement of two or more individuals to complete a specified task, such as creating a key, changing its attributes, revoking status, or destroying an encryption from use forever.  Think of dual control as the act of requiring two individuals with two different keys to unlock the launch codes for a nuclear missile.  You certainly wouldn’t want all that responsibility resting on the shoulders of just one person with no oversight in place.  The same can be said for the management of your encryption keys.

To implement dual control on Alliance Key Manager (AKM), our encryption key management HSM, you'd first active it in the AKM configuration file of the hardware appliance.  Then the two Security Admins responsible for key management would install our Java based admin console into their work environments and configure them to communicate with the key manager over a secure TLS connection.  Once this is established, the first Security Admin would authenticate to the key server and set an 'Authorized Administrator' time period.  This allows the the first Admin to specify a window of time (in minutes) where the other Admin can log onto the key manager and perform their duties.  Taking this approach to key creation and management adds that additional layer of security to your encryption key environment.

In Part II of 'Meeting PCI-DSS Requirements for Key Management'  I will discuss the importance of capturing your audit logs and transporting them to a collection server off the key manager device as well as dig into the concept of split knowledge and how AKM meets that requirement. Until then, download our white paper on encryption key management requirements for PCI.

Did you know that any organization that handles sensitive information (PHI, PII, etc) is can be audited in the event of a data breach? You may be asking yourself, what does a security auditor look for? I recently sat down with Patrick Townsend, President & CEO of Townsend Security, to discuss how organizations can set themselves up for success when they get audited.

Patrick Townsend:

“First of all, in my experience, companies will have different experiences with different auditors. Some auditors will be more knowledgeable about certifications and encryption best practices than others. However, there are three critical components of data security that all auditors will look for:

1. NIST-Certificated Encryption and FIPS 140-2 Certified Key Management
One problem that we see companies face is that they are using encryption, but have implemented non-standard technology, which almost never withstands proper scrutiny. At Townsend Security, we stand behind our standards based products because they have gone through rigorous testing by NIST chartered testing labs.  Our AES encryption is NIST certified and our encryption key manager is FIPS 140-2 certified — which means they have been independently tested and certified to meet best practices.

2. Security Best Practices
Use best practices of dual control, separation of duties, and split knowledge. These three practices are parts of NIST encryption key management best practices and are critical to your security posture. As a company, you must insist on employing these practices in order to meet the highest standards of data security.

3. Policy Based Security
Invest in policy-based security. This type of security will be developed to deploy data protection with all data security regulations in mind—both federal and state. Every company falls under state and proposed federal privacy laws, and therefore, companies handling sensitive data will do better to use certified data security solutions built by companies who can tailor their products to meet an organization’s individual needs.

Here at Townsend Security we are always moving forward with you, our customers, to help meet a variety of compliance regulations with the most standard, up-to-date, and industry-certified security solutions. We want to help our customers always pass their security audits with flying colors!

Download a free 30-day evaluation of NIST-certified Alliance AES Encryption to start meeting compliance regulations (PCI DSS, HIPAA, etc.).  Additionally, learn how to easily store encryption keys separately from your encrypted data with a secure encryption key management HSM by visiting our Encryption Key Management Simplified Resources page.