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!

Tokenization is a technology that helps reduce the chance of losing sensitive data – credit card numbers, social security numbers, banking information, and other types of Personally Identifiable Information (PII). Tokenization accomplishes this by replacing a real value with a made-up value that has the same characteristics.  The made up value, or “token”, has no relationship with the original person and thus has no value if it is lost to data thieves.  As long as a token cannot be used to recover the original value, it works well to protect sensitive data.

Tokenization in Development and QA Environments

Tokenization is an excellent method of providing developers and testers with data that meets their requirements for data format and consistency, without exposing real information to loss.  Real values are replaced with tokens before being moved to a development system, and the relationships between databases are maintained.  Unlike encryption, tokens will maintain the data types and lengths required by the database applications.  For example, a real credit card number might be replaced with a token with the value 7132498712980140.  The token will have the same length and characteristics of the original value, and that value will be the same in every table.  By tokenizing development and QA data you remove the risk of loss from these systems, and remove suspicion from your development and QA teams in the event of a data loss.

Tokenization for Historical Data

In many companies, sensitive data is stored in production databases where it is actually not needed.  For example, we tend to keep historical information so that we can analyze trends and understand our business better.  Tokenizing sensitive data, in this case, provides a real reduction of the risk of loss.  In many cases it may take an entire server or database application out of scope for compliance regulations.  In one large US company the use of tokenization removed over 80 percent of the servers and business applications from compliance review.  This reduced the risk of data loss and it greatly reduced the cost of compliance audits.

Download our white paper “The Business Case for Tokenization: Reducing the Risk of Data Loss” to see how tokenization is helping organizations meet their business goals without exposing their sensitive data to loss.

As a company that provides NIST-certified encryption and FIPS 140-2 encryption key management, we need to secure data on a number of different platforms. Lately we have been coming into several cases where a customer needs encryption and key management on both Microsoft SQL Server and Oracle databases. Below is an email exchange with a customer who came to us “looking for a product to store, generate and manage keys that we use to encrypt/decrypt credit card information inside both SQL Server and Oracle Databases on Windows and UNIX.” We hope this discussion helps with your encryption project.

Customers Environment:

1. Encryption key is generated on the Windows platform through custom software, but if we can move away from that to an automated approach all the better. The key is moved to Oracle manually and we want to replace this with automation.

2. Credit card information is interfaced to our system then automatically encrypted using the key and stored in a SQL 2008 Enterprise Edition server table (only the one column is encrypted).

3. The SQL Server data is then sent to our Oracle database as encrypted data where it is stored in one column of a table.  It is then decrypted and sent to a payment services company who send us back a billing code, which replaces the encrypted credit card number.  So most of the encrypted credit cards are only stored for a short period of time, but some with problems are stored much longer.

Questions Addressed:

Our Alliance Key Manager (AKM) Hardware Security Module (HSM) provides full life-cycle management of encryption keys for PCI DSS and PII compliance. It works with applications and databases on a variety of platforms including Windows, Linux, UNIX, and IBM mainframes. We support the Microsoft EKM architecture for automatic encryption of SQL Server using TDE or Cell Level Encryption. Our customers also use AKM to manage keys for Oracle database applications, and support for Oracle TDE (requires Oracle Enterprise Edition and Advanced Security) is in our product roadmap.

SQL Server:

Because you are running SQL Server Enterprise edition, you have two options. The first is to deploy Extensible Key Management (EKM), which is supported by our Alliance Key Manager. EKM gives you the ability to automate encryption through Transparent Data Encryption (TDE) or Cell Level Encryption. TDE is usually the choice people make as it is the easiest to deploy and does not require any programming. Cell Level Encryption requires a bit of programming, but still fully automates the storage of keys on the key server.

The second approach is to use our Windows .NET key retrieval assembly to retrieve an encryption key from our key server and perform encryption in your application. Since you are already doing an encryption with a local key, this would probably be a pretty simple task. It appears that you might need this type of granular approach to support your current integration between SQL Server and Oracle. We have C# and VBNET sample code that shows how to retrieve a key from the key server.

Additionally, we support Windows 2003 for either approach and both of these approaches will meet PCI DSS standards for key management.

Oracle:

Our customers are currently using our key manager to encrypt data in Oracle databases. We provide sample code in Java, Perl, PHP, and other languages to support this. We also provide a shared library that does secure key retrieval from a variety of platforms, and also sample code that shows how use the shared library in PL/SQL.

Key Generation:

Encryption keys are generated on the encryption key manager using a secure administrator's console installed on a Windows PC. The interface to the key manager is a wire protocol and you can drive it from any application platform that supports SSL/TLS. All of your OS's do so. Our business users attempting to meet PCI DSS requirements for Dual Control and Separation of Duties typically stick to using our secure key management console.

Encryption on HSM:

Our Alliance Key Manager also supports encryption on the server. Rather than retrieving the key to your business application, you can send the data to the key manager with the name of the key you want to use, and it will return the encrypted or decrypted data back to your application on the secure connection. No key leaves the key server with this approach - just an alternative that is worth mentioning.

We hope that this case study can help you with your encryption project.  Listen to our podcast “Encryption Key Management with Microsoft SQL Server 2008 to learn how easy it is for your organization to start encrypting data on your SQL Server.

Many people we talk to are gambling with $7.2 million whether they realize it or not.  This week we are at HIMSS12 in Las Vegas meeting members of the IT medical community – an appropriate venue for such high-stakes gambling.  How are these people gambling with so much money?  The average cost of a data breach is $214 per record, or $7.2 million for an organization.  This figure is determined not only by direct costs of a data breach, such as notification and legal defense costs that impact the bottom line for companies, but also indirect costs like lost customer business due to abnormal churn.

Is there a way to make sure you aren’t putting your organization in such risk?  The HITECH Act, the compliance regulation that the medical community is concerned with, says that the only way to avoid a breach notification is through the use of industry standard encryption such as AES, and appropriate encryption key management technologies.  Other compliance regulations (such as PCI DSS) go as far as REQUIRING protecting Personally Identifiable Information (PII) with encryption and key management – not just to receive a breach notification exemption.

Becoming compliant with these regulations doesn’t have to be hard (though it can be).  Townsend Security has made it easy (saving your organization time and money) with NIST-certified AES encryption for all the major enterprise platforms, as well as a FIPS 140-2 certified encryption key management hardware security module (HSM).  For those organizations who are already encrypting but need key management, our encryption key manager can easily work with your existing database (SQL, Oracle, DB2, etc.) to help meet compliance requirements that call for separation of duties and dual control.

If you aren’t familiar with NIST and FIPS 140-2 certifications, the National Institute of Standards and Technology (NIST) provides them to encryption and key management solutions after they undergo a rigorous testing process.  The testing is carried out by independent testing labs who then report the results directly to NIST for validation.  Only the most dedicated security vendors are able to pass the tests and achieve NIST and FIPS 140-2 certifications.  Not only are these certifications essential for meeting compliance regulations, but they provide you an ease of mind that a third-party has verified the integrity of the product.

So are you gambling with $7.2 million?  If you aren’t protecting your PII with encryption and key management you might be.  Take the first step for help and call our gambling hotline (800-357-1019) or send us an email.  We’d be glad to help you step away from the table.

Learn more about proper encryption and key management best practices for HIPAA and HITECH Act in our white paper titled "Achieve Safe-Harbor Status from HITECH Act Breach Notification".

Are you an ISV?  Visit our ISV Partner Program page for more information on becoming a partner or download our white paper titled Healthcare ISVs: Critical Issues in Meeting HITECH Data Protection Regulations.

The last few days has seen a number of new reports about a security vulnerability in RSA public/private keys in use on the Internet. The vulnerability has to do with duplicate keys, and not with any weakness in the cryptographic algorithm itself. But it is disturbing information because public/private key encryption is crucial to the security of web sites and a number of other secure applications and services.

The news is based on the work of academic researchers and you can read the paper here.

While the researchers did not identify the cause of the duplicate keys, a number of us are guessing that the problem lies in random number generation. It is really easy to create bad random number generators, and hard to get it right and prove that you have it right. So any sloppiness in your engineering processes related to RNG can lead to this type of problem. There are not a lot of applications in use that create RSA public/private keys and X509 certificates, so the problem may be limited to a small number of these applications. But at this time there is no indication of which RSA key generation routines may be at fault.

How bad is this problem and should you worry about it?

At this point I don’t think there are any known attacks or breaches based on this vulnerability. It may have happened, but it hasn’t been reported yet. However, while the original researchers did not disclose their methods for identifying the duplicate RSA keys, it doesn’t seem hard to think of ways to do this. That being said, I am not sure how easy it would be to mount an effective attack even if you know about the duplicate keys. A lot is still unknown about this vulnerability.

I think Bruce Schneier has a good take on this issue. If you are concerned about this potential problem, you can read his comments here.

Are there bad random number generators in the wild?

You bet. Some years ago we found one on the IBM i (AS/400, iSeries) platform. In the early days of the IBM i platform you could use a system API named CEERAN0 to generate random numbers. We were shocked to learn how poor this RNG application is. It would start generating collisions within about 30,000+ cycles. That is really bad. It turns out that IBM also provides a cryptographically secure RNG application, but the older one still exists and we’ve seen it used in vendor and customer applications.

So, the obvious question is how can you know if a random number generator is good? One place to start is with the National Institute of Standards and Technology (NIST). NIST publishes guidelines on proper RNG methods, and a certification program. You can read the NIST recommendations for certifying random number generators here (warning: heavy lifting ahead).

NIST also has a certification program for random number generators and vendors like us can submit our work to independent labs that perform NIST testing. All of our cryptographic solutions have been through this testing. It is also important to note that encryption key management systems that undergo FIPS 140-2 certification also go through full RNG testing. Our Alliance Key Manager if FIPS 140-2 certified and the RNG routines were NIST certified as a part of that process. We’ve also certified our RNG implementations on a variety of platforms including the IBM i. The list of vendors who have completed certification are here.

While I don’t think NIST certifications are a perfect indicator of good cryptographic implementations, I certainly wouldn’t accept any encryption key management or cryptographic solution that had not been through an independent certification process.

Proper random number generation is crucial to secure cryptographic systems. You can’t leave RNG to chance (sorry about that).

When more information is available on the RSA vulnerability I’ll give you an update. 

For more information on the importance of encryption key management, download our white paper "Key Management in the Multi-Platform Envrionment" and learn how to overcome the challenges of deploying encryption key management in business applications.

Stay safe.

Patrick

Anyone who works with software applications in the medical segment is painfully aware of the complexity of patient information.  You mix a lot of personal information about patients, their family, their care givers, diagnostic information, pharmaceuticals, and insurance providers together, and you get a witches brew of data that would make your head spin.

Mix in a rapidly changing regulatory environment and you’ve really got a headache!

Medical organizations and application vendors have a lot on their plates keeping up with all of this, and now with new Electronic Medical Record (EMR) requirements coming into effect, they have to become experts in encryption technologies to protect patient information.

The lights are blinking red; system overload!

We’ve been helping medical organizations meet their data protection requirements with our encryption and key management solutions for several years. Our commitment to industry certifications such as FIPS 140-2 fits well with HIPAA and HITECH Act guidelines on data protection. When you read about NIST recommendations for encryption and key management best practices, we are already there.

Software ISVs who serve the medical industry also need partner-friendly solutions. ISVs need more than just a technical solution. They need someone they can call on to explain data protect best practices, who can assist in the implementation of encryption and key management, and who can help them stay competitive in their markets. The last thing an ISV needs is to integrate some expensive technology into their solutions and then find themselves at a competitive disadvantage. I am proud of our partner program and its focus on making sure our partners are successful both in their technology initiatives, and in their businesses, too.

This will be our first year at the HIMSS conference in Las Vegas, but we are bringing a lot of experience in the medical segment to the show.  I hope you find the show interesting and helpful, and that you come by our booth (#14124).

As we move closer to the finalized rules for HITECH data protection, some things are now becoming very clear.  The government wants ISVs and service providers to offer encryption of data at rest to their customers, and they want covered entities to use it!  While a careful read of the regulations reveals that they do not mandate encryption, the guidance makes clear that encryption is the ONLY safe harbor from breach notification.  Your customers will interpret this as a mandate, and will start demanding encryption in your products and service solutions.  We are already starting to see this happen.

Healthcare ISVs face some really big challenges as they start to move into the unfamiliar territory of encryption and key management.  Here are four critical issues you will face as you start down the path to securing your data at rest with strong encryption:

1)    The Big Challenge is Encryption Key Management

Encryption itself is not really the biggest technical challenge facing ISVs as they start to encrypt data in their application databases.  Most operating systems, databases, and programming languages offer encryption libraries that you can use right off the shelf.  For example, Microsoft provides encryption libraries in SQL server and the .NET language.  Oracle offers similar support for encryption in their database.  The really big challenge is encryption key management.  Encryption keys are the secrets that must be protected.  Key management systems create, store, and protect keys from loss, and this will be the hardest thing to get right.

2)    NIST & FIPS Certification

The HITECH guidance is full of references to the National Institute of standards and Technology (NIST) for encryption standards and best practices.  Advanced Encryption standard (AES) is the recommended technology for encryption.  And the NIST recommendations for key management are the gold standard for key management solutions.  Serious key management vendors submit their solutions to NIST for certification under the FIPS 140 protocol, and these vendors are easy to locate on the NIST web site.

3)    Getting Encryption and Key Management Right

You will be tempted to push the responsibility for encryption and key management to an outside vendor.  If it is really hard to do, why not let someone else do the job? You can refer your customers to the vendor for the solution, and the vendor can do the work of getting the database encrypted.  It seems easy.  Until you discover that your customers are not going to distinguish between your vendor and you when problems happen!  You will be ultimately responsible for any problems with data protection.

4)    The Right Partnership

Many ISVs discover that finding the right partner for encryption key management solutions is the biggest hidden challenge in their projects. Not only is the technology very specialized, there are a small number of vendors who offer FIPS 140 certified solutions.  You have to offer solutions to your customers that are easy to deploy and meet your product pricing objectives.  What if you need a customized key management solution?  Are there any vendors who are willing to help you with these requirements?  Finding the right partner is as important as finding the right technology.

Visit our ISV Partner Program page for more information on becoming a partner or download our white paper titled Healthcare ISVs: Critical Issues in Meeting HITECH Data Protection Regulations.

In our final installment on system logging on the IBM i series, Patrick Townsend, Founder & CTO, discusses what to look for when selecting and deploying a logging solution.  As we found out in part two of this series, it really isn’t a good idea to take the “do it yourself” approach.  System logs are in several different locations on the IBM i, and even if you get them all together, it is still a challenge to get them in a useable format.  Here is what Patrick has to say about selecting a logging solution:

So what do you need to look for when selecting and deploying a logging solution?

I think that there are four key points when looking at a logging solution especially on the IBM i Platform. One is, you want a real-time logging solution.  It won’t cut it to have a system collecting events once or twice a day and sending them off to a log server.  You need a real-time system that is collecting events as they happen so that your log collection server and your SIEM can actually correlate events across multiple servers and “see” what’s happening.

Secondly, on the IBM i, performance is always an issue. We have many customers running Alliance LogAgent with tens of millions of events a day.  Just this week we talked to a customer who was generating 120 million events a day.  That is a lot of events to be collecting and other solutions just can’t keep up with the sheer volume of events.  If your system can’t keep up with that, you will have a real compliance problem.  I’m really proud of the performance of our solution and that it allows us to do hundreds of millions of events every day, keeping up with the security events of the largest customers.

Third, logs should be protected while they are being transmitted to a log server.  Alliance LogAgent protects the transmission with a SSL/TCP connection.  Some of the information in your system logs can be very sensitive and it would be a bad idea to transmit this data in the clear.  When choosing a logging solution, it should have full support for a secure transfer mechanism.

Finally, industry standards are very important.  Standards are important on a very practical level.  When you buy a light bulb in the store, you want to be able to take it home and plug into a light socket.  You are able to do this because of standards.  The same is true for logging events on the IBM i.  There is a standard format for logging system events and the way you send your logs from an IBM i to a log collection server.  Query, reporting, and alerting tools depend on those standard formats.  The solution that you decide to deploy should be built on industry standards.  We support both the RFC Format and Common Event Format standards.

Those are the four most critical points for a standard logging solution and I am really proud that our product, LogAgent stands up really well on all four of those points. Overall, I think if you focus on those four items you’ll be in a good place.

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.

In the first part of our series on system logging on the IBM i (AS/400) we discussed why system logging is so important and where security information lives on the IBM i.  We will now continue my conversation with Patrick Townsend, Founder & CTO, and talk about log collection and meeting compliance regulations with system logging.

So now that you have identified the sources of this important system information, how do we format it for log collection and SIEM Servers?

This is probably the biggest challenge for IBM i users - getting log information from the IBM i into a usable format.  IBM i logs are not recognizable by a typical log collection sever or a SIEM console that monitor log data.  With Alliance LogAgent, we have tackled this problem by reading all of these sources of event information and translating from the IBM i format to a standard log format.  IBM does provide a few utilities for printing log information, and I have seen people try to use those to get data into a text type format, but they are unsuccessful because the printed log information is not in a standard format.  Another reason why this method doesn’t work is that it is typically not in real-time, so you’re not picking up information in a timely fashion - meaning you are missing threats that are happening in your machine.

Formatting data is a major challenge and we decided that the right way to do this was to bite the bullet and read the internal format of the logs, while they are completely unrecognizable to any standard log collection server, and format them to industry standard formats - based on existing RFC’s in terms of SYSLOG formats or Common Event Format.  Alliance LogAgent puts them in the right format and transmits them.  The technology in our logging solution is really focused on making all that log information usable, doing it in real-time, and then getting it to where it needs to go – allowing it to be monitored by your SIEM in real time.

System logging is also important for meeting compliance regulations too, right? 

Absolutely, if you take a look at PCI data security standards from the beginning, section 10 is focused on collecting logs and analyzing them in a timely fashion.  If you drill down into the recommendations for HIPAA/HITECH Act, or if you’re looking at FFIEC in the financial sector, or even privacy notification laws, they are all very consistent about requiring proper monitoring of system logs.  And this is understandable, looking at how threats evolve and what the typical threat looks like.

Sometimes bad software gets installed on a system and sits there for months at a time, undetected because nobody is monitoring the logs. That software can be phoning home through an IP connection and checking in through remote servers.  Your logs should be showing that activity.  That is why you’ll find across the board, in almost every compliance regulation, a need or requirement to collect logs in a central location, on a log collection server, or in a SIEM.  Someone needs to be paying attention to those logs and “someone” could be automated software, including products from SIEM vendors.  It is really important from a compliance point of view that you are collecting logs, doing it in a fast, real-time fashion, and have something monitoring those logs looking for threats.

View our Webcast “Understanding Log Management on the IBM i” for more information on logging and how it can help you meet compliance requirements with real-time security event logging across your Enterprise.

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.