Townsend Security Data Privacy Blog

With V7R1 IBM introduced FIELDPROC (field procedure) exit points which Alliance AES400 for IBM i uses to encrypt database files at a field level. Since the cryptographic process is called by the database directly upon access, rather than by the application, this means that the process will work regardless of what type of application uses it. No application changes are needed, which is something our customers really like to hear.

These are five frequently asked questions we get around FIELDPROC encryption.

1. What type of fields are supported with FIELDPROC?

Surprisingly, virtually every field type is supported, whether it is character (even binary character), numeric (zoned, packed or binary) date, time, timestamp, Double Byte Character Set (DBCS), and hex. Some fields have certain restrictions, for example in order to implement fieldproc encryption on date, time, and timestamp fields you must specify a default value that is not ‘current date and time’.  You can define this in DDS or structured query language (SQL), and there is an option in the DB2/400 FIELDPROC encryption menu that will do this for you.

FIELDPROC will also handle blank fields by not encrypting them at all. This helps us achieve better results from certain SQL operations. FIELDPROC encryption however does not support fields with NULL values and they should be avoided or changed if necessary.

2. Will I need to make any changes to my applications?

As I mentioned above, it is not necessary to make application changes, but here is more detail as to why: In V7R1, AES/400 can create FIELDPROC exit points that tie to individual fields in a DB/2 file. When a file is opened for any operation, read, update, insert, or delete, the exit point calls one of our FIELDPROC applications, which calls our encryption or decryption APIs. It does this regardless of which application is accessing the file, thus creating application independent encryption.

A few things to consider are: when you backup your file you will need to also backup the FIELDPROC applications, and make sure you restore them at the same time as well. It is also important to remember that if the file is accessed through FTP it will be transferred in the clear.

3. Can I encrypt index fields?

In short, yes. However, encrypting index fields will affect the performance of your SQL operations, and the more indexes you encrypt, the more your performance will be affected. This happens primarily for the following reason: For faster performance DB/2 looks up records based on their encrypted values. This means that when you tell DB/2 you are looking for the record with social security number 111223333, and that field is encrypted, it will encrypt the search string and then retrieve the matching record for you. This is done as a performance enhancement especially when working with logical files on the IBM i. However for some SQL operations it decrypts all the records in order to read the index fields, so rather than encrypting single values to look up, it needs to decrypt a multitude of records.

4. What kind of performance can I expect?

In our test environment, which consists of a single processor IBM i platform, model 515, approximately 3500 CPW, V7R1 of the operating system with TR5 installed, we can process about 16,000 records per second. Systems with higher processing power should see better performance. This means that if we have a file with one million records and one field encrypted we can read the entire file in about 60 seconds. If they are 2 fields encrypted it will take us about 120 seconds because we are handling two million decryption calls.

5. Does using external key management affect performance?

In short, no. The time it takes AES/400 to retrieve a symmetric encryption key from our Alliance Key Manager server is approximately 0.0116 seconds. And this is through a secure TLS connection. There are network infrastructures in which this time may be slightly affected, firewalls, routers, switches, distance, however it should never create a noticeable difference in performance.

To learn more about automatic encryption on IBM i V7R1 using FIELDPROC, download the podcast "FIELDPROC Encryption on the IBM i" to hear IBM i security experts Patrick Botz and Patrick Townsend discuss encryption, key management, and meeting compliance regulations on the IBM i.

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!

In V7R1 of the IBM i (iSeries, AS/400) operating system, IBM introduced support for automatic, column-level encryption in the DB2 database call FIELDPROC (short for “Field Procedure”). For customers who are familiar with other automatic database encryption implementations such as Microsoft SQL Server Extensible Key Management (EKM) and Oracle Transparent Data Encryption (TDE), the new DB2 database implementation can be confusing. The encryption implementation in DB2 is quite different from other vendor implementations. Here are a few highlights of those differences:

FIELDPROC is not encryption, it is an exit point. What IBM is providing with FIELDPROC is the opportunity for you, the customer, to implement encryption at the column level. You have to enable the option, provide the IBM i AES encryption software, and do the implementation yourself. This is different from SQL Server and Oracle TDE where the database does the encryption for you.

Operations are on encrypted data. In SQL Server and in Oracle, the database is decrypted and then the SQL operations take place on the plaintext values. Not so in DB2 FIELDPROC. The necessary information is first encrypted, and the operation takes place using the encrypted value. This can lead to some surprises if you are not careful about your approach to AES encryption and Initialization Vectors.

Decryption might not be called on a read operation.  Some IBM i customers are surprised that FIELDPROC may not be called when doing a “read equal” type of operation. In SQL this can happen in a SELECT clause with a WHERE statement. In the RPG language this can be a CHAIN operation with a key value. The DB2 database will call the FIELDPROC application to encrypt the search value, but not call the FIELDPROC application if the search is satisfied. That will defeat your attempt to do data masking on decryption!

Database joins need special care. Database joins take place on the encrypted values, not the decrypted values. This means that identical values in different tables need to have the same encrypted value. This runs counter to normal encryption thinking in database tables.

FIELDPROC applications are dynamic calls.  The FIELDPROC applications that you or your vendor creates are going to be called dynamically from the database engine. This means that when you develop the FIELDPROC application you have to take special care that they perform exceptionally well, and that your encryption library is optimized (see next item).

Not all AES encryption libraries are equal. There are big performance differences between AES encryption libraries and it can mean a really big difference to your FIELDPROC application performance. We’ve noted before that AES encryption library performance can vary by a factor of 116. That difference can mean a batch job that takes 10 hours or 10 minutes. Be careful!

For further information view our webinar "Automatic Encryption on IBM i V7R1" and learn how Automatic Encryption is now possible on IBM V7R1 with AES/400.

Patrick

View Recorded Webcast: Automatic Encryption on IBM i View this webinar to learn how easy automatic encryption with FIELDPROC is on your IBM i. Click Here to View Now

Simplify your encryption project.  Encrypting data easily, automatically and securely on the IBM i is possible using the new encryption capabilities with V7R1 and AES/400. I recently sat down with Patrick Townsend, Founder and CEO of Townsend Security to ask, what are the five things customers need to know to help their organization automatically encrypt sensitive data on IBM i V7R1 with AES/400?  For even more information on automatic encryption on the IBM i, view our webcast below!

1.What is FIELDPROC?

In release V7R1 of the IBM i operating system IBM enabled it’s customers to implement automatic encryption using a new column-level API called FIELDPROC. FIELDPOC is an exit point that sits at the column level of the database and enable IBM i users to implement encryption and decryption without making any changes to their application source code.

2. We’re at V7R1, now what?

Upgrading your operating system is a start, however, IBM doesn’t provide the actual exit point software IBM i shops need to automatically encrypt and decrypt data - third party vendors and customers must do this.  Townsend Security’s AES/400 solution enables organizations to implement automatic encryption.

AES/400 and the FIELDPROC exit point in V7R1 give companies to easily encrypt sensistive data.  We call it automatic encryption, because it is the easiest, fastest and most secure way to encrypt data on the IBM i.

3. What types of data can be encrypted?

IBM i database applications use a variety of fields to store sensitive information. Encrypt fields that store data such as credit card numbers, SSN, birth dates, address, account numbers and other PII instantly without impacting applications.

Alliance AES/400 FIELDPROC support will protect any of the above mentioned fields without changing your database or your business applications. There is no need to reformat your database, or expand field sizes.

While most IBM i customers will use FIELDPROC encryption with legacy RPG and COBOL applications, FIELDPROC support also works with SQL applications, and Alliance AES/400 supports both program models concurrently. Your ILE and OPM applications will work well with FIELDPROC data protection. You do not have to have the source code for your application to implement Alliance AES/400.

4. Are there any security risks with automatic encryption using FIELDPROC?

Native IBM i object or user authorities will not protect encrypted data.  Automatic encryption and decryption works for all users and applications. Administrators cannot rely on native IBM i object or user authorities to control access to protected data, additional controls and policies must be put in place.

Data masking simplifies access control for security administrators.  It allows administrators to define which users and applications should have access to data and exclude users or applications that should not.  Security administrators can define users who should have access to the data, and define a default policy that masks the data for others

5. Will automatic encryption impact performance?

The IBM FIELDPROC exit point works by calling the exit program for each database insert, read, or update. The exit point program is also called on certain query and file positioning operations.  The right encryption solution can help minimize impact to system performance. Alliance AES/400 FIELDPROC support has been optimized for performance. The Alliance AES/400 encryption APIs are capable of encrypting 1 million credit card numbers in less than one CPU second. They are highly optimized for performance, and perform up to 100 times faster than equivalent IBM APIs on the IBM i platform. These same Alliance AES APIs are used for FIELDPROC encryption.

For more information on automatic encryption using FIELDPROC on the IBM i, view our webcast.

Your Encryption Project Just Get Easier!!

Automatic database encryption is possible with IBM i V7R1 and AES/400

No one wakes up in the morning and says they want to encrypt their data, other than those of us at The Encryption Company.   We   love to help companies get started with encryption and we love to talk about it.  Those facts aside, much of the IT world views encryption as an onerous project and one they will avoid until an auditor says they have to meet a compliance requirement for PCI, HIPAA,  etc.

The good news for IBM i shops is that the latest release of the O/S, V7R1, just made it easier for them to embrace an encryption project, instead of avoiding it.  The most significant update in V7R1 is the introduction of the FIELDPROC exit point, which provides for an exit point at the column level of the database.  We were so excited about what FIELDPROC does for IBM i customers that we updated our AES encryption solution, AES/400 to support FIELDPROC. This enhancement enables future and current AES/400 customers to implement automatic database encryption on the IBM i.

AES/400 version 6.0 allows administrators to apply instant field (or column level) encryption routines without impacting applications.  Administrators can also enforce what users and what applications are allowed access to the protected data.  Rather than rely on native IBM object level security, which is often not implemented correctly, simply specify which user and which program has access and exclude all others.  That’s it!   Around the office we are calling it push button encryption because it really is that simple to implement encryption at the database level.

To paraphrase Staples (a long-standing Townsend Security customer), Automatic encryption – that was easy! 

Request a demonstration today and let us show you how your company can be encrypting and decrypting data in a matter of hours rather than weeks.

I just listened to a discussion of database security hosted by Oracle that was very well done. At one point the discussion turned to current threats and how the Enterprise has lost the ability to use perimeter protection for sensitive data. This has been a topic of much discussion in the security area for the last few months. Perimeter protection is based on the use of Firewall and similar technologies to keep the bad guys out, but this approach is failing with the advance of more sophisticated attacks, the use of social media by large organizations, the advance of mobile technologies, insider threats, and the migration of applications to cloud platforms. The trend is called “de-perimeterization” and represents a bit of a challenge to organizations that need to protect sensitive data.

Vipin Samir and Nishant Kaushik did a great job of describing the how the process of de-perimeterization has forced companies to fall back on user access controls to protect data. But user access controls are notoriously weak.  Weak passwords and sophisticated password cracking routines make it almost impossible to properly secure a database. So what is a security administrator to do?

Here are the suggestions from the panel that are a part of a defense-in-depth strategy:

Use Encryption to Protect Data:
Companies should use encryption at the database level or column level to protect data. This will secure data at rest on backup tapes and on disk in the event a drive is replaced. Encryption is an important part of the data protection strategy, but it needs to be combined with other techniques.

Use Good Key Management:
Protecting encryption keys is the most important part of the encryption strategy. Good key management techniques are needed, and the keys must be separated from the data they protect. Without this separation from protected data it is impossible to implement separation of duties and dual control – important parts of the key management strategy. See our Alliance Key Manager solution for more information about securing encryption keys.

Separation of Duties:
Because the threat from insiders is rising, it is important that the management of encryption keys be separate from the management of databases. Database administrators responsible for our relational databases should not have access to encryption key management, and security administrators should not manage databases. This is a core principal in data security regulations such as PCI DSS, but is often overlooked.

Context Sensitive Controls and Monitoring:
The last important step is to be sure that data access controls are sensitive to the data and its context. Bill in shipping has access to the order database, but should he really be decrypting the credit card number? Does your encryption solution detect and block this type of event? How will you monitor this security event? Or, Sally is authorized to view HR data from the accounting application, but should she really be using FTP to transfer this data? Normal encryption functions would not provide adequate protection from these types of data access. Context sensitive controls are needed to augment encryption.

When we started planning for automatic encryption in our Alliance AES/400 product two years ago, we took care to implement context sensitive controls right in the decryption APIs. That is now available in V7R1 of the IBM i operating system. We avoided the error of basing these controls on user account authorities and native OS security. Just because the operating system says you have read access rights to a database table, doesn’t mean you should be decrypting the social security number or using FTP to transfer the file. I’m happy with our implementation that is based on explicit authorization by a security administrator, and application white lists.

You can get more information and request an evaluation version of our Alliance AES/400 solution here.

You can find the Oracle presentation here. Look for “How secure is your Enterprise Application Data?”

Patrick