IBM i has multiple layers of defense, starting with the hardware itself and going up to the operating system. The platform does have some vulnerabilities that if left configured improperly, can result in hackers or even insiders to your company gaining access to data that they should not have access to. It is extremely important to implement the most appropriate security level around passwords, encrypted sessions, and so on.
There is another important layer of security that needs to be considered – Encryption for protecting data, let’s look at the various ways encryption can be implemented on IBM i.
Encryption in Motion
IBM i customers need to meet regulatory requirements to secure the transfer of data over the internet and on internal networks to eliminate any exposure. Encryption in motion is a way to secure the transfer of data and provides secure FTP (SFTP) and Secure Shell (SSH) transfer support to meet these regulations. Optional PGP encryption protects data at the source and destination.
Secure file transfer can encrypt any file type including Db2 database files (externally described files), flat files (internally described files), IFS files, Save Files, and spooled file reports. PGP encrypted files can be received from any other system including Windows, Linux, UNIX, IBM AIX, Sun Solaris, HP-UX, and IBM z (Mainframe).
Encryption at Rest
Encryption transforms readable information into an unreadable format (or “cyphertext”). Encryption is based on proven, well-known algorithms and is continuously scrutinized with attempts made to break them. Algorithms rely on secret “keys” for encrypting/decrypting data. The best encryption solutions are independently certified to validate compliance with standards (e.g. NIST). The encryption algorithm is never a secret, but the encryption keys must be kept secret. Encryption is a mature science that has been used for thousands of years
Companies with sensitive data should implement DB2 encryption and look at their security practices. It can play an important role in protecting sensitive data from being exposed into the world which can lead to heavy fines and compromising businesses. To stay in compliance with PCI-DSS, HIPAA, GDPR, SOX, and other regulatory regulations, sensitive parts of your data are required to be encrypted, ensuring the safety of your company and customer’s critical information.
Encryption was simplified by IBM i Field Procedures, based on the exit point technology beginning with IBM i V7R1. This has been a game-changer as it eliminates the need to make changes to the database files and applications. It also no longer required developers to make extensive changes in their code, opening up encryption to customers running older applications. Using field procedures masks the complexity associated with this change. While access to such data can be controlled by the IBM i’s powerful access controls, it is still very prudent and a legal requirement to encrypt sensitive components of this data – just in case employees, staff with high system security level access, or hackers, manage to gain access to areas they should not.
Encryption key management is critical. Hackers don’t break encryption algorithms, they find the keys. Encryption keys are kept secret and must be protected. Key management is key to successful data encryption. Vendor products have solved this problem and provide solutions that include encryption routines, key management, and methods for determining which users see the full data or masked data. Compliance regulations like HIPAA, PCI-DSS, and others, require proper key management and (FIPS 140-2) lays out industry standards and best practices for key management
What does a key Manager do?
It protects the keys from theft and loss. It’s recommended to store the keys separately from the encrypted data, restrict access to keys and back up keys separately. You want to support the separation of duties between whoever is encrypting the data and handling the keys.
IBM introduced the concept of encrypted disk, which encrypts the entire disk unit and enables any data that is written to the disk to be automatically encrypted. It’s really more of a system-level function, and there is no protection from the data access. With field procedures, because it is an application program, it is going to be selective. You can use authorization lists that the field procedure will interrogate to decide what type of visibility the user has and If the user is not authorized they won’t see anything. So in other words, disk encryption does not offer a layer of defense against inappropriate access of your data. Disk only protects your data when you swap out a disk, and data is automatically decrypted. Full disk encryption offers no options for specifying who can see fully decrypted data; data is always decrypted on access. Using FIELDPROC provides protection regardless of how the information is accessed—via an application menu, FTP, ODBC, remote command, command line, etc.
Challenges with Encryption
The challenge with encryption is that it can be very time consuming, even though it is relatively straightforward. The key is so critical here that handling key management is a big part of what we need to consider. Unfortunately, a lot of times we see that the keys are stored inside source code. That was actually part of the reason that there was a documented hack with Verizon. When people broke into their web services, they discovered that there were IBM i user IDs and passwords embedded in scripts, and they were able to access the system. So, storing keys in plain view, inside source code is not recommended.
iTech Solutions can help. Let’s talk about IBM i Security.
Book a meeting with a member of the iTech Solutions team to talk about your IBM i security.