THE ESSENTIAL GUIDE TO

BY CAROL WOODBURY APRIL 2006

RIVEN BY REGULATORY COMPLIANCE issues and the ever-growing threat of compromised private data, more and more organizations are starting encryption projects. When done right, encryption can add an excellent layer of defense on top of the good access controls already protecting your data. Before you jump right into the implementation phase of your encryption project, lets look at the most critical part understanding the purpose and the scope of the project. An encryption project, particularly one involving the encryption of fields in database files, is not a trivial undertaking. Its critical that you plan and design it properly. Understand the Purpose of Your Project If you want to keep your data secure, simply encrypting it will probably not achieve your goal (well discuss this in more detail later). If your goal is to comply with a regulation such as the Payment Card Industry (PCI) Data Security Standard, then you must carefully read and understand its requirements. The PCI Data Security Standard has detailed encryption requirements and sets the expectations of what PCI auditors will look for in your implementation. If you are encrypting to satisfy a law (such as the notification laws that have recently sprung up in numerous states), I recommend that you design your implementation as though you were meeting a standard such as PCIs. Most states notification laws do not provide details about the type or strength of encryption required; rather, they simply exempt the entity from having to notify individuals if the breached data was encrypted. You might as well implement

a strong encryption scheme with strong key management processes in case the laws change and start specifying strict requirements (or your business changes, and you suddenly find yourself having to comply with a strict law or regulation). In other words, if youre going to the trouble of implementing encryption, you might as well do it right. For a list of encryption resources, see Find Out More, on page 3. Identify the Scope of Your Project The first step in identifying the scope of your encryption project is to determine what data you are going to encrypt. This decision is not one that should be made in a vacuum in other words, what data gets encrypted should not be the sole decision of the IT administrator or programmer in charge of the project. The decision needs to be made with the help of the data owners and possibly your organizations legal counsel. Why? Because no single person is aware of all of the regulations that determine what constitutes private data, of the laws and regulations that govern protection of private data, of the ramifications of not protecting the data or having the data compromised, and of all the places where the data is stored and how it is used. To do this project right, you need input from numerous individuals from around your organization. Only after you gather this input can you know the true scope of your project and decide how to proceed. Lets look at the steps you need to determine the scope of your project. Step 1 Determine the type of data to be encrypted. The laws and regulations with which your organization must comply might dictate the type of data you must

SUPPLEMENT TO iSeries NEWS 2006

SUPPLEMENT TO iSeries NEWS 2006

THE ESSENTIAL GUIDE TO ENCRYPTION

encrypt. For example, if your organization stores credit card numbers, the PCI Data Security Standard dictates the type of data to encrypt. If youre storing protected electronic healthcare information, then HIPAA dictates the data to encrypt especially when data is being transmitted. In other cases, your organization might be doing business with a company that has encryption requirements to fulfill its service agreement. Finally, the datas owners might determine that their data must be encrypted. Step 2 Determine where the data is stored. Determining the type of data to encrypt is the easy step. A more difficult task is determining all and I do mean all of the places where the data resides. Without fail, private or confidential data resides in more places than one first imagines. To ensure that this list is complete, you will probably need to assemble a group of programmers, system administrators, database owners (such as the lead HR administrator), database administrators, system analysts, and even representatives from your third-party software vendors. In making this list of all data occurrences, remember the private information that resides in spooled files, outfiles, query files, text files, stream files, and printed reports. Also make note of databases replicated to high availability (HA) machines, databases residing on development machines (including copies of the production database made into developers libraries), logical files that include the fields to be encrypted, and data residing on network servers and desktop applications (e.g., Excel spreadsheets). After listing all the places where the private data resides, examine each instance to determine whether the private data is actually required or can be eliminated for that specific instance. In many cases, you can significantly reduce the scope of your project (as well as the exposure to your organizations private data) if you dont store the private data on servers, disallow it to be included in queries, create a logical file that does not contain the fields with private data, and eliminate the private data from printed reports and Excel spreadsheets. Often, the data is included in these places simply because its part of the information in the original file structure, not because its actually necessary. Or, perhaps the data has only recently come to be considered susceptible to abuse at one time, information such as Social Security numbers were not considered to be sensitive. Oh, how times have changed! For example, do credit card numbers really need to be included on a printed report of all returns to a store if the person viewing the report is interested only in whats being returned and the reason for the return? No, they dont. Viewing credit card information is not part of this persons job function, and therefore it should be removed from the report. And without question, removing the credit card number from the report is much easier than adding logic to the application to allow this individual to see decrypted data. It also eliminates the problems of putting appropriate

FIND OUT MORE

iSeries NEWS articles at iSeriesNetwork.com Accessing V5R2 Cryptographic Services APIs from RPG (article ID 20374) APIs by Example: Cryptographic Services APIs, Parts 14 (article IDs 51236, 51786, 51863, and 51962) Cryptographic Services APIs: A Tutorial (article ID 20312) Triple-DES Encryption from RPG (article ID 51211) Other Resources Applied Cryptography: Protocols, Algorithms, and Source Code in C Wiley, 1995. ISBN: 0471117099 Cryptography for Dummies For Dummies, 2004. ISBN: 0764541889 Cryptography Decrypted Addison-Wesley Professional, 2000. ISBN: 0201616475 Cryptographic Toolkit from the National Institute of Standards and Technology (NIST) csrc.nist.gov/CryptoToolkit NISTs recommendations for key management (direct link to .pdf) csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf Official (ISC)2 Guide to the CISSP Exam, Chapter 6 AUERBACH, 2003. ISBN: 084931707X Payment Card Industry (PCI) Data Security Standard usa.visa.com/business/accepting_visa/ops_risk_management/cisp.html?ep=v_sym_cisp Practical Cryptography Wiley, 2003. ISBN: 0471223573 Sans Organization sans.org

SUPPLEMENT TO iSeries NEWS 2006

THE ESSENTIAL GUIDE TO ENCRYPTION

access controls on the file, adding routines to encrypt the credit card number, and dealing with the proper disposal (shredding) of the printed reports. Step 3 Determine how the information is being used. This step, while easier than step 2, still usually takes an assembly of individuals to complete. You want to understand how the data is being used so you can determine the type of encryption thats required. For example, if the data is a Social Information number (in Canada) or a drivers license number used only for verification purposes, you can likely store it in a one-way hash. A hash cannot return the original data; it is one way only. For that reason, hashing private data is much easier to implement and even more important more secure than implementing more complex encryption algorithms that allow decryption of data. To ensure encryption provides an additional layer of protection on top of the access controls you have on the files containing your data, you will want limit the scenarios for which the data must be decrypted. For example, if the data is being sent to a bank for transaction processing or to a clearinghouse for verification, it is likely that clear text data is required. For this scenario, you will have to determine how and when to decrypt the data so that the data is in clear text for as short a time as possible. Also, as soon as the clear text data has been transmitted over an encrypted session, it will need to be removed or cleared as soon as possible. Types of Encryption Dont worry, Im not going to get into a full dissertation on encryption algorithms. But as you start to read about encryption and do further investigation for your encryption project, you will hear about various algorithms, and you might find a quick explanation helpful. Generally speaking, there are three types of encryption algorithms (Figure 1). Symmetric key algorithms use the same key to both encrypt and decrypt data. They are generally faster than asymmetric key algorithms and are often used to encrypt large blocks of data. Algorithms youll hear mentioned include Data Encryption Standard (DES), Triple DES, RC5, and Advanced Encryption Standard (AES) the standard for the U.S. government. Asymmetric key algorithms use one key to do one function and another key to do the opposite function. In other words, the same key cannot be used to both encrypt

Figure 1: Types of encryption

SUPPLEMENT TO iSeries NEWS 2006

THE ESSENTIAL GUIDE TO ENCRYPTION

and decrypt the data. These algorithms are typically used for authentication; for example, they are used during an SSL handshake to verify that the client knows the server to which its trying to connect. Asymmetric key algorithm types include Rivest-Shamir-Adlem (RSA) and Elliptic Curve. Hash algorithms produce a result that cannot be decrypted. They are typically used for the comparison of two values to ensure they are the same. For example, the verification of a digital signature uses a hash function to ensure that the signed document has not been altered. Because a hashed value cannot return the original value, this method provides the most secure form of storing data and is the most appropriate method when the original form is not required. Message-Digest algorithm 5 (MD5) and Secure Hash Algorithm (SHA-1) are two examples of hash algorithms. What Are the Challenges? Transmitting encrypted cardholder data isnt a challenge for most shops; theyre already doing it either through the functions provided by i5/OS (e.g., https, secure FTP) or through a vendor solution. Some organizations are deciding that encrypting their backup media is a requirement. Although this poses some interesting challenges, the bigger challenge for most organizations is the requirement to encrypt private data residing in database files. This brings up several issues the implementation will most likely require some redesigning of the database, you must determine how to securely store and manage the encryption keys so that only the appropriate people have access to them, and you must plan how to handle the new disaster recovery issues that encryption presents. The online version of this Essential Guide contains a discussion of key management issues. The Key Is Key Management I cannot emphasize enough that without solid key management, your encryption project will likely be a disaster and provide absolutely no additional security to your data. Consider these best practices for key management. Separation of duties. The same person should not create the keys, use the keys (write programs to use the keys for encryption or decryption), and act as the custodian of the keys. For large shops, this should not be an issue, but for small iSeries shops, it may present a challenge. Either way, you must be prepared to explain your separation of key management duties to any auditor who asks. Creating the keys. Creating strong encryption keys hinges on seeding the key generation algorithm with a totally random number. You might think just typing in some number will suffice after all, it looks random to you, right? But studies have shown that people type in a certain pattern; in reality, the key is not random but a manifestation of the persons typing pattern. Therefore, your data is weakly encrypted, allowing hackers to easily decrypt it using dubious methods. Word to the wise use a formal random number generator to obtain the seed for your key generation system. Changing the keys. You must also be prepared to explain to auditors your process for changing keys. If a breach occurs or you become aware that the encryption key has been compromised, you will need to decrypt the data and reencrypt it using a different key. You will want to carefully plan and then document your procedure for accomplishing this task. Best practices also state that keys regardless of whether they have been compromised should be changed every year or two. The exception to this rule is when theres a good chance of compromising the data by decrypting and reencrypting it rather than leaving it encrypted with an old key. Whether or not you change keys regularly, you need to establish and document a policy reflecting your key management change practices. Storing the keys. Appropriate placement and access control of stored keys is vital. Many people think they need to keep their encryption algorithm a secret, but the secret that must be kept is the key itself. Therefore, storing keys in clear text in the program source or in a data area is a bad idea. One choice is to use a validation list for secure storage of keys (by the time you read this, V5R4 will be released, and it provides some integrated key management features). Validation lists provide a method for storing and encrypting small amounts of data, such as encryption keys. Another choice is to use a vendor product that provides key management with the vendors product offering. Controlling access to the keys and encryption/decryption routines. Without strong access controls (that is, object security) on the keys and encryption routines (especially the decryption routine), you get no additional security benefit by encrypting the data. If anyone on the system has access to the decryption key, whats the point? In addition, you must realize that you cannot protect your encrypted data from being decrypted by an *ALLOBJ user. Remember, users with *ALLOBJ special authority can access any object on the system (this is why I prefer to use hashes whenever possible). The best you can do to ward off access by *ALLOBJ users is to throw up some roadblocks to make it more difficult to run the encryption routine, and thus discourage them from trying to decrypt the data. One such roadblock is to query the process to see whether its running with *ALLOBJ, and if it is, reject the request. Another is to check the program calling the decryption routine and decrypt only if the calling program is in an approved list. But understand no method is a perfect prevention mechanism against abuse by an *ALLOBJ user. Now lets look at the issues surrounding the two methods people are currently most interested in encrypting backups and encrypting a field in a database file. Encrypting Backup Media Two popular methods exist for encrypting backup media. One is to first save the data to a save file (*SAVF), encrypt

SUPPLEMENT TO iSeries NEWS 2006

THE ESSENTIAL GUIDE TO ENCRYPTION

the *SAVF, and then save the encrypted *SAVF to the media. This method requires that you have storage available for the *SAVF. Depending on how much data is being saved, this approach can use a significant amount of storage, which will present problems on some systems. The other method is a hardware solution in which the device performs the encryption before the data is written to media. This technique removes the requirement for the intermediate save file. Rather than encrypt data on the media, some people use compression software. Compression software reduces the space required for the backup data and produces what I call mangled data. While mangled data is not easily read, it is not the same as encrypted data, and it may not meet the requirements of the laws or regulations with which you need to comply. Make sure to take this into account when considering this option. Whichever method you choose, you should determine how key management will be performed and develop a procedure for retrieving the key when data needs to be restored to the system. You must also determine the impact on your disaster recovery plan, then update your disaster recovery plan to include the procedure for recovering the keys, as well as account for any new hardware requirements for hot site locations. Although its not a security issue, you will also want to look at the performance impact of encrypting backups and the subsequent impact on your system operators schedules. Encrypting a Field in a Database File IBM provides several options for encrypting data in a database field. The most rudimentary one (but the only one provided before V5R2) is coding to the CIPHER machine instruction. If you are running V5R3, APIs are integrated into i5/OS that provide software encryption functionality. A subset of this function is available via PTFs in V5R2. Finally, for the most secure method, as well as the most complex, you can install a FIPS-compliant hardware cryptographic coprocessor card and write to the APIs provided. The crypto card is the only IBM solution that provides encryption key management features prior to V5R4. You can find documentation for all of these encryption methods in IBMs Information Center (publib.boulder. ibm.com/iseries). However, writing to these interfaces yourself without some knowledge of encryption methodology will result in a less-than-optimal implementation. Another IBM solution is to use the SQL ENCRYPT_RC2 keyword, but I dont recommend this method. Remote database access requires that the key be passed in clear text. Because of this and other issues, its doubtful that using this keyword will provide an implementation that will pass any type of regulatory compliance. Several vendors also provide solutions for database encryption. When investigating these solutions, make sure you understand their key management capabilities to ensure they meet your project requirements. Whatever method you choose, some amount of redesigning may be required. The ideal solution is to redesign your application and move each type of private data into its own database (e.g., one for cardholder data, another for HR data). This method makes it much easier to ensure the encryption/decryption functions are called only when necessary, which helps keep the data secure. It also helps minimize the effect of encryption on system performance because the data is decrypted only when necessary, not on every file open. Additionally, you are in a much better position to respond quickly should the encryption requirements change in the future. If moving the data to another file is not an option, you will most likely have to declare a new field for the encrypted value because the encrypted value is almost always significantly larger than the original value. Once the encrypted field is populated, youll have to take steps to neutralize or otherwise wipe out the clear text version of the private data currently residing in the file. Again, you need to restrict when the data is being decrypted. Using a trigger program that blindly decrypts the data whenever the file is opened defeats most if not all benefits gained by encrypting the data. Make sure that when you implement your decryption scheme, it is invoked only when the clear text data is required. Disaster Recovery Considerations When planning your encryption project, remember to take into account the impact on your disaster recovery plans. If the media is encrypted, youll need to make the keys available at your alternate location so that media can be read and data restored. If you used a hardware encryption method (for either encrypted backups or encrypting data in database files), the same hardware must also be available at your recovery site. Finally, when encrypting data while its being transmitted, make sure that you have the appropriate digital certificates installed in your servers or VPN configurations. Success Depends on Planning An encryption project should not be taken lightly. It takes significant planning and a well-designed implementation to ensure success. Determining the regulatory issues with which you must comply as well as the scope of your project are keys to your projects success. This information will help you decide whether to implement one of the options from IBM or to evaluate vendor solutions.

About the Author

Carol Woodbury is cofounder of SkyView Partners, Inc., a firm specializing in security compliance management and assessment software as well as security services. Carol is the former chief security architect for AS/400 for IBM in Rochester, Minnesota, and has specialized in security architecture, design, and consulting for more than 15 years. Carol speaks around the world on a variety of security topics and is coauthor of Experts Guide to OS/400 and i5/OS Security (29th Street Press, 2004). E-mail Carol at carol.woodbury@skyviewpartners.com.

SUPPLEMENT TO iSeries NEWS 2006

SUPPLEMENT TO iSeries NEWS 2006