Why Disk Level Encryption is Not Enough for Your IBM i
Download as PPTX, PDF0 likes66 views
The document discusses the importance of encryption for protecting sensitive data and compares different encryption strategies, emphasizing the benefits of field-level encryption over disk-level encryption on IBM i systems. Field-level encryption allows for individual key management and data masking, which enhances security compared to disk-level encryption that relies on a single key for all data. Additionally, it outlines best practices for key management and considerations for system performance and compatibility with legacy programs.
Why Disk Level Encryption is Not Enough for Your IBM i
- 1. Why Disk-Level Encryption is not enough for Your IBM i Bill Peedle | Principal Sales Engineer
- 2. Today’s Topics • Benefits of encryption • Comparing encryption strategies • Field-level encryption on IBM I • Additional considerations • How Precisely can help 2
- 3. Why use encryption at all? 3 • Applications frequently use and store sensitive data such as confidential personal details, payment information, or proprietary data. • In some jurisdictions, this type of data is subject to governance, privacy, and security compliance mandates. • Unauthorized access of sensitive data or a failure to comply with a mandate often results in significant reputation damage and financial penalties. • Therefore, it is important to keep sensitive data secure to protect your corporate data from unauthorized access.
- 4. Protect your stored data with AES Encryption • The US government and agencies have accepted the Advanced Encryption Standard (AES) as a format standard (FIPS -197) for encrypting data in databases. • For PCI-DSS, HIPAA, and specific government privacy rules, AES is the preferred encryption method. • The encryption methods recognized by the National Institute of Standards and Technology (NIST) ensure that your data is protected to the highest standards. 4
- 5. 5 Protect your encryption keys and data by keeping them separate If you keep your encrypted data and keys in the same place, it’s like placing your house key beneath the mat Security best practices require you to store encryption keys separately from your encrypted data and manage them with an encryption key manager
- 6. What is a key management server? 6 When encrypting fields in a file, an encryption key is required • Many customers use an external key manager to store and manage the master key as well as the encryption keys for the individual fields. • They may already have an external key manager for other platforms and can leverage that server for the IBM i encryption as well. • An example of an external key server would be Thales Cipher trust or Alliance Key Manager. There are others as well. • For those who do not want to support an external key manager on a Windows or Linux server, a local key store can be used on the IBM i to store and manage the keys. Third party encryption tools typically include a local key store for this use case.
- 8. What is disk level encryption? 8 • On the IBM i, full disk encryption allows you to encrypt data that is stored in basic disk pools and independent disk pools • Full disk encryption protects data from several different threats: • Protects data transmission to and from the disk drive (important in a SAN environment) • Protects data transmission in the cross-site mirroring environment (only when the data being mirrored is on an encrypted independent disk pool) • Protects data in the case of theft of the disk drive
- 9. 9 What is field level encryption? • Field procedures can provide field level (or column level) encryption on DB2 for IBM i • A field procedure is a user-written exit routine to transform values in a single column • When values in the column are changed, or new values inserted, the field procedure is invoked for each value • The field procedure can transform values (encode it) in any way. • The encoded value is then stored • When values are retrieved from the column, the field procedure is invoked for each encoded value. • The field procedure decodes each value back to the original value. • Any indexes defined on a column that uses a field procedure are built with encoded values. • The fields are encrypted at rest and will be decrypted when a database operation is performed against the file that has the field in it. • Fields can be ”masked” based on specific users or groups.
- 10. What is field level masking? 10 Individual fields can be “masked” in addition to being encrypted • One of the big benefits of field level masking versus disk level encryption. • For example, a Social Security Number (SSN) field can be masked so that: • Only certain users or groups can see the fully unmasked SSN data • Other users or groups can be masked to see only the last four digits of the field • Other users will see a fully- masked SSN Let’s use the Social Security Number 123456789 as an example • For users that need to see the full SSN such as a payroll administrator, the field is encrypted but gets decrypted on the fly and they can see the full number • For other users, you may decide that they should not see the full SSN, so in that case, you can mask the first 5 digits, so the SSN# would look like this: XXXXX6789 • You can mask the entire field for certain people or groups if appropriate, so the SS# would look like this: XXXXXXXXX
- 11. Field level masking • If the field in question is a numeric field, the mask will be the number 9. However, if the field in question is a character field, you can choose the character that you want to use for the mask. • For example, if you want to mask a credit card number that happens to be a character field, you can choose “X” or whatever other character you want to use for the mask. • Let’s use the credit card number 1234567890123456 as an example. If we decide to mask everything but the last 4 digits (or characters in this case), it looks like this: XXXXXXXXXXXX3456 • If you decide to mask the entire field, it looks like this: XXXXXXXXXXXXXXXX 11
- 13. What does field level encryption look like on the IBM i? 13 The best way to see that the field or fields are encrypted on the IBM i is by leveraging the DSPFFD command. Below is an example of a social security number that is not encrypted:
- 14. What does field level encryption look like on the IBM i? 14 After encrypting a field with field level encryption, you will notice new attributes on the field called “Field Procedure Name” and “Field Procedure Library”. Below is an example of a social security number that is encrypted via a field procedure.
- 15. 15 Field procedures are part of the IBM i OS. They can be used for other purposes but are primarily used for encryption and masking The best way to encrypt and decrypt fields with field procedures is to use a third-party interface that will develop the code for you, attach it to the field in question and help you to manage and track which fields are encrypted or decrypted and to set up the masking rules A field procedure is a procedure that can be written by hand and attached to the field, however, that can be a large undertaking How do I encrypt sensitive fields in a file? Working with Field Procedures
- 16. Implications with for field level encryption • While encrypting or decrypting a file, the IBM i requires an exclusive lock on the file until the encryption or decryption has completed. This means users need to be out of the file until the operation has completed. • For smaller files, this may not be an issue as you may be able to lock the file for a short period of time. However, for larger files, this process can take several hours. • In addition, many customers have requirements to “roll” the encryption keys periodically, which requires decryption and then re-encryption of the fields with a new key. • For legacy RPG-ILE programs, if the encrypted field is an index or key on the file, the sort order will be based on the encrypted data instead of the actual values. There are technologies that can help overcome this situation available on the market. Once you have decided on a tool to develop and manage field level encryption on your IBM i, there are some technical considerations:
- 17. Minimizing the downtime required to encrypt/decrypt fields 17 • In order to avoid the downtime required to encrypt fields in larger files, there are technologies that allow you to ”Encrypt while active”. • This technology allows you to make a copy of the file empty (using CRTDUPOBJ) into a temporary library. Once the file is duplicated, it can encrypt while it is empty. • The “Encrypt while active” technology will then copy all the records from the production copy of the file into the temporary copy. As they are being copied in, the records are encrypted. • This technology keeps the file in sync with ongoing changes since the file is still being used by end users and applications.
- 18. Minimizing the downtime required to encrypt/decrypt fields (cont.) 18 • Once you have a maintenance window and have users out of the file, the process that keeps the file in sync is ended, the old copy of the file can be moved out of production, and new encrypted version of the file can be moved into production. • The file is moved into production using the MOVOBJ command which simply updates the pointer to the location of the file from the temporary library to the production library. It does not perform a full copy of the data so the process is very quick. • The ”Encrypt while active” technology can save many hours of downtime on initial encryption, and then also during the roll of the key when the file needs to be decrypted and re-encrypted with a new key.
- 19. What can I do if I have legacy RPG-ILE programs that no longer sort correctly by an encrypted key field? There are technologies available to help with the sorting issues that may occur because of an encrypted key field in legacy RPG-ILE programs These technologies require access to your source code Handler software can be used to convert traditional record-oriented file access to SQL Query Engine (SQE) access Only one line of code is added to make this conversion Presentation name 19
- 20. Presentation name What can I do if I have legacy RPG-ILE programs that no longer sort correctly by an encrypted key field? (cont.) 20 • This is what the additional line of code would look like to handle the sorting issues in a legacy RPG-ILE program: • The handler program converts record-oriented reads into SQL access which corrects the sorting issues experienced by having an encrypted key in legacy RPG-ILE programs
- 22. Field level encryption performance considerations 22 Any time you add a new process into the mix when dealing with database transactions, expect to have additional overhead on your IBM i processing time Since a program will get executed each time a new record is read to perform the decryption and then re-encryption, that will produce overhead Expect programs to run longer than they currently do when the fields are not encrypted Testing and benchmarking should be done so that you will know what impact the addition of field level encryption will have in your environment Performance is also dependent on the conditions of your system – additional resources may be required to support the additional overhead of encrypting fields in your database
- 23. How does field level encryption work with a HA/DR solution? • If you have a replication solution in place for high availability or disaster recovery in your environment, there are a few considerations • First off, the field procedure program needs to be included in replication. The best practice is to generate the field procedure in the same library as the file that has encrypted fields. • Depending on your third-party software solution for encryption, you should have the product installed and licensed on the HA/DR systems so they are ready to go for a role swap. • If you are using an external key manager, your HA/DR partition will need to be able to access the server as it did on the production system
- 24. So why is field level encryption better than disk level encryption? 24 Disk level encryption utilizes the same key for everything. If the key gets compromised, all the data on the system can be decrypted with one key Field level encryption can utilize a different key for every field, or every file depending on how you want to implement it. If one key gets compromised, the rest of your data is still protected Disk level encryption does not allow for masking individual fields, whereas field level encryption allows for masking to hide sensitive data from those that may have access to the file but shouldn’t be able to see the sensitive field data
- 25. How Precisely can help
- 26. Assure Encryption 26 Complete protection for data at rest and in motion • IBM i FieldProc exit program-based encryption • High performance encryption libraries • Built-in masking of decrypted data based on user or group • Simplifies and ensures secure encryption key management • Includes extensive data tokenization capabilities The only NIST-certified AES encryption solution for IBM i
- 27. Assure Encryption 27 Integrates with other applications and key managers • Encryption commands for Save Files, IFS, and much more • Extensive encryption APIs for RPG and COBOL • Native support for Townsend Security’s Alliance Key Manager • Integrates with any OASIS KMIP-compliant key manager
- 28. Questions?