We have made our plans to be at COMMON in Minneapolis. Have you?

It’s almost here, that time of year when IBM System i (AS/400, iSeries) customers gather as a community to learn and collaborate about what is new with the platform.  It's almost time for COMMON, the largest gathering of IBM i users in the US.  This year the event is in Minneapolis, not too far from Rochester, MN – best knows as the "home of the AS/400".   You could say the AS/400 faithful are returning to the mothership.

Of course we are planning on being at COMMON,  we look forward to attending it every year.  It’s a great opportunity for us to visit with many of our customers,  catch up with our peers and meet new members of the IBM i community.   In addition to exhibiting at COMMON, John Earl and Patrick Townsend will be presenting sessions on data privacy.  John and Patrick are regulars at COMMON and their sessions are always well attended.  Here are some details about what they are presenting and when.

Encryption 101, John Earl 
May 1, 11AM – 12:15PM
101 H Minneapolis Convention Center

Security Challenge: Let's Break In!, John Earl
May 3, 2PM – 3:15PM
101 H Minneapolis Convention Center

Data Security and Encryption, Patrick Townsend
May 3: 9:30AM – 10:45AM
101 H Minneapolis Convention Center

Tokenization, Patrick Townsend
May 3:  5PM – 6:15PM
101 H Minneapolis Convention Center

So, as you make your plans on who to visit in the Expo be sure to include us on your list -- booth #511.   We are anxious to talk to our customers and old friends and look forward to making a few new friends as well.  

There are a lot of exciting things happening with Townsend in 2011, new products are on the horizon and updates to our most popular products; AES/400, FTP Manager and Key Manager will be coming soon.  Be sure to stop by and learn more!   If you would like to schedule a one-on-one with John or Patrick, send an email to marketing@townsendsecurity.com and we’ll make sure to accommodate your request.

See you in Minneapolis.

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.

It's user group time and I am hitting the road!

This month I have agreed to speak to 5 IBM i user groups in a seven day swing that will start in Seattle and then take me across the heart of the midwest.  It starts Thursday, March 10th at lunch in Seattle (a place I have spoken a lot, as you can imagine) at the Pacific Midrange Systems Association, and ends at a dinner engagement on St Patrick's day in Chicago at the OMNI user group. In between, I'll stop in Toledo Ohio then move on to Michigan, visiting user groups in Southfield, Lansing, and Kalamazoo. To see a complete list of cities and times, follow this link.

The flag ship presentation on this tour is a new creation called "Automated Encryption with V7R1."  As you can imagine, we're pretty excited about the new automated encryption capability that IBM has put in DB2/400.  Townsend Security customers who use our AES/400 encryption solution will be able to select sensitive fields in their databases and turn on encryption with just a menu option.  Townsend Security's AES/400 encryption then works with DB2/400 to automatically encrypt, and (based on rules you can specify) automatically decrypt data on your IBM i.  If you have been contemplating encryption on the IBM i, your encryption project just got a whole lot easier.

So if you're in the neighborhood of any of these user groups, be sure to stop by and say hello.  We love to meet and talk with our customers and learn how they are using our software.

Do you belong to a user group in another part of the country?
Drop us a line to see these presentations at your next meeting. Patrick or myself would enjoy coming out to your group and showing you how cool automated encryption is.

 

John Earl

Now that the new version of the PCI Data Security Standard (PCI DSS version 2.0) is in effect, many IBM i (AS/400, iSeries) customers are getting dinged on their PCI compliance in the area of encryption key management. The renewed focus on "Dual Control" and "Separation of Duties" by QSA auditors is forcing many IBM i customers to move from homegrown key management to a better method of securing keys. This is even happening for IBM i customers who use IBM’s Master Key and key database facility. Why is this? There is just no way to properly implement effective security controls for the QSECOFR user, or for any user with All Object (*ALLOBJ) authority. Thus no "Dual Control" and no "Separation of Duties." And QSA auditors have figured this out.

Moving to good key management does not mean you have to completely change how you encrypt the data. And it doesn’t have to be a time consuming, laborious process. Many IBM i customers use the native IBM i encryption APIs to protect data. Let us show you how easy it is to implement our Alliance Key Manager solution in RPG code while maintaining your encryption approach.

When you use the native IBM i APIs you first create an encryption algorithm context, then a key context, and they you use these contexts on the call to the encryption or decryption API. If you are using the IBM Master Key facility and special key database, you pass additional parameters to the key context API. Before migrating to our Alliance Key Manager solution your RPG code might look something like this:

      * Create a key context
     C                   eval      myKey = 'some binary value'
     C                   eval      keySize = 32
     C                   eval      keyFormat = '0'
     C                   eval      keyType = 22
     C                   eval      keyForm = '0'
     C                   callp     CrtKeyCtx( myKey      :keySize :'0'
     C                                       :keyType    :keyForm :*OMIT
     C                                       :*OMIT      :KEYctx  :QUSEC)
       *
       * Now we call Qc3EncryptData or QC3ENCDT to encrypt some data
       * and pass it the key context field <KEYctx>

After you implement the Alliance Key Manager solution and the IBM i API to retrieve the key, your application code would look like this:

      * Get the key from Alliance Key Manager
     C                   eval      AKMName = 'SomeKeyName'
     C                   eval      AKMInstance = ' '
     C                   eval      AKMSize = 256
     C                   eval      AKMFormat = 1
     C                   callp     GetKey( AKMName       :AKMInstance
     C                                       :AKMSize    :AKMFormat
     C                                       :AKMKey     :AKMUsed
     C                                       :Expires    :LastChange
     C                                       :Reply)
      *
      * Now we can use the field <AKMKey> on the create of the key context
      *
      * Create a key context
     C                   eval      keySize = 32
     C                   eval      keyFormat = '0'
     C                   eval      keyType = 22
     C                   eval      keyForm = '0'
     C                   callp     CrtKeyCtx( AKMKey      :keySize :'0'
     C                                       :keyType    :keyForm :*OMIT
     C                                       :*OMIT      :KEYctx  :QUSEC)
       *
       * Now we call Qc3EncryptData or QC3ENCDT to encrypt some data
       * and pass it the key context field <KEYctx>. That code is unchanged.

Notice that you’ve added a few lines of code to retrieve the key from the key server, and then used the retrieved key to create the key context. For most IBM i customers this will be a very quick change involving just a few lines of code. If you’ve taken a common module approach to isolate the encryption code, this might mean changing just one or two applications on your system. If you are using the IBM i Master Key and key database facility, you will have one more step to re-encrypt the data using keys from the Alliance Key Manager server.

Pretty simple process. Not bad for a day’s work.

Of course, there are proper ways to manage and protect an encryption key that has been retrieved from a key server, but we won’t go into that here. I want to save that topic for another day as it applies to many different application environments.

I hope you’ve gotten the idea that good key management doesn’t have to be a difficult, scary process. We are helping customers get this done today, and you can get there, too.

Click here to learn more about Alliance Key Manager and request an evaluation today.

Patrick

Last week we presented a webinar on PCI requirements for encryption key management.  Many of the people who attended were encrypting data on the System i and curious about how to manage their encryption keys according to new PCI requirements. 

The way organizations are managing encryption keys is falling under more scrutiny by QSA auditors.  Companies must demonstrate they are enforcing dual control and separation of duties.  

How is this achieved on the System i? Is it still effective to use an integrated key management solution that is store encryption keys in the same partition as the encrypted data?  The answer, quite simply,  is "no" PCI DSS requirement states the following requirements for key management:

 

• Dual Control means that at least two people should be required toauthenticate before performing critical key management tasks.
• Separation of Duties means that the individuals managing encryption keys should not have access to protected data such as credit cards, and those that have access to protected data should not have the authority to manage encryption keys.

Now here is an uncomfortable truth.  On the IBM i you simply can't achieve these PCI requirements if you store the encryption key in the same partition as the protected data.  The QSECOFR user profile (and any user profile with *ALLOBJ authority) will always have complete access to every asset on the system.  An *ALLOBJ  user can circumvent controls by changing another user's password, replacing master keys and key encryption keys, changing and/or
deleting system logs, managing validation lists, and directly accessing database files that contain encrypted data.  

From the perspective of PCI, an integrated key management system puts too much control into the hands of any one single individual.
The only way to comply with PCI requirements for key management is to store the encryption keys off of the IBM i.  Take users with *ALLOBJ out of the picture completely.  When you use a separate appliance to manage encryption keys you can grant a user access to the protected data on the System i and deny that same user access to the key manager.  Now you have enforced separation of duties.  And with the right key management appliance you can require TWO users to authenticate before keys can be managed, and have dual control of encryption keys.

Let us know about the key management strategy at your company. Is your organization encrypting data on the System i?  How are you managing the encryption keys? If you store them on a separate partition, have you had a recent PCI audit?  What did your auditor say?

IBM i (AS/400, iSeries) users send a lot of sensitive information to their customers, vendors, and employees which needs to be protected with strong encryption. Our customers today are using our PGP encryption solution to protect files. But there has been a big need to generate and protect information in common PC formats. With our upcoming release of Alliance FTP Manager for IBM i, we are stepping up our support with encrypted Zip files and encrypted PDF files.

Zip compression is very commonly used to send files via email. Not only does zip compression make our email attachments smaller, but the most popular zip compression programs now support 256-bit AES encryption of the contents. The ability to encrypt Zip files with AES provides a much better level of security than older zip protection methods. In the new release of Alliance FTP File Manager for IBM i we fully support Zip encryption to the WinZip standard. This means that you can create and protect Zip files on your IBM i platform, and then use a variety of delivery methods to get the Zip files in the hands of your customers, vendors, and employees. This will immediately give IBM i customers a new tool to meet compliance regulations.

The new Zip support provides rich capabilities to IBM i users. You can create encrypted or un-encrypted zip archives, include sub-directories, and use wild cards to select files. When uncompressing and decrypting you can specify any directory as the target for the files. This capability integrates with our automation facilities for processing received files. Lastly, we provide a Windows command line Zip application to help our customers who don’t already have a Zip application. I’m confident that this new capability will help our customers achieve a better level of security.

The other new security technology in FTP Manager for IBM i is our encrypted PDF support. In this first implementation, our customers will be able to create encrypted PDFs with their own content, and then use the automation facilities to distribute the PDFs via email, FTP, and other distribution methods. Encrypted PDF support includes the ability to set fonts and colors, embed watermark and graphic images, set headers and footers, and create tables and lists. The resulting encrypted PDF file is compatible with any PDF reader that supports the AES encryption standard for PDF. We’ve tested with a wide variety of PDF readers on PCs, Apple Macs, Blackberry, Linux desktops, and so forth. This will give our customers an additional tool to secure their sensitive data.

These new technologies for the IBM i customer will increase their abilities to meet compliance regulations and secure sensitive data. I hope you get the idea that we are dedicated to helping you protect your sensitive data and corporate assets. You are going to see a lot more of these types of new capabilities as we go forward.

Patrick