Townsend Security Data Privacy Blog

Understanding the basics can help you avoid problems! 

As enterprise customers deploy data security solutions to meet various compliance regulations (PCI DSS, HIPAA, etc.), they are frequently surprised by the performance impacts of encryption. Inadequate preparation in an encryption project can lead to increased costs, delayed (or even failed) projects, inability to meet compliance requirements, and even exposure in the event of a data breach.

By its very nature, encryption and decryption are resource intensive processes. Enterprise customers can be surprised to discover that encryption from one vendor can perform very differently than the very same encryption from another vendor. While the various vendor solutions accomplish the same tasks, they vary greatly in how efficiently they do these tasks. The differences can vary by a factor of 100 or greater! This can have a large impact on business applications that perform encryption and decryption tasks. One vendor’s solution may encrypt a data in 10 minutes, and another vendor’s solution may take 10 hours to perform the same task!

Avoid surprises, ask for performance metrics:

Armed with the knowledge that encryption performance is important, you can take action to avoid potential problems. Before acquiring an encryption solution, ask your data security vendor to provide performance metrics for their solution. How long does it take to encrypt one million credit card numbers? Can they provide you with source code and demonstrate this performance on your server? Optimizing software for performance is a complex task and usually involves specialized technical talent and some experimentation with different computational techniques. Unless an encryption vendor is deeply committed and invested in encryption technologies, they may not make performance enhancements to their applications.

Create your own proof-of-concept applications that measure encryption and decryption performance in your application environment. Be sure to measure how well the encryption solution performs under your current transaction loads, as well as anticipated future transaction loads. A good rule of thumb is to be sure you can handle three times your current encryption volume. This will position you for increased loads due to unexpected changes in the market, or an acquisition of another company. It also insures that you are seeing real-life performance metrics, and not just the vendor’s marketing message.

Avoid hidden costs, ask for pricing calculations:

Ask your purchasing and accounting departments to include performance upgrade costs in the pricing calculation during vendor evaluation. Be sure these costs include any increases in software license fees. If an encryption solution consumes one third of the CPU processing power of a server, you might want to include the cost of upgrading to a processor twice as powerful as the one you have. Working these costs in during the product evaluation phase can provide a more realistic view of the actual cost of a vendor encryption solution. Upgrading hardware can lead to unexpected additional software costs. Some software vendors license their solutions to the number of processors, or speed of the processors, in your server. Upgrading hardware to solve a performance problem can result in increased software license fees.

Avoid red flags, not all AES encryption solutions are the same:

Some encryption solutions use “shadow files” (files external to your application) to store encrypted data. The use of shadow files normally indicates that the vendor has an incomplete implementation of the AES encryption suite, or that the system architecture is limited in some way. The use of shadow files can impose severe performance penalties. In order to perform an encryption or decryption task an addition file read or write is required which essentially doubles the file activity. This may also increase processor loads as your application mirrors the data to a hot backup system. You will want to be very careful in measuring the performance impacts of encryption solutions that use shadow files.

If an encryption vendor will not provide you with a fully functional evaluation of their solution, this represents a clear warning signal. Your application environment is unique and you will need to be able to evaluate the impact of encryption in your environment with a limited test. A vendor who refuses to provide you with a clear method of evaluating the performance of their solution may not have your best interests in mind.

Avoid frustrations, take a test drive with us:

Despite an organization’s best efforts, data will get out. The best way to secure sensitive information is with strong encryption that is NIST compliant and FIPS 140-2 compliant key management that meets or exceeds the standards in PCI, HIPAA/HITECH, and state privacy laws. For a more technical look at AES encryption, including FieldProc exit points and POWER8 on-board encryption, check out this blog by Patrick Townsend, Founder and CEO of Townsend Security: How Does IBM i FieldProc Encryption Affect Performance?

Our proven AES encryption solution encrypts data 115x times faster than the competition. But don’t just take our word for it, we provide a fully functional evaluation!  Request a free 30-day trial (full version) of our popular Alliance AES Encryption and see for yourself.

IBM introduced the DB2 Field Procedures (FieldProc) column level encryption interface in V7R1 of the operating system. It has been a great way for IBM i (iSeries, AS/400) customers to protect sensitive data in their DB2 for i files and tables, but customers often have questions about how this new capability works. One of the most common questions is “Can I encrypt index fields and will they work correctly?”

The answer to the first part of the question is YES you can encrypt index fields, and the answer to the second part of the question is THAT DEPENDS. Let’s take a deeper look at encrypted indexes with FieldProc.

First, let’s look at DB2 FieldProc strictly from a SQL point of view. Remember that SQL is IBM’s preferred interface to the DB2 relational database. So let’s start there:

The first thing to understand is that FieldProc is fundamentally a SQL construct. That is, it is designed for and implemented as a SQL facility. You can specify a FieldProc program on the SQL CREATE TABLE or ALTER TABLE commands, but you can’t specify FieldProc on traditional DDS source descriptions. FieldProc works great on index fields in your SQL applications! Your SQL statements will work just as you would hope and you will have a great new facility for implementing automatic encryption. With very few limitations you will find that encrypted indexes work without any issues for your SQL applications. I’ve rarely found a customer who was unhappy with IBM’s implementation of FieldProc in native SQL applications. This includes SQLRPG applications that use native SQL for the database interface.

But, of course, most IBM i customers are running a lot of legacy RPG or COBOL applications that do not use SQL. And this is where there are some significant restrictions on encrypted indexes.

First, you CAN use FieldProc on traditional database files created with DDS. It is not necessary to convert the database files to SQL in order to use FieldProc. Of course, FieldProc application support is installed using SQL statements, but they will work on traditional DDS created files with some minor limitations. So this part is not complicated.

Next, you CAN encrypt indexes that are created with DDS. However, you do have some significant limitations when using FieldProc with DDS files. For example, some join logical files that join on encrypted index fields will not work. You simply won’t be able to create join logical files that link using fields encrypted under FieldProc.

A more fundamental problem is that legacy RPG and COBOL applications will not work correctly with most encrypted indexes. Since the legacy file interface is not SQL, the legacy applications will not work as expected in many cases. For example, it is very common to use the Set Lower Limits (SETLL) command with the Read (READ) command to read a range of values in a table. In these legacy applications the SETLL value will be converted to the encrypted value by FieldProc, and then the next record will be read using the encrypted key value. But encrypted values will not be in the same order as the original plaintext values. This will lead to empty subfiles and empty or incorrect information on reports.

For many IBM i customers the limitations on encrypted indexes are not a big problem and they live with them. For many others encrypted indexes with legacy RPG applications is a significant problem that will make the use of FieldProc impossible.

Is there a solution for this problem? Well, of course you can convert all of your legacy databases and applications to SQL databases and SQL RPG applications, or even to native SQL applications. But this represents a major investment by many customers. But there is an alternative provided in the Open Access for RPG (OAR) implementation by IBM.

The Open Access for RPG implementation allows you to define a handler for file operations using one F specification in your RPG program. With this implementation the legacy file operations are handled by your new handler application. And that can be a set of SQL functions! This means that a legacy RPG program can become enabled for true SQL operations with a simple change and re-compile of the application. Of course, you must have the SQL handler functions ready to take over the file operations. I won’t go into creating SQL handlers in this blog, but be aware that creating SQL handlers is not for the faint of heart. You need to have extensive experience with SQL and understand the OAR architecture. If you’ve not done this before the IBM Lab Services team can provide assistance.

In summary, FieldProc is a great new facility and it is already helping a lot of IBM i DB2 customers to protect data with strong encryption. It works great with native SQL applications, but you need to be aware of some limitations when used with legacy RPG and COBOL applications.

Our Alliance AES/400 solution provides everything you need to implement FieldProc. 

Here is a sneak peek at the introduction for the latest regulatory guidance white paper from Townsend Security. For detailed information, download the entire document:

On March 25, 2014, the Article 29 Data Protection Working Party of the European Union issued new guidance on data breach notification and the use of data protection technologies such as encryption and encryption key management. Extending beyond just Internet Service Providers, the new regulations cover all organizations that process, store, or transmit private information of EU citizens. Along with these new regulations, there are substantial financial penalties for failing to protect sensitive information. These penalties can reach into the 10’s of millions of Euros depending on the organization’s size and amount of data compromised.

The European Union does not mandate that all organizations immediately encrypt sensitive data, but the only exclusion for subject data breach notification and financial penalties will be for those organizations who use encryption and other security methods to protect the data. Applying these security methods after a breach will not remove the notification requirements and penalties.

EU Data Protection Directive (also known as Directive 95/46/EC) is a directive adopted by the European Union designed to protect the privacy and protection of all personal data collected for or about citizens of the EU, especially as it relates to processing, using, or exchanging such data. The following guidelines will help meet these new EU objectives:

Encrypt Data at Rest

Make a full inventory of all sensitive personal information that you collect and store. Use strong encryption to protect this data on servers, PCs, laptops, tablets, mobile devices, and on backups. Personal data should always be encrypted as it flows through your systems, and when you transmit it to outside organizations.

Use Industry Standard Encryption

Use industry standard encryption such as Advanced Encryption Standard (AES, also known as Rijndael). AES is recognized world-wide as the leading standard for data encryption. Never use home-grown or non-standard encryption algorithms.

Use Strong Encryption Keys

Always use cryptographically secure 128-bit and 256- bit AES encryption keys and never use passwords as encryption keys or the basis for creating encryption keys. Encryption keys based on passwords will never meet minimum standards for strong encryption keys. Keys should be generated using a cryptographically secure random bit generator (CS-RBG) validated to international standards.

Protect Encryption Keys from Loss

Encryption keys must be stored away from the data they protect and must be securely managed. Manual procedures cannot accomplish the goal of proper encryption key management. Use a professional encryption key management solution to protect keys and provide different keys for different data protection needs. Key management solutions should implement key creation, management, and distribution and be compliant with the NIST FIPS 140-2 standard recognized and accepted worldwide.

Change Encryption Keys Regularly

Using one encryption key for a long period of time can expose you to a breach notification for historical data. Change your encryption keys on a quarterly or semi-annual basis. A good key management solution can automatically change encryption keys at an interval you define.

Use Strong, Industry Standard Hash Algorithms

Use strong, industry standard secure hash algorithms when protecting passwords and other information. Never use MD5 or other weaker hash methods. Use the SHA-256 or SHA-512 methods for your hash requirements.

Use Keys or Salt with Your Hashes

When using a strong secure hash algorithm, always use an encryption key or random salt to strengthen the resulting hash value. You can use the Hashed Message Authentication Code (HMAC) method with an encryption key or use a strong encryption key under the protection of a key manager as the salt for the hash method.

For details on the EU Data Protection Directive...

The time required to crack an encryption algorithm is directly related to the length of the key used to secure the data.

Every now and then, our development team comes across someone still using antiquated DES for encryption.  If you haven’t made the switch to the Advanced Encryption Standard (AES), let’s take a look at the two standards and see why you should!

Data Encryption Standard (DES):

DES is a symmetric block cipher (shared secret key), with a key length of 56-bits. Published as the Federal Information Processing Standards (FIPS) 46 standard in 1977, DES was officially withdrawn in 2005 [although NIST has approved Triple DES (3DES) through 2030 for sensitive government information].

The federal government originally developed DES encryption over 35 years ago to provide cryptographic security for all government communications. The idea was to ensure government systems all used the same, secure standard to facilitate interconnectivity.

To show that the DES was inadequate and should not be used in important systems anymore, a series of challenges were sponsored to see how long it would take to decrypt a message. Two organizations played key roles in breaking DES: distributed.net and the Electronic Frontier Foundation (EFF).

• The DES I contest (1997) took 84 days to use a brute force attack to break the encrypted message.
• In 1998, there were two DES II challenges issued. The first challenge took just over a month and the decrypted text was "The unknown message is: Many hands make light work". The second challenge took less than three days, with the plaintext message "It's time for those 128-, 192-, and 256-bit keys".
• The final DES III challenge in early 1999 only took 22 hours and 15 minutes. Electronic Frontier Foundation's Deep Crack computer (built for less than $250,000) and distributed.net's computing network found the 56-bit DES key, deciphered the message, and they (EFF & distributed.net) won the contest. The decrypted message read "See you in Rome (Second AES Candidate Conference, March 22-23, 1999)", and was found after checking about 30 percent of the key space...Finally proving that DES belonged to the past.

Even Triple DES (3DES), a way of using DES encryption three times, proved ineffective against brute force attacks (in addition to slowing down the process substantially).

Advanced Encryption Standard (AES):

Published as a FIPS 197 standard in 2001. AES data encryption is a more mathematically efficient and elegant cryptographic algorithm, but its main strength rests in the option for various key lengths. AES allows you to choose a 128-bit, 192-bit or 256-bit key, making it exponentially stronger than the 56-bit key of DES. In terms of structure, DES uses the Feistel network which divides the block into two halves before going through the encryption steps. AES on the other hand, uses permutation-substitution, which involves a series of substitution and permutation steps to create the encrypted block. The original DES designers made a great contribution to data security, but one could say that the aggregate effort of cryptographers for the AES algorithm has been far greater.

One of the original requirements by the National Institute of Standards and Technology (NIST) for the replacement algorithm was that it had to be efficient both in software and hardware implementations (DES was originally practical only in hardware implementations). Java and C reference implementations were used to do performance analysis of the algorithms. AES was chosen through an open competition with 15 candidates from as many research teams around the world, and the total amount of resources allocated to that process was tremendous. Finally, in October 2000, a NIST press release announced the selection of Rijndael as the proposed Advanced Encryption Standard (AES).

Comparing DES and AES

	DES	AES
Developed	1977	2000
Key Length	56 bits	128, 192, or 256 bits
Cipher Type	Symmetric block cipher	Symmetric block cipher
Block Size	64 bits	128 bits
Security	Proven inadequate	Considered secure

So the question remains for anyone still using DES encryption…
How can we help you make the switch to AES?

In the world of encryption there are many different names for encryption, but probably the two most common would have to be AES and PGP. But not everyone knows what these acronyms stand for. In today’s world of TLAs (Three Letter Acronyms) it’s easy to feel left behind in a data security conversation when they start replacing every other word. OMG!

First we’ll break both of them down a bit and then we’ll compare them to each other.

AES, or Advanced Encryption Standard, as we know it today is the dreamchild of two cryptographers’ proposal of a symmetric key encryption algorithm based on the Rijndael cipher. This algorithm was developed when NIST (National Institute of Standards and Technology) sent the call out to the cryptographic community to develop a new standard. NIST spent five years evaluating fifteen competing designs for the AES project and in 2001 announced the cipher developed by the two Belgians Joan Daemen and Vincent Rijmen as the adopted standard, known as FIPS-197, for electronic data encryption.

AES is a symmetric key encryption algorithm, which essentially means that the same key is used for the encryption and decryption of the data. A computer program takes clear text and processes it through an encryption key and returns ciphertext. If the data needs to be decrypted, the program processes it again with the same key and is able to reproduce the clear text. This method required less computational resources for the program to complete its cipher process, which means lower performance impact. AES encryption is a good method to protect sensitive data stored in large databases.

There is, however, a time when AES will not be your go-to encryption process. When you need to share sensitive information with trading partners or transfer information across networks, using AES has one downside when it comes to security: You would have to share your encryption key with your trading partners. Sure, they’d be able to decrypt the information you sent them, but they would also be able to decrypt anything else encrypted with that key, and if the key itself became compromised anyone in possession of it could decrypt your data.

Enter PGP. PGP stands for Pretty Good Privacy, and before you get too distracted by the name, I can tell you it is actually much better than just pretty good. PGP uses symmetric and  asymmetric keys to encrypt data being transferred across networks. It was developed by the American computer scientist Phil Zimmerman, who made it available for non-commercial use for no charge in 1991. To encrypt data, PGP generates a symmetric key to encrypt data which is protected by the asymmetric key. 

Asymmetric encryption uses two different keys for the encryption and decryption processes of sensitive information. Both keys are derived from one another and created at the same time. They are divided into and referred to as a public and a private key, which makes up the key pair. Data is only encrypted with a public key and thus can only be decrypted with the matching private key. The encryption PGP offers is just as strong as that of AES, but it adds the additional security that prevents anyone with just the public key from being able to decrypt data that was previously encrypted with it. Another benefit of asymmetric encryption is that it allows for authentication. After you have exchanged public keys with your trading partners, the private keys can be used to digitally sign the encrypted content, allowing the decryptor to verify the authenticity of the sender.

PGP does require more computational resources, which is why it is usually not recommended for encrypting data in large databases where information needs to be accessed frequently, and each record that you access needs to be ran through a cryptographic process.

When you are considering which encryption to use for your sensitive information choose whichever will suit your needs best. AES is fast and works best in closed systems and large databases; PGP should be used when sharing information across an open network, but it can be slower and works better for individual files.

 

AES Encryption & Related Concepts Download the white paper "AES Encryption & Related Concepts" Click Here to Download Now

Today, nearly every business needs to meet at least one set of data security compliance regulations, if not more. Regulations such as PCI-DSS, HIPAA-HITECH, and GLBA/FFIEC recommend if not outright require companies collecting sensitive data to secure that data using encryption and encryption key management. Most solution integrators are aware of this, but they may not know what to look for in a third party key management vendor to partner with.

The key management vendor you chose to partner with should provide you with all services you need to integrate key management into your solution easily. If you're a solution integrator, a third party key management vendor should provide you with:

1. Technology. Does your key management partner provide you with all of adequate hardware, software, encryption libraries, and tools you need to easily deploy encryption and key management on your customers' networks?

2. Certifications. Certifications are crucial to meeting government and industry data security requirements. Is your key management partner’s solution FIPS 140-2 certified? What is the certificate number? Do they use NIST-certified AES encryption?

3. Training. Does your partner provide you with adequate training to tools such as walk-through instruction and training videos to help you implement encryption key management with ease?

4. Platform Compatibility. Does your partner support all of your customers' legacy platforms such as IBM, Microsoft, or Oracle, including newer and older versions?

5. Client Side Support. Does your partner supply you with all of the sample code, binary libraries, applications, key retrieval and other tools you need to implement encryption and key management fast and easily? Do they charge client-side licenses? (Note: Townsend Security never charges for client-side support.)

6. Marketing Collateral. Does your partner provide you with strong sales and marketing material to help you promote and provide credibility to the product?

7. Knowledge of Compliance Regulations. Does your partner know how their solutions will help your customers meet compliance regulations such as PCI-DSS, HIPAA-HITECH, and GLBA/FFIEC?

8. Virtual and Cloud Environment Capabilities. Your customers may be storing their data "in-house", but if they want to move to the cloud, can your key management partner  move with them?

9. Scalable Solutions. Many customers of SIs are small and medium sized businesses with the same data security needs as larger enterprises. Can your key management scale to meet the needs of the SMB market?

10. A Supportive Business Relationship. Does your partner understand your competitive and pricing challenges? Will your partner work with you to craft a solution that will keep your price competitive, or will they just give you a price and walk away?

11. A Win-Win relationship. Will the partnership create new business and generate new revenue for both parties?

Townsend Security is a third party encryption and key management provider of NIST-certified AES encryption and and FIPS 140-2 certified key management systems. With over 25 years of experience helping companies protect data and meet compliance requirements, Townsend Security can help you do the same.

To learn more about partnering with Townsend Security, contact us now. To learn more about AES Encryption and encryption key management, download our White Paper  "AES Encryption and Related Concepts."

IBM announced recently the end of support date for V5R4. This has prompted many IBM i shops running this older OS to upgrade to a newer release - either V6R1 or V7R1. Traditionally, we have seen that most IBM i administrators upgrade just one release forward. In this particular case, we recommend going to V7R1. Not only is upgrading to V7R1 a fully supported path by IBM, there are security reasons. I recently sat down with Patrick Townsend, Founder & CEO, to discuss IBM i V7R1 and how Townsend Security can help organizations take advantage of FIELDPROC, a new feature that allows companies to encrypt their sensitive data without changing their applications.

You said recently that upgrading your IBM i to V6R1 is a bad idea. Can you explain why?

Security today is more important than it was even two or three years ago. We live in an evolving world around security and organizations of every size - from small companies to global companies - really have been under severe attack. The bad guys are getting much better at what they do and we are faced with highly sophisticated attacks. Even mid-sized companies are now under pressure to protect their data. So we live in a world that is far more sensitive and insecure, and we really have to put more attention on protecting sensitive data.

IBM gave us FIELDPROC in the latest release of the operating system (V7R1), which allows encryption with no application changes. FIELDPROC is really attractive for mid-sized and large customers. It makes the usually very difficult task of encrypting data in our systems much easier. I think that customers who are on older versions of the operating system (V5R4, for example) and who might in the past have just moved up one level, should really move up to V7R1. From a security perspective, it is time to jump a level from V5R3 or V5R4, past V6R1, which would be the next release, to V7R1 and get the benefits of FIELDPROC encryption.

What would an organization need to do to take advantage of FIELDPROC once they upgrade? They still need third-party encryption, right?

Yes, FIELDPROC is the ability to do encryption, but IBM relies on third-party vendors like us to actually provide the encryption libraries and appropriate encryption key management. When customers deploy our FIELDPROC encryption solution on V7R1, they are getting our NIST-certified encryption libraries, as well as seamless integration with Alliance Key Manager, our encryption key manager. Alliance Key Manager is FIPS140-2 certified, and when used with our encryption, lines up perfectly with best practices for encryption across all compliance regulations. Whether it is PCI/DSS with Credit Cards, HIPAA/HITECH in the Healthcare industry, FFIEC in the financial industry, DICAP if you are a civilian company working with the federal government, or if you are a federal agency where it is a mandate that you must have a FIPS140-2 solution.

Our FIELDPROC solution installs into an IBM i customer’s environment, provides both our optimized and certified AES encryption libraries, and the key management you need to be compliant. IBM has done the hard work of making this capability available and we do the work of snapping in proper encryption and key management.

Download a free 30-day evaluation of our Alliance AES/400 encryption, built specifically for IBM i V7R1. Alliance AES/400 is the only NIST-certified FIELDPROC encryption available.

As the social revolution moves into the business world, protecting your data is more important than ever.  This was a key takeaway for attendees of the recent “Dreamforce to You” event in Seattle, WA, hosted by Salesforce.

Similar, yet smaller in scale to the Dreamforce conference held annually in San Francisco, this event brought together sales and marketing professionals who use Salesforce.com (a cloud-based Customer Relationship Manager) to see what is new with the CRM, how it can help you do your job better, as well as allow attendees to network with peers.  Additionally, Peter Coffee, an IT visionary who acts as the VP and Head of Platform Research at Salesforce.com, delivered an inspirational keynote titled “Toward the Social Enterprise: Trust; Vision; Revolution”.

The focus of both Dreamforce and “Dreamforce to You” is that by and large  business is embracing the social revolution.  Whether you are Bank of America and helping your customers find the nearest ATM or are collaborating with co-workers internally using social tools, businesses are migrating to the social world.  During the keynote, Peter Coffee presented a slide titled “Social is a model, not an app.”  By being social, businesses are able to work more efficiently and reach more customers in ways that were never thought possible.  “Salesforce is not just using social tools but instead is driven and formed by the social network.”

As Peter Coffee continued to discuss cloud computing, the future of IT platforms, and how businesses are “going social”, he conveyed a key concept – companies need to protect their sensitive information.  

We couldn’t agree more.  As a security company, this is something we have been saying since the beginning.  We have offered NIST-validated AES encryption for all the major enterprise platforms for over ten years, been securing managed file transfers with PGP encryption, and recently stepped up our game with a FIPS 140-2 compliant encryption key management HSM.  Simply put, we are helping organizations protect their sensitive information and meet compliance regulations with certified encryption solutions.

Occasionally we hear “I don’t need encryption, nothing can get inside my network” (De-Perimeterization concept). The truth is, no matter how many of the latest and greatest network security devices you implement, there is still nothing as fail-safe as properly encrypting your data.  As keynote speaker Peter Coffee would say about investing in the wrong technology, “doing it better is still doing the wrong thing.”

For more information on data privacy, download our podcast Data Privacy for the Non-Technical Person.  Patrick Townsend, our Founder & CTO, discusses what PII (personally identifiable information) is, what the most effective methods for protecting PII, as well as the first steps your company should take towards establishing a data privacy strategy.