Townsend Security Data Privacy Blog

As compliance regulations start mandating encryption and key management, we are seeing more and more companies stepping up their data security policies.  One important thing to realize is, that just because you are implementing encryption, it doesn’t necessarily mean that you are doing it correctly and will meet regulations such as PCI DSS, HIPAA/HITECH, State Privacy Laws, etc.

We have compiled a list of the top ten encryption pitfalls that your enterprise needs to be aware of.

 

1) Encryption Key Management

Encryption requires a proper key management strategy. This means protecting and isolating encryption keys from the data that they protect. For most companies this means using a proper key management solution across all of their servers and applications.  Townsend Security offers Alliance Key Manager to help meet key management and compliance regulations.

 

2) Completeness and Compatibility

It’s not uncommon for some encryption solutions to only implement a partial specification of AES encryption. There are nine encryption modes (five for business data) that can be used with AES encryption. An incomplete solution that encrypts with one mode — such as CBC — will leave you unable to decrypt with another mode like ECB. This incompatibility makes transferring encrypted data from one server to another difficult or impossible.  Townsend Security’s Alliance AES Encryption is NIST-certified on all five modes for business data.

 

3) NIST Certification

As regulators refine the requirements for encryption and key management, the certification of products to NIST standards is more important. The recent 2009 HITECH Act makes specific reference to the NIST standards for encryption and key management. Many vendors of encryption solutions ignore NIST certification leaving their customers exposed to these evolving regulations.

 

4) Performance

The impact of encryption on servers and applications is often an unpleasant surprise as companies implement their data security plans. There are large differences in the performance of vendor solutions. The performance impact of encryption can delay or derail data security efforts.

 

5) Application Modifications

Implementing encryption at the database level often involves some application redesign and modification. This requires work by companies and their vendors. This work is often unplanned and unbudgeted, causing financial and human resource problems.  It is important to make sure your application modifications are minimal.

 

6) Quality Assurance and UAT Testing

When applications and databases are modified to implement encryption, there is a need to re-certify them for accuracy, reliability and performance. Many companies find this effort larger than the effort to implement encryption.

 

7) Data Leakage to QA and Test Environments

Every company that maintains business applications must keep a set of data available to the developer and user acceptance teams so that changes can be adequately tested. Often the data used in these test environments contains sensitive information. Good practice requires proper protection of this information using encryption, masking, or tokenization.

 

8) System and Compliance Logging

A common question asked by auditors is “How do you know who decrypted a credit card number?” Unless your encryption solution has integrated compliance logging, you may not know who is viewing sensitive data in your database systems. Compliance logging is often overlooked by vendors of encryption systems, leaving companies perplexed in the event of a data loss.  Townsend Security offers Alliance LogAgent for the IBM i or Syslog-ng as both an application or appliance.

 

9) Key Access Controls

Encryption and key management access controls are essential to an encryption strategy. Can you specify who has access to the HR encryption key for payroll processing? The ability to restrict the use of encryption to specific users and groups is an essential security control.

 

10) Virtual and Cloud Platforms

Encryption and Key Management in VM and Cloud environments pose special challenges. The PCI SSC virtualization group indicates that security concerns are much higher in these environments.  Currently there is no standard for implementing key management in the cloud environment.

In conclusion, there are many factors involved when choosing the right encryption and key management solution for your enterprise.  Additionally, once chosen, it is also important to make sure that it is implemented correctly.  For more reading on encryption and PCI, we have written a white paper titled Encryption Key Management Requirements for PCI.

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 invited a partner to come down from Seattle to learn about our key management appliance, Alliance Key Manager. It started innocently enough, we planned to meet on February 21st and discuss our encryption, key management and system logging solutions in the context of PCI compliance.  A week later, I received a call from an Australian partner asking to come by our office for training on Feb 21st. They were going to be in Seattle after the RSA Conference. I told them they were in luck, we were coincidentally conducting a training session on that very day, come to our office, we would love to host them. 

We had two partners confirmed, why not ask a few more? Turns out some others were available as well.  Voila! The first annual  Townsend Security Partner Training was underway!!

The day started with a tour of our new offices- a must-see when in the Seattle area!! Training began with an overview of FTP Manager and PGP encryption.  Our latest release of FTP Manager, our managed file transfer offering, brings support for encrypted PDF and encrypted ZIP files as well as PGP administrative enhancements. 

Break! After a fabulous lunch at a local Italian restaurant, we delved into the world of encryption key management, database encryption, and system logging.

Patrick Townsend, Founder & CTO, addressed the importance of encryption & key management as a means of protecting data and meeting PCI compliance. 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 encryption keys.  He explained how compliance auditors requirements have evolved from "you must encrypt" to "don't store your keys with your encrypted data" to "protect keys with a key manager" and are now converging on the message "that key manager should be FIPS-140 certified."

Finally, partners were introduced to what an end-user sees when we work with them.  We took them through a pre-sales walkthrough and through a post-sales support ticket.  Eppy Thatcher, one of our senior support engineers, walked everyone through a demonstration of Alliance Key Manager and LogAgent.  A few of our partners were surprised to learn that some compliance regulations require collecting system logs. Eppy showed  them how Alliance LogAgent can communicate with any SIEM solution and help satisfy system log requirements.

By the end of the day, everyone walked away with a solid understanding of how our solutions work and how they can help meet compliance regulations.  Our partners saw the benefits of being able to offer their customers NIST and FIPS-140 certified encryption and key management solutions. They realize that these certifications will guarantee encryption and key management is done correctly.

If you are interested in becoming a partner or attending the next partner training session, please let us know.

Robbn Miller, Channel Manager

Townsend Security heartily supports non-profit organizations in our community. So it comes as no surprise that several Townsend Security employees were spotted at the annual United Way “Power of the Purse” fundraiser last week.

The event raises money to help disadvantaged women, young and old, become more financially stable and self-sufficient.  This is a cause that speaks to the hearts of the strong women of Townsend,  how could we not show our support? 

Over 100 women (and a few men) from all backgrounds and professions joined together to meet new friends and support a wonderful cause.  We strolled the silent auction, enjoyed a wonderful meal and participated in the bidding frenzy of the progressive auction.  Funds raised from the auction went directly to support the financial stability of women and girls of Thurston County, where Townsend Security has its headquarters.
    
The evening was a success in so many ways. Over $10,000 was  raised to create scholarships and help fund the overall program. We were able to visit with old friends and make new acquaintances.  And as the Ladies of Townsend packed up our purses and treasures from the evening we couldn't help but feel fortunate to have been in such good company while  supporting a wonderful cause.

For the month of March, 2011 Townsend Security is asking you to help us support the United Way.  Join the conversation and collobarate with fellow IT Security Professionals, we'll donate $1.00 for each new follower on Facebook, Twitter, or LinkedIn.

It was a great time of year to be in Anaheim, California last week for the IBM System z Mainframe SHARE user conference. The rains had just passed through and the weather was balmy. The Anaheim convention center is right next door to Disneyland, a place that was paradise to me growing up in Southern California.  The juxtaposition was not lost on anyone – Mainframes being the really serious computing platform, and Disneyland being the silliest and most fun place on planet Earth. But there was fun at the SHARE conference, too.

The death of the Mainframe has been predicted for years, but it keeps chugging along as one of the workhorses of large organizations. IBM has invested a lot in the hardware technology to keep it up to date, and you get a lot of bang for the buck with one of these systems. You can now even run Linux under z/VM and there are some really big installations of Linux on this platform.  All in all, it’s an impressive system.

I was at SHARE to support our partner, Software Diversified Services as they are now our distributor for PGP on the Mainframe z/OS platform. They are doing a great job of bringing this important encryption technology to IBM’s largest server system. People are often amazed at what you can do with PGP on the Mainframe. Create an Apple Mac self-decrypting archive on z/OS??? You have to be kidding, right? Nope, the PGP solution on the Mainframe creates self-decrypting archives for Windows, Mac, Linux, and flavors of UNIX. Also, it integrates with PGP Universal key server for key management. Another feature is that it compresses data up to 98 percent for encrypted data files. Additionally, it supports Mainframe file systems like PDS, Sequential, and VSAM. So PGP is an impressive offering for Mainframe customers who need to encrypt data for compliance. It was great to talk to the Mainframe customers who were approaching PGP with some trepidation. They were a lot more comfortable knowing that they could run PGP using normal JCL scripts.

With the customer base holding steady at between 6,000 and 7,000 customers worldwide, and with IBM continuing to improve the platform and make it more affordable, I believe it will be an important computing platform for years to come.  We’ll be seeing a lot more of Mainframes and Mickey Mouse for years to come.

Click here for a free evaluation version of PGP for the Mainframe.

Patrick

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

One thing that jumped out at me at this year’s RSA conference in San Francisco was the number of new vendors showing off mobile identification solutions.  There were at least four new vendors of mobile-based two factor authentication solutions, and one regular exhibitor with a new entry in this area. These vendors didn’t have the biggest booths or the most lavish give-aways, but as a category they certainly made a big splash.

I think there are really two things responsible for this big change:  Two factor authentication is now more important for security, and everyone now carries a cell phone or mobile device. The second part of this is completely obvious. In fact, I often see people carrying multiple cell phones. The ubiquity of the  cell phone makes them an ideal platform to deliver a one-time password or PIN code. And phone numbers are a lot easier to manage than hardware tokens.

The first part of this, the change in the security landscape, is not as well known to many people. As we’ve moved to a de-perimeterized security reality, we are more dependent on passwords to authenticate the users of our systems. And security professionals know how weak that dependence is. People who access our systems persist in the use of weak passwords, and the bad guys get better and better at password cracking and harvesting. By itself, password authentication is a poor defense, and that’s why two factor authentication is getting a lot of attention.

So what is two factor authentication? It means that you use two different authentication methods to access a system. Those authentication methods include:

•    Something you know (like a password or PIN code)
•    Something you are (fingerprint, iris)
•    Something you have (cell phone, HID card, hardware token)

By combining two of these authentication methods during system access you greatly reduce the chance of a security breach. For web applications, you generally find the use of a password with a PIN code generated with a hardware token (something you know, something you have), because it really hard to use a fingerprint reader or iris scanning device (something you are).  And that’s why cell phone based two factor authentication is picking up steam.

Don’t be confused by security systems that use one factor twice. I’m sure you’ve seen it at work on banking web sites. First you enter a password, then you answer a personal question (where were you born, the age of your oldest child, etc.). This is one factor authentication (something you know) used twice. This is when 2 times 1 is not equal to 2.  The use of one factor authentication twice does not add up to two factor authentication, and does not provide the same level of security.

Cell phones and mobile devices are a great way to deliver that second authentication factor. You have to have your cell phone to get the one time PIN code used for authentication. And everyone has one.

For more information on data security and compliance issues, visit the regulatory compliance section of our website to learn more.

Patrick

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

As day three of the RSA Conference 2011 begins, it marks the half-way point through the largest data security tradeshow that the industry has to offer. Walking into the show you would be hard pressed to tell whether you walked into a security show or a grown up play-yard. Look to left you see sumo wrestlers, looking ahead there are unicycles weaving the crowd, and to the right are pirates handing out candy. And to top it all off, each night ends with beer, wine, and appetizers for all attendees. Who wouldn’t want to attend the RSA Conference 2011??!!

As you look past all the gimmicks, the technology is still really what matters.

A noticeable change over the past two years is the increased awareness of FIPS-140 certification for key managers.

We believe this is largely driven by compliance auditors whose demands have evolved from "you must encrypt" to "you can't store your keys with your data" to "you need to use a key manager" and are now converging on "you need a FIPS-140 certified key manager."

As the auditing community matures we expect the requirements for formal government certifications to move from occasional to manditory.

In the past we usually only heard these concerns from sophisticated security architects with very large companies. Now we are seeing this awareness beginning to move through the SMB marketplace.

Prospective partners, future clients and current customers recognize that Townsend Security has done encryption and key management the way that it needs to be done – and proven by NIST and FIPS certifications. If your encryption offering hasn’t been reviewed and certified by NIST, you have no assurance that you aren’t implementing a less than secure product. “I wouldn’t consider an encryption solution that isn’t certified by NIST” is a common statement by attendees at our booth.

Would you like to see first hand how certified encryption and key management will work at your organization? Click on the links to request evaluation versions of AES encryption and Key Manager. One of our security specialists will be in contact with you to make sure you are up and running and answer any questions that you might have.

Or, if you just would like to learn more about encryption and key management, visit the resources section of our web site.

And if you read this while you are still at the RSA Conference 2011, stop by our booth and pick up a little somethin’ special that we have been saving you.