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

A number of studies show that only about 25 percent of companies and organizations have deployed encryption of data at rest to meet privacy regulations, and we seem to be stalled at about that level.  We are now about 10 years past the really big data losses that led to the emphasis on protecting data, why are we making so little progress?

I think one of the main reasons is the level of difficulty in deploying most data encryption solutions. Most organizations still see an encryption project as requiring lots of time, money, and human resources to accomplish. As humans I think we all have a tendency to avoid the hard and painful things we know we need to do (I plead guilty). And this is an impediment to getting our data protected with the right encryption and key management technologies.

Vendors of data protection technologies have been slow to address this part of the equation. We have our heads in the technical side of things trying to be sure that we implement secure solutions that meet best practices, and working towards the difficult product certifications that we have to accomplish. The user experience is not usually the thing most on our minds. So, I think we’ve been a part of the problem.

It is also true that developers who are good at the user experience are generally lousy at security. You just don’t go about security development in the same way you mash up a new web service.  Most of the new web-based security solutions that promise to make things so much easier look from the outside really terrible in terms of encryption, key management, and interface security.

It is up to those of us who make security solutions to make them easier to use. Here at Townsend Security we are trying to channel Steve Job’s focus on the user experience.  Once you have the foundational security applications done and certified, it is time to look at how to make them easier to use. This year we implemented our SQL Server EKM encryption key management solution that makes it easy to secure Microsoft data. We also introduced IBM i FIELDPROC automatic encryption which is making data protection a lot easier for AS/400 customers.  I am convinced we are on the right track in this regard, and you will find us trying to make other environments easier to secure as we go forward.

Best wishes for the New Year!

Patrick Townsend

Learn how we have made encryption key management easier and more affordable than ever with Alliance Key Manager.

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

Yesterday, our partner, Symantec, released a survey on enterprise encryption practices.  The study contained both good news and bad shows when it comes to encryption and key management.  

First the good news, in a recent interview with eWeek Tim Matthews, senior director of product marketing at Symantec said, “About 48 percent of the survey participants reported their organization had increased their use of encryption over the past two years, with one third reporting "somewhat to extremely frequent" deployments of "rogue" projects without any centralized management oversight.”

Now the bad news, Tim Matthews goes on to say, “Business groups and employees are often independently encrypting the data without involving the IT department. While the move to encrypt is a good thing, these unauthorized deployments are a challenge for IT because the data is lost and irretrievable if the employee loses the key, forgets the passphrase or leaves the company without passing on custody of the encryption keys. If IT doesn't have the key, it also becomes harder to properly backup the data or to access the information as part of an e-discovery request”

We understand the difficulties in managing encryption keys and have been helping companies for years with this challenge, so when we saw this statistic about poor key management, it did not come as a big surprise to us, because we hear about the challenges first hand.  The study showed:   “About 52 percent of the respondents said they have had serious key management problems, with about a third claiming that keys were lost or misplaced keys and another third citing key failure. A little over a quarter, or 26 percent for the participants, said former employees refused to hand over keys when they left the company.”

We have posted several different checklists for companies to help them in their selection of key management vendor. One of our more popular lists is the 10 questions that you should ask your potential key management vendor. Given the news in the study, we thought it was worth showing this list again:

1. Is your key manager FIPS 140 certified?  What is the certificate number?
2. How would you describe the encryption key payload as retrieved from the key server?  Is it simple or complex?
3. Is there a common key retrieval application interface on all platforms?  What are the differences?
4. What platforms do you support for key retrieval?  (Note any gaps in platform coverage for your company)
5. Do you provide working sample code for the platforms I need? (Windows, Linux, UNIX, IBM i, IBM z)
6. Do you supply binary libraries for all Enterprise servers?
7. Do you have a Java key retrieval class and examples? Is it standard Java or JNI?
8. Do you charge separate license fees for each client operating system?
9. Do you require that we purchase consulting services from you?  Why?
10. I am an independent software vendor (ISV), can you brand the solution and certify the solution for us?

We encourage you to download and read the study from Symantec. We are sure you will find it very informative.  Then once you have read the study and have decided you need to learn more about encryption key management, listen to this informative 15-minute podcast.

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

IBM introduced FIELDPROC (Field Procedures) in V7R1 of the IBM i (AS/400, iSeries) operating system to provide for an automatic method of implementing encryption at the column level. While new to the IBM i platform, FIELDPROC is not actually a new technology. It was first implemented on the IBM System z mainframe platform about 20 years ago. But it is new to the IBM i and is now starting to get a lot of attention as customers start the upgrade process to V7R1.

The attraction of FIELDPROC is that it gives you a way to implement AES encryption on the IBM i without changing your application code. As long as you have an application that can perform key retrieval and encryption (IBM does not supply this) you are ready to implement FIELDPROC. 

But you should be aware of the one really big impact of FIELDPROC on your application – performance. A FIELDPROC program is called dynamically from the DB2 database engine. That is, it is not statically bound to the database, and it is not incorporated as a service program (dynamic ally linked library). The dynamic nature of the FIELDPROC invocation added on top of the encryption CPU load can lead to really bad surprises when you roll into production.

Before you deploy your own or your vendor’s FIELDPROC code, do some simple tests. I suggest that you do these simple tests on a database of 1 million records:

• Start FIELDPROC to place the entire table under encryption control.
• Read the entire database to force a decryption on every record.
• Update the encrypted field in every record to force a decryption and encryption for every record.

If you have multiple fields in a table under FIELDPROC control, you will want to do additional performance tests as well. If you encrypt 20 fields in the table, what will happen when FIELDPROC gets called 20 times with every database read?

We are a vendor of a FIELDPROC solution and I will share some results with you from one of our in-house systems. To line up with compliance regulations and encryption best practices, we used our FIPS-140-2 certified encryption key management appliance and our NIST certified AES encryption library. These results are not independently verified, but you can you can download the tests and try them on your system (always a good idea).

The Platform:

An entry level 9407 model 515 with a single POWER5+ processor, 1 Gigabyte of memory, two 70-Gigabyte model 4327 disk drives (no RAID), and a CPW rating of 3800. The latest V7R1 cumulative PTFs are installed. This is the slowest thing we have in the house.

The Database:

A simple, uniquely keyed DB2 database created with DDS and containing 5 character fields and one packed numeric field. One of the non-keyed character fields is encrypted with FIELDPROC. The file contains 1 million records.

Encryption Key Management:

Our FIPS-140-2 NIST certified Alliance Key Manager encryption key server installed on the local network. Our FIELDPROC application will automatically and securely retrieve the encryption key when needed.

Encryption Library:

Our NIST certified, optimized, 256-bit AES encryption software library.

The Application Environment:

No other applications running on the system at the same time; the system is in normal state (not dedicated); all applications are OPM model with no optimization; tests are run in batch.

The Results:

Start FIELDPROC to place the database under initial protection:

Read all records to force a decryption:

Update all records to force a decryption, an encryption, then an update:

I think this is a pretty good baseline of minimum performance our customers will see with our FIELDPROC solution. Most of our customers run with the more modern POWER6 or POWER7 processors which bring a lot more CPW power to the task (a new entry level POWER7 process has 10 times the CPW rating). More and faster disk drives and more memory will definitely help performance. So you should see substantially better performance in real-world environments.

I hope this provides some helpful guidelines for your FIELDPROC project.  Download an evaluation copy of our Alliance AES Encryption for FIELDPROC to see for yourself just how easy you can be protecting your sensitive data.