Townsend Security Data Privacy Blog

Everyone in the IBM i (AS/400, iSeries) world with responsibility for these large servers knows that IBM will soon announce the next release of the IBM i operating system, and that version V5R4 will go off of support a short time after that. While the date of the next release and the sunset date for V5R4 have not been announced, IBM has a fairly predictable pattern of new OS releases and support schedule. You can read Timothy Pickett Morgan’s thoughts in an article he wrote titled "The Carrot: i5/OS V5R4 Gets Execution Stay Until May."

So right now IBM shops running V5R4 are busy planning their upgrades. Many are planning to move just one version ahead to V6R1.

News Update! IBM just announce the support end date for V5R4. It’s September 30, 2013. You can read it here.

Upgrading your IBM i (AS/400) to V6R1 instead of V7R1 is a bad idea. Here’s why:

In V7R1 IBM provided a new automatic encryption facility in DB2/400 called FIELDPROC (That’s short for “Field Procedure”). This new facility gives IBM i customers their first shot at making encryption of sensitive data really easy to do. With the right software support you can implement column level encryption without any programming. The earlier trigger and SQL View options were very unsatisfactory, and the new FIELDPROC is strategically important for customers who need to protect sensitive data.

Another key feature in V7R1 is a new version of the Secure Shell sFTP application. This is rapidly becoming the file transfer method of choice. And IBM provides version 4.7 in V7R1. If you are doing a substantial amount of file transfers with sFTP, or you plan to do so, you will want all of the latest security patches in OpenSSH.

I know that an operating system upgrade is a lot of work, and that’s why IBM i shops are reluctant to do it very often. And when they do an upgrade, there stay there as long as possible. But FIELDPROC is only available in V7R1, it is not patched back to V6R1. And the latest version of OpenSSH is provided in the V7R1 distribution.

So I think you should skip V6R1 and go directly to V7R1. You won’t want to be locked in to a version of the OS without important security features. And the jump from V5R4 directly to V7R1 is a fully supported path by IBM. I hope I’ve convinced you to consider this important security option as you look at your OS upgrades this year. 

Download our podcast on "The Benefits of FIELDPROC Encryption" to learn more about FIELDPROC capabilities and the benefits of transparent encryption.  Additionally, we have a podcast titled "FIELDPROC Performance - Speed Matters" for those who are wondering how it will impact their systems.

Patrick

Are you going to COMMON in Anaheim? I will be doing four sessions on security on the IBM i. Be sure to stop by the booth and say Hello!

As a company that works hard to protect your data, we get a lot of questions – from people wanting to know the ins and outs of our products to IT professionals who are new to the world of meeting compliance regulations.  Luckily, our company has several experts to answer these questions.  One topic that we often get questions regarding is system logging on the IBM i (AS/400).  Logging on the IBM i is different than logging on other platforms.  I recently sat down with Patrick Townsend, Founder & CEO, to pick his brain on what system logging is, and why it is so unique on the IBM i.

System logging has become one of the most essential compliance tasks in contemporary corporate IT. Can you give a brief explanation of what logging is and why it is so important?

Sure, all computer systems, including the IBM i (AS/400, iSeries, System i) collect lots of important information about the security state or the operational state of the system as a whole.  We call these System Logs and they often include a great deal of information about what is going on in the system.  In a lot of systems, including the IBM i, these logs are created in real-time.  To give an example, if someone tries to sign into an IBM i and for whatever reason the username or password is invalid, that event is logged in the system log.  This is an important thing to log because if you were to look at this system log in real-time and notice several invalid username and password events, you would say “Hey, our system is being attacked. We need to take action on this now.”  In summary, System Logs are just a central repository on the computer system that say what is going on within the system.  This is why they are so important from a security point of view.

Where does security information live on the IBM i?

Security information lives in a number of places, which is one of the challenges that IBM i administrators have.  On the IBM i, IBM creates a central repository (QAUDJRN in the IBM i world) for a large number of security events including password and other security events. Our Alliance LogAgent customers can decide what kind of events they want to collect.  QAUDJRN is not the only place to look for this security information. There is also a system event log file called QHST that has important log-on and log-off information for users.  The operators console (QSYSOPR) collects and tracks important events and messages for security monitoring.  Finally, the IBM i sports a lot of new, web-type services that have their own log collection facilities including WebSphere, Apache, and SSH.  In order to properly look at all of the security events that are happening on an IBM i, you have to look in several places, which can be a challenge.

Listen to our podcast “System Logging on the IBM i” for more information on logging, how it can help you meet compliance requirements, what to look for in a logging solution, and how Townsend Security can help you transmit the logs from your IBM i to any SIEM console.

Meeting compliance regulations on your IBM i for securing data in motion doesn’t need to be difficult.  They all have the same overlying theme – encryption.  PCI DSS requires encryption when transferring files over the internet and WiFi networks.  HIPAA/HITECH says that encryption is the only Safe Harbor from a data breach.  While failing to comply with these regulations can financially impact your organization, the good news is that with just a few core encryption components, you can easily satisfy these requirements.

There are a handful of core components to look for when deciding on a managed file transfer solution for your organization.

• SSL FTP with 128-bit encryption
• sFTP with 128-bit encryption
• PGP file encryption with 2048-bit keys
• Audit trails

Our Alliance FTP Manager not only contains all of these components, but also enables users to automate their managed file transfers.  Alliance FTP Manager provides several automation functions to help you exchange files without human intervention.  Users can automatically transfer files using Secure Shell sFTP or secure SSL FTP to banks, insurance companies, benefits providers, payment networks, and any other internal or external server.  The transfers are encrypted to meet compliance regulations (such as PCI DSS, HIPAA/HITECH, and privacy notification laws).  Additionally, audit trails and system logs provide the permanent history needed for compliance regulations.

Finally, Pretty Good Privacy (PGP) is the de facto standard for file encryption before transmission to a trading partner.  Based on open standards and tested by time, PGP has won the trust of governments and private enterprises to protect their sensitive data.

Are you ready to get started?  Download a 30-day evaluation of Alliance FTP Manager, configure it, and send your first encrypted file transfer in about an hour. Sending and receiving encrypted data just doesn't get any easier.

I’ve been writing about encryption performance lately because our customers and potential customers have been asking about the impact of encryption on the overall performance on their systems.  It’s good that they are asking these questions as a poorly performing encryption library can have severe impact on your application environment. This is especially true on an IBM Enterprise platform like the IBM i (formerly known as AS/400 and iSeries) where customers often run multiple applications.

While it is common in the Microsoft, UNIX, and Linux worlds to segment different applications onto different physical servers, it is common in the IBM i world to run many applications on the same server. You typically find CRM, ERP, web, and many other applications happily co-existing on one IBM i server. But this means that a poorly performing encryption library will have a ripple impact on all of these applications, and not just one.

IBM provides a no-charge, AES software encryption library on the IBM i platform that developers can use to encrypt data. It implements all of the standard AES key sizes (128, 192, and 256) along with a variety of other encryption algorithms, both open and proprietary.  I don’t believe the software library has been independently certified to the NIST standards, but I believe that it properly implements the AES encryption algorithm.

But how does it perform?

We did a simple little comparison test of encrypting 1 million credit card numbers on an entry level IBM i model 515 server with a single processor. We compared the native IBM AES library with our own AES encryption library which is NIST certified and optimized for encryption.  The difference is very large. Our IBM i encryption library clocked in at 116 times faster than the native IBM i library. Note that this is an informal test and not independently verified, but practical experience by our customers is very similar.

What does this mean in terms of application performance when you add encryption to the mix? The math is pretty simple. An encryption task that takes 10 minutes with our library will take several hours with the IBM library. That’s painful. And all of the other applications that share this system will also feel the pain.

The problem is not limited to just an occasional developer at an individual customer site. Some vendors of IBM i software use the IBM encryption libraries, too. So you can be inadvertently using the poorly performing libraries without knowing it.

Often I see IBM i customers trying to fix an encryption performance problem by adding additional processors to their servers. This can be expensive, and usually involves software license upgrade fees. It can also not have the impact that you might think. Due to the way that encryption works, adding a second processor usually will not double your encryption throughput. Another bit of disappointment and extra cost.

It is usually not hard to fix an encryption performance problem if you catch it early. If you’ve take a modular approach to the implementation, you can usually swap out one module for another without too much difficulty. You just don’t want to be doing that for hundreds of applications.

For more information on AES encryption, download our white paper "AES Encryption and Related Concepts" and learn about how proper encryption and key management work together to secure your data.

Patrick

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!

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

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:

Elapsed time:	68 seconds
Records per second:	14,705
Application CPU:	34.33

Read all records to force a decryption:

Elapsed time:	62 seconds
Records per second:	16,129
Application CPU:	37.43

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

Elapsed time:	88 seconds
Records per second:	11,363
Application CPU:	81.26

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.

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

Last week we posted part one of our two-part series covering XML & Web Services.  This second half covers how organizations are currently using web services, how the technology can increase revenue, and how the technology can reduce costs.  For even more information, we have made a recorded webinar available titled "XML & Web Services - How to Win More Business."

How are organizations currently using web services?

There are lots of ways web services are being used to help companies do business and make business work well.  Definitely in back-office processing, we see orders being placed via web services -- shipment requests, notification of order status, all types of business transactions that you can imagine are quite easily implemented as a web service.  So, sort of that fundamental day-to-day operational side of web services are there.  And then you see some really creative kind of things.  You see things like Microsoft SharePoint which provides a web service based collaboration tool that helps people share information and collaborate on documents.  These are powerful technologies that can really be used in a number of different ways.  So, really, almost any interaction that you have that involves information is quite susceptible to being engineered through web services. 

How can the technology increase revenue?

View Recorded Webinar Now

Well, think of new business.  Sometimes, when you want to bring onboard a new customer there is going to be some data interchange that you have to do with that customer.  Web services can make that really easy and fast to do.  Web services can really be an enabling technology to on-board entirely new sets of customers – perhaps in lateral opportunities.  In terms of increasing revenue, that is probably the main way we see XML and web services being deployed.

You mentioned that this technology can also reduce costs.  Can you explain?

In today’s world there can still be a lot of manual work as we move data through our various applications.  Web services can automate that.  We can gain efficiency within our own organizations by automating a lot of these processes.  So, again, XML and web services can be the transport mechanism or the enabling technology for these processes to happen automatically.  We push out inefficiencies, we automate processes, we make data flow faster, which then can improve customer service.  So XML and web services can be an important efficiency tool within an organization as well.

Are there any specific cost savings for our listeners who implement a SharePoint server?

A SharePoint server is a Microsoft server based product that is a collaboration tool and it really lets people in geographically different locations share information in real-time.  So you can push a document up to a SharePoint server, someone else can get notified that the document is available, and then immediately take a look and work on it. This is all done with a web services type of implementation.  Or imagine you are on an IBM Mainframe where you are running back-office applications. What if your daily reports could automatically be published to a SharePoint server and made immediately available to the people who need them?  You can now reduce printing costs, time for the information delivery, and you make that information much easier to share.   So this technology is really helpful for pushing cost out of an organization.

Are there any companies we might recognize using your XML?

Sure!  PotteryBarn is using the RightNow CRM and they needed a way to do bulk data transfers to a SharePoint server hosted by RightNow.  Our Alliance XML/400 was able to do that.  In this case, the payload was an Excel CSV file that had to be shared between PotteryBarn and RightNow.  Our technology made this sharing take place.

How complex is the implementation of XML and web services technology?

That’s a good question.  Let me take that in two parts.  XML and web services technologies have a fair amount of complexity in them.  You have issues of security with HTTP/HTTPS implementations and you have the complexities of dealing with XML payloads - they have to be parsed properly to extract data and make it useable. 

Encryption and encoding becomes an integral part of this technology, so there are a fair amount of really complex technologies integrated into a web services solution.  However, the actual solutions that get deployed don’t have to be complex. 

For example, in Alliance XML/400 we make the implementation of the client and server applications very simple.  They are natural native interfaces on the IBM i that any developer can use if they wish.  So in our solution we tried to hide the complexities of all these technologies in the solution itself, so that our customers don’t have to deal with that.  I think that deploying XML and web services with our product is a very straightforward and easy thing to do. 

We have had people in a very short period of time get up and running with integration with their customers – in as little as a couple of days.  This is something that can be deployed quickly.  Good solutions hide those complexities so that people can get on with doing business and not spend their time fussing around with the technology itself. 

This has been some great information.  Is there anything else you would like to say before we are done?

XML and web services are really enabling tools.  We are living today in a difficult economic time and yet the most successful companies are moving forward.  They are working to engage new opportunities, to reduce cost out of their organizations, and XML and web services technologies can help with this process.  So, being positive and looking for opportunities and being sure to look at the payback for web services as part of the whole picture is really important.

For more information on XML & Web Services, view our webinar titled "XML & Web Services - How to Win More Business."

 

We're just recently back from the COMMON 2011 conference in Minneapolis.  What a great experience for Townsend Security and our IBM i customers.  The encryption and key management sessions that Patrick and I presented were well received and well attended.  Many of the attendees were interested in the mechanics of encryption, and many of those were pleasantly surprised to learn that there is now a way to encrypt database fields without doing massive application program changes.  

At COMMON we announced our new Automated Encryption capability that is now embedded in our benchmark AES/400 product.  Automated Encryption allows you to insert encryption at a database level, rather than at the application programming layer, and that greatly simplifies the task of encryption.  Automated Encryption increases the efficacy of encryption too.  By enforcing encryption at the database level, you eliminate the chance that an application program might be unwittingly introduced that might not follow your encryption standard.  Encryption at the database level ensures that every credit card, or every social security number, is encrypted in the database - without the need for additional application programming.

Another bright spot at COMMON was the number of customers that were either already at IBM i V7R1, or were planning to get there in the next few months.  With the status of OS version V5R4 uncertain (it's End-of-Support date has been extended by IBM at least twice), there was a lot of discussion about what the right upgrade path is.  V7R1 has been out in the market for over a year, and with great new features like the database FieldProc (Field Procedures) It was encouraging to see how many customers were either already on V7R1, or had immediate plans to move there.  A number of customers that currently on OS version V5R4 were planning to move directly to V7R1 without stopping at V6R1.  While they don't avoid the problems of program conversion at V6R1, they do get to the stable, current release in one step rather than two.

Finally, it was great to talk to all of the people that stopped by our booth during the conference.  We spoke to over 300 people during the two and a half day expo.  For those of you that asked questions or made data requests, we are in the process of going through our notes and providing the requested feedback - someone will reach out to you soon.  Most everyone else will have gotten an invitation to follow us on LinkedIn, FaceBook or Twitter - that's a great way to keep up with what is happening in the encryption world and to stay on top of data privacy trends.  We're always producing new educational material about encryption, keymanagement, and data protection, so it's a great way to stay current on those topics.

And for those of you that couldn't make it to the COMMON conference, you can still follow us on social media, and we hope to see you at a tradeshow in the future!

jte