Townsend Security Data Privacy Blog

While FIELDPROC was introduced nearly two years ago with IBM i V7R1, it is becoming new to administrators who are finally upgrading to the latest IBM i OS.  Lucky for you newbies, we have plenty of experience with this release and can share a wealth of knowledge for your encryption project.  FIELDPROC allows us to bring you automatic encryption – encryption with no application changes!  We recently hosted a webinar titled “Automatic Encryption on the IBM i” and received some great questions.  Patrick Townsend, Founder & CTO, recently took some time to answer a few questions that we received during the webinar.  If you have any further questions on FIELDPROC and how your organization can implement automatic encryption with no application changes, send them our way.

When you back up encrypted data to tape, does it back it up un-encrypted?

No.  Data that is encrypted by FIELDPROC, when you do a backup, is going to be encrypted on the backup tape.  If you a put a file under FIELDPROC control and you back it up, you can then just dump that tape and see that the data is encrypted on the tape.  Backup operations do not trigger FIELDPROC decryption and you can securely back up a file on to tape for it to be protected.  That is a part of the built-in capabilities within FIELDPROC.  However, if you copy a file with the “copy” command, the database WILL trigger FIELDPROC and decrypt that data.

Can masking be done by group profile or only by a specific user?

Good question.  Yes, you can use group profiles for user access controls and masking.  We understand that a lot of our customers have a large number of users and have leveraged using group profiles.  We fully support group profiles around both access controls and masking. It is important to note that we do not use native object authority for our user access controls and masking. Instead we use a white-list approach that allows you to control and monitor QSECOFR and any user with All Object (*ALLOBJ) authority.

Are there any performance impacts of using encrypted data as indexes, as far as reads or chains, or other I/O functions? 

IBM has done a great job of implementing FIELDPROC in terms of how it gets called and when it gets called.  There is no particular performance impact for reads, as opposed to writes.  We have done tests with encryption and decryption and they are both very efficient and very effective.  There is a tiny measureable difference between encryption and decryption, and that has to do with key scheduling, but believe me, it is extremely insignificant.  I think you will find about equivalent performance with both encryption and decryption.

View our webinar “Automatic Encryption on the IBM i” for more information about FIELDPROC and how your organization can easily meet compliance regulations that require encryption – with no application changes!

Last week we hosted a webinar titled “Automatic Encryption on the IBM i” and got some great questions!  Now that IBM i 7.1 (V7R1) has been out for almost two years, we are starting to see more and more companies upgrade their IBM i’s to this latest release of the OS.  As a result, questions and concerns about FIELDPROC have been rolling in.  This feature allows organizations to automatically encrypt their data with no application changes, making it easier than ever to meet compliance regulations with encryption (PCI DSS, HIPAA/HITECH, etc.). 

Previously, encryption was a big project that often brought fear into the eyes of the IBM i administrator.  Not only do we have a FIELDPROC encryption solution that avoids the need for development, but we feel it is the best available encryption for your organization.  Performance is a key differentiator among encryption providers, and we challenge you to find a faster solution.

Additionally, we have been getting questions on how FIELDPROC affects Business Intelligence (BI) tools.  Patrick Townsend, Founder and CTO, has taken a few minutes to address some of these questions from our recent webinar. 

I have heard bad things about FIELDPROC performance.  You seem to think it performs ok.  Can you talk about that?

I think some of the less than stellar things you have heard about FIELDPROC performance comes from people who have implemented poor FIELDPROC encryption solutions.  Different encryption libraries can have very different performance results.  We have tested our optimized encryption libraries, and when compared to others, have found a 100 times difference in the speed of our libraries – even when you are doing something like 256-bit AES encryption.  I think some people have had a bad experience with encryption and FIELDPROC, and I am sure you will have a different experience with our solution. 

We make it really easy to evaluate AES/400, our FIELDPROC encryption solution.  If you have had a bad experience around FIELDPROC, you should take a look at our solution.  I think we will convince you that we have the best FIELDPROC encryption solution available.

How does FIELDPROC encryption affect OLAP reporting tools like ShowCase and Cognos?

The implementation of FIELDPROC is going to work as long as you have a standard DB2/400 database on the IBM i platform and you are running V7R1.  If you have a Business Intelligence tool that runs on top of DB2/400, then FIELDPROC will work for you.  FIELDPROC is a facility that is implemented at the database level and not on the application level.  Personally, I think that if you have sensitive data in any Business Intelligence database, the user controls and masking controls that we have implemented in our FIELDPROC encryption solution should look very good to you because it gives you the ability to maintain the power of those Business Intelligence tools without accidentally exposing sensitive data and creating additional risk.  FIELDPROC, by itself, will not do masking or user controls for you, but our implementation of FIELDPROC in our Alliance AES/400 product will do that for you and will help you protect that data.

View our webinar “Automatic Encryption on the IBM i” for more information about FIELDPROC and how your organization can easily meet compliance regulations that require encryption – with no application changes!

Before you deploy an encryption solution, there is one often-overlooked consideration to be aware of – performance.  A slow encryption solution can change a “job-well-done” into “we need to get this solution off our servers and go buy from Townsend Security STAT!”  This actually happened to a retail customer of ours.  Their initial encryption implementation was so slow that it prevented them from being able to use it in production.  True story.

So are there any performance tests you can do before you decide on a FIELDPROC encryption solution?  You bet.

Before you begin, you need to decide how many fields in a table you have to encrypt.  If you need to meet the PCI DSS compliance regulation, you might only need to encrypt one field (credit card number).  If you are protecting PHI (Protected Health Information) in the medical segment or PII (Personally Identifiable Information) for privacy notification laws, then you may have several fields in a table that need to be protected. Every column that you need encrypted is going to add to the overall performance burden.

A good first performance test is with just with one column.  We recommend creating a table with one million records, implement FIELDPROC, and then seeing how long it takes to encrypt the data in that table.  These results will give you an idea how your system will perform when you are only encrypting one field (a credit card number to meet PCI DSS, for example).

Next, if you need to encrypt several fields (ZIP code, phone number, credit card number, etc.), do a test on a table with that many fields.  You will learn a lot very quickly about the performance of FIELDPROC and your encryption solution.  If you do these tests, and we think it is absolutely important that organizations try this test before they deploy a FIELDPROC encryption solution, you will learn a lot about how the encryption will impact your production environment. 

Summary

Look at what you need to protect, try and create as close to a real-world test as you can, and see how your performance results are.  It is very simple to do.  We can even provide you with a sample database and table with a million records so that you can create and test on your machine.

Listen to our podcast “IBM i FIELDPROC Performance: Speed Matters” for more information on encryption performance with FIELDPROC on IBM i 7.1

In our final installment of questions from “Encryption Key Management with Microsoft SQL Server 2008” we tackle the topics of encryption key management in High Availability (HA) and disaster recover scenarios.  If you missed the first two blogs in the series, you can always go back and read about “The Performance Impacts of TDE on Microsoft SQL Server” and “How often do I need to rotate encryption keys on my SQL Server?”  If you still have any questions about encryption or encryption key management on your Microsoft SQL Server, feel free to send them our way.  It is always a pleasure to hear from members of the data privacy community.  Here is the last question in this series:

Can you speak to how encryption key management works in High Availability (HA) and disaster recovery scenarios?

An encryption key management solution becomes a part of your critical infrastructure if you are properly protecting keys.  If your key manager goes down, your applications stop functioning until you have key management back up.  We really address those concerns in a number of ways.  One way is that our key manager is built for redundancy.  We know it is hardware, and if it is hardware it can fail, so we implement a hardware platform that is resilient and has a lot of redundancy built in.  The first layer of keeping an encryption key manager up and running consistently is to have a good hardware platform.

Secondly, we build real-time mirroring of keys and policy around keys directly into the product.  You can actually deploy a high-availability failover key server with all key activity and access controls mirrored in real-time to a fail-over key server.  If you use SQL Server, you can define right in our software one or more fail-over servers.  For example, in SQL Server, through the configuration panels you can define multiple key servers for fail-over.  If you have a failed server, a hardware problem, or network outage, you can actually define fail-over servers and that will take place in real time.

Furthermore, there is a lot of resilience in the EKM provider software that we install on the Windows server so that if there is a software failure, there are some self-healing mechanisms there too.  If our module were to be killed off by the security administrator, it will get re-started automatically.  So there are a lot of redundancy and self-healing components built in to both the software and configuration components on the key server.

We have done a lot to help customers deal with the concern about resilience of a key manager because it is critical infrastructure, and we fully support that through real-time mirroring.  It is not an operating system feature.  The key server itself has implemented this mirroring capability.  It is itself self-healing.  So if two key servers are mirroring to each other and the network goes down, they will queue up those mirroring transactions, and when the network comes back, it will re-commit those changes.  Alliance Key Manager is a robust facility for making sure you have good backups of your encryption keys.

This concludes our series of questions from the recent webinar “Encryption Key Management with Microsoft SQL Server 2008.”  We encourage you to view the webcast and learn even more about how easily and affordably you can begin meeting data privacy compliance requirements with encryption and encryption key management.

Now that IBM i 7.1 has been available for over a year, more and more companies are finally adopting the latest OS.  It is a great release and we encourage your organization to upgrade.  As a data privacy company, the main reason we are excited about this release is because it finally allowed us to bring you automatic encryption – encryption with no application changes!  The days of modifying your applications to meet compliance regulations (PCI DSS, HIPAA/HITECH, GLBA/FFIEC, etc.) are over.  If this sounds to good to be true, read on.

With the introduction of the FIELDPROC exit point, IBM i administrators now have something similar to what Microsoft SQL and Oracle users have had for some time.  FIELDPROC allows you to implement encryption without changing your applications.  As we attend industry events, one of the top questions we get asked is “Great!  What are the performance impacts?”  This is where the answer is “Depends.”

Any time you are doing encryption in a database environment, there are considerations about performance.  With FIELDPROC, you really have to pay attention to this question because it is an automatic facility and every time a row or record in the database is accessed, the FIELDPROC program is going to get called to do encryption or decryption.  For example, if you have 10 million records in a table and you read that entire table, you are going to make 10 million calls to a FIELDPROC program to do decryption – even if you aren’t using that particular field.  We have heard horror stories from people who have implemented poor FIELDPROC solutions and were not aware about how important investing in a proven encryption solution is.  We are very happy with the performance of our FIELDPROC solution. 

Our FIELDPROC solution uses our own NIST-certified AES encryption libraries (which is very important in many compliance requirements).  They are very highly-optimized, very fast, and have clocked in at under one second for 1 million encryptions (for more details on these tests, listen to our podcast on the topic). And as you know, the encryption library is only half of the encryption process.  The other part is encryption key management.  We have an encryption key management appliance that is FIPS 140-2 certified (again, important for meeting compliance regulations) and implements best practices for encryption key management.  Aside from your server, these components are the two things that effect encryption performance of FIELDPROC the most.

Listen to our podcast “IBM i FIELDPROC Performance: Speed Matters” for more information on encryption performance with FIELDPROC on IBM i 7.1

Last week we began a series of blogs with questions from our recent webinar titled “Encryption Key Management with Microsoft SQL Server 2008”.  If you missed part one, you can view it now.  We talked about the performance impacts of TDE (Transparent Data Encryption) on Microsoft SQL Server 2008.  This time we will talk about how often you need to rotate your encryption keys on your SQL Server and whether your database gets locked during Cell Level or Column Level encryption during the re-encryption process.  Additionally, we will touch on how we can help users that have both Microsoft SQL and Oracle environments.  Without further delay, here are the questions:

How often do keys need to be changed?  During Cell Level or Column Level encryption, will the database be locked during the re-encryption process? 

With Cell Level encryption you can roll keys without bringing down your database.  When you establish a symmetric key in Alliance Key Manager, our encryption key management appliance, you can establish how frequently you want that key to be rolled over, rotated, or changed (which all mean generate a new key) for use by the database.  Alliance Key Manager implements support for both automated and manual key rollover, and if you are using Cell Level encryption in Microsoft SQL Server, you can take advantage of that.  The broader question about how often you should change keys in your database is a really interesting one.  There is no simple answer to that.  If you are familiar with PCI DSS you know that particular question got a little more complicated in version 2.0.  Basically, you have to establish a crypto-period for your keys.  I think NIST would say two years is probably the maximum for the usage period of a key.  Five years on the outside for a key to be used, even for the decryption of previously protected data.  The bottom line is you have to establish a crypto-period for your keys and then implement that as policy.  We support that process by letting you define how frequently keys should be changed and then managing that process for you automatically.

With TDE, the answer is a little bit different.  TDE requires some manual steps to roll keys, but we fully support multiple keys and rolling keys with our encryption key management appliance. 

Does your Alliance Key Manager Enterprise Edition serve keys to Oracle databases as well?

Yes.  We provide encryption keys across a wide set of databases, applications, and servers.  We have customers today who are protecting Oracle databases using our Alliance Key Manager to store encryption keys.  We provide sample code that shows how to do that - same thing with MySQL, DB2 from IBM, and almost every standard database that you might run into.  We also make it easy for customers who are using a variety of development languages to implement encryption. 

If you are using SQL Server EKM, you really get a big win because it doesn’t take any programming at all to implement TDE.  So that is the “easy button” in terms of encryption.  Additionally, if you have written applications in Java that use SQL Server, Oracle, or MySQL, we provide Java examples - full applications in fact - on how to use them.  If you programmed in C#,  VBNET, Perl, Python, or PHP, we have sample code that really helps customers get up and running very quickly with our key management solution.

Stay tuned for our next post on encryption key management in High Availability (HA) and disaster recovery scenarios.  In the meantime, you can view a recording of “Encryption Key Management with Microsoft SQL Server 2008”

Townsend Security hosts a monthly webinar on a wide variety of topics ranging from encryption and key management best practices to what’s new with compliance regulations such as PCI DSS.  If you haven’t had a chance to attend any of our webinars yet, sign up for our newsletter and we’ll make sure you know what is coming up next.

During our recent packed webinar, “Encryption Key Management with Microsoft SQL Server” we were asked some great questions from the audience and would like to share them with you on our blog.  Upcoming questions include “How often do I need to rotate encryption keys on my SQL Server?” and “How does encryption key management work in High Availability (HA) and disaster recovery scenarios?”

Here is part one in our series of questions from this webinar.  As always, if you still have any questions, send them our way and we will promptly get back to you.

What are the performance impacts of TDE encryption on Microsoft SQL Server?

Encryption really has a reputation for being CPU intensive.  There is good news on this front for Microsoft customers because I think the people in the SQL Server group did a really great job at performance tuning data encryption within the SQL Server environment.  If you look at what Microsoft says about turning on TDE (Transparent Data Encryption), they say you will pay a 2-4% performance penalty when encryption is enabled.  That is actually very excellent performance.  In our experience, it is actually closer to 2%.  More complex environments may get a little higher than that.

Microsoft will tell you that there is a little more performance penalty around Cell Level or Column Level encryption.  I think that is probably true too, but still I think they have done a great job of making a good solution that performs quite well.

Stay tuned for our next post on “How often do I need to rotate encryption keys on my SQL Server?” and “During Cell Level or Column Level encryption, will the database be locked during the re-encryption process?”  In the meantime, view a recording of “Encryption Key Management with Microsoft SQL Server”.

As we wrap up our blog series on encryption and key management with Microsoft SQL Server 2008 continues, Patrick Townsend, Founder and CTO, finishes the conversation by speaking on special requirements for an encryption key management HSM and how Townsend Security can help organizations running SQL Server 2008 with their encryption project.  If you are jumping in to the series right now, you can read part one and part two for the earlier parts of our conversation.  Here is the final part of our discussion:

Download Podcast Now

Are there any special requirements for an HSM?

HSMs are very specialized devices.  It takes a certain type of development approach to create systems that protect encryption keys.  There are well-defined processes by which encryption keys should be created, managed, stored, and protected by other encryption keys.  All of that is a very special security practice by vendors who create HSM solutions.  It is a very highly specialized practice.  Even the way you build and program for an HSM is quite different than you would build or develop a standard business application.  So, first off, there are really best practices on how HSMs get developed. 

Secondly, there are standards for HSM devices.  The National Institute of Standards and Technology, or NIST, produces a FIPS 140-2 certification and specification for cryptographic modules.  Vendors of HSM solutions can have their products certified to the FIPS 140-2 standard.  Any serious vendor will undergo FIPS 140-2 certification.  It is a requirement by the US government and any federal agency that is protecting encryption keys must use a FIPS 140-2 certified solution.  In private industry, it is a well-recognized standard.  I can tell you from personal experience that it is a very tough process.  There is a lot of scrutiny over how you have implemented key management, and as a result, only the best vendors attain a FIPS 140-2 certification.  We are proud to have achieved this status with our encryption key management appliance.

How does Townsend Security help organizations running SQL Server 2008 with their encryption project?

First, we do have an encryption key management appliance called Alliance Key Manager.  It is designed to be the Fort Knox for encryption keys.  It helps our customers meet encryption best practices with an HSM solution.  It carries the FIPS 140-2 certification that customers demand.

Secondly, it connects very easily to Microsoft SQL Server 2008 – including the upcoming SQL Server 2012 which was code named Denali.  It is easy to deploy and SQL Server customers will find it very straightforward to install.  It understands EKM configurations and automatically mirrors them and backs them up in a High-Availability (HA) environment.  All of that is done through very straight-forward GUI applications. 

Additionally, our encryption key management solution provably meets industry standards, is easy to deploy, and cost-effective.  We are really trying to help the Microsoft mid-market customer who may have one or two SQL Servers get into an HSM solution that really will fit their budget.  Our cost-effectiveness is one of the things we are bringing to the market that is brand new.  We look at key management HSMs as something that every organization should be able to deploy to protect their data. 

Finally, we do a lot to automate the entire key management process.  Keys can be generated and then automatically rolled to meet compliance regulations.  These components are core to our strategy of making encryption key management and the deployment of HSMs with the Microsoft EKM environment a straightforward and reasonable thing to do.  It really will help a whole range of customers meet encryption key management best practices quickly and with an affordable solution.

To listen to our conversation in its entirety, download our podcast “Encryption Key Management with Microsoft SQL Server 2008” and learn how easy it is for your organization to start encrypting sensitive data on your SQL Server.

As our blog series on encryption and key management with Microsoft SQL Server 2008 continues, Patrick Townsend, Founder and CTO, resumes the conversation by speaking on who would need to use Extensible Key Management (EKM) and what part a Hardware Security Module (HSM) plays in this environment.  If you are jumping in to the series right now, can read “Encryption and Key Management on Microsoft SQL Server 2008- Part 1” by clicking on the link.  Here is part two of our conversation:

Who would need to use Extensible Key Management (EKM)? 

Download Podcast Now

Almost anyone who stores sensitive data in a SQL Server database should be considering encrypting that data to prevent its loss.  We are all familiar with the data breaches.  Some of them have been very well publicized – Sony and Citigroup, etc.  Losses happen to large and small companies alike, and it is quite damaging financially and to the reputation of a company to have a loss.  Anyone who is storing sensitive data in a database should be considering using EKM to protect that data.  If you are in a retail environment and are taking credit cards, you fall under PCI DSS rules and should be encrypting that database.  If you are in the medical segment you fall under HIPAA and HITECH Act rules.  Patient information that is stored on your SQL Server should be encrypted.  Finally, anybody who falls under a state privacy law – which is almost everyone – and are storing Personally Identifiable Information or PII, such as social security numbers, drivers license numbers, military IDs, etc. could benefit from using TDE and EKM.

So, any company who falls under compliance regulations and needs to protect sensitive information from loss and wants to minimize their risk should be using Encryption Key Management (EKM).  Microsoft, through their EKM architecture, makes it really easy to accomplish, it is relatively inexpensive and is very cheap insurance to help protect your data against loss.

What part does a Hardware Security Module (HSM) play in this environment?

HSMs are the Fort Knox for encryption keys.  Good security practice across all regulations requires that you take extra steps to protect your encryption keys.  The real secret that you are trying to protect is the key that you have used to encrypt that data.  Protecting encryption keys is the biggest challenge and most important part of an encryption strategy, and that is exactly what an HSM does.  HSMs create keys, protect them from loss, manage them through their lifecycle, and deliver them to applications that need them, such as EKM in the SQL Server environment.  HSMs are a very crucial part of your encryption strategy and that is why Microsoft and security professionals recommend using an HSM.

In the compliance arena, if you are undergoing PCI DSS assessment, there is not an explicit requirement for an HSM, but there are explicit requirements for “Separation of Duties” and “Dual Control” as applied encryption key management.  When you begin to look at requirements to achieve “Dual Control” and “Separation of Duties” you quickly come to the realization that you HAVE to separate the encryption keys into a separate environment and that is exactly what our encryption key management appliance does.  So to effectively meet security and compliance requirements you need to deploy an HSM to protect encryption keys.  It is a fundamental core principle in an encryption strategy.  Trying to bypass that by the local storage of keys, or storing them in the clear on another server, will not meet compliance regulations nor meet security best practices.

To listen to our conversation in its entirety, download our podcast “Encryption Key Management with Microsoft SQL Server 2008” and learn how easy it is for your organization to start encrypting sensitive data on your SQL Server.

I was recently able to sit down with Patrick Townsend, our Founder and CTO, to discuss Microsoft SQL Server 2008 and what Microsoft customers should be thinking about when using Transparent Data Encryption (TDE) and Extensible Key Management (EKM).  Additionally, we talked about the role of an encryption key management appliance in regards to meeting compliance regulations such as PCI DSS, HIPAA/HITECH, etc. and what to look for when selecting one for your organization.  Here are a few questions from our conversation:

What is Extensible Key Management (EKM) on Microsoft SQL Server 2008?

Download Podcast Now

Microsoft introduced a new architecture for database encryption with SQL Server 2008.  It was a new architecture and a new way of approaching integrated database encryption. SQL Server 2008 had the first implementation of Extensible Key Management (EKM), and it is implemented in SQL Server 2008 R2, and the just announced SQL Server 2012. 

The real significant part of this is that Microsoft understood that there was a need for a new architecture for encryption, that it had to be standardized, and that it had to integrate third-party Hardware Security Modules (HSM) for encryption key management and protection.  So that is what EKM is.  It really has two primary components.  The first one is Transparent Data Encryption (TDE) and the second component is Cell Level Encryption. 

So, TDE is a brand new type of implementation under EKM.  TDE automatically encrypts the entire table space in a SQL Server database and it doesn’t require any application modifications.  It is a really great and easy way to implement encryption in your database.  Cell Level Encryption or Column Level Encryption is the second component.  It gives you the ability to pick a particular column in a SQL Server database and encrypt that column.  Cell Level Encryption does require modifications to your SQL applications, so it has a little more of an impact from the point of view that it takes a developers time to implement it.

Both TDE and Cell Level Encryption, under EKM, give you the ability to plug in a Hardware Security Module (HSM) to protect the encryption keys.  Microsoft also recognized very clearly that proper encryption of a database requires protection of the encryption keys in an appliance or HSM. 

Now that we know what EKM is, how does it work? 

It is a facility within SQL Server 2008, Enterprise Edition and above.  It isn’t activated until you explicitly activate it.  When you decide that you want to place your database under encryption control you go into the standard database administrators console for managing SQL Server and you define that you want to implement encryption through an EKM provider and specify how you want to manage your encryption keys.  You then place the database under encryption control.  It is really a simple process for implementing TDE.  In fact, we recently created a video titled “Setting Up TDE & EKM on SQL Server 2008” showing how easy it is.

Cell Level Encryption requires a couple extra steps to modify your SQL code, but the basic architecture is pretty simple.  Once you decide how you want to do it, you create encryption keys and you turn on EKM through an EKM provider.

To listen to our conversation in its entirety, download our podcast “Encryption Key Management with Microsoft SQL Server 2008” and learn how easy it is for your organization to start encrypting sensitive data on your SQL Server.