What the California Consumer Privacy Act (CCPA) and Similar Regulations Mean for You: Addressing IBM i Data Privacy – Part 2

This article on the California Consumer Privacy Act (CCPA) was originally published in Enterprise Tech Journal. Part one of this two part post focused on an overview of the CCPA regulations and the responsibility of IT departments when handling data privacy regulations. This part covers the protection of IBM i data.

Obscuring sensitive IBM i data

Sound IBM i security practices and technologies are critical to preventing the occurrence of a breach, but if it does happen, it’s equally critical that sensitive data cannot be read by the unauthorized actor. As mentioned in the introduction of this article, CCPA gives consumers the right to sue an organization in the event of a data breach that exposes their personal information if that data wasn’t encrypted or otherwise made unreadable. In addition to encryption, CCPA mentions “redaction” and “deidentification,” which could be accomplished through tokenization (also called pseudonymization), anonymization, and masking.

Encryption

Encryption transforms human-readable data into unreadable ciphertext by taking a publicly available algorithm and combining it with a private encryption key (a unique, secret sequence of bits). When the data needs to be read by an authorized party, it must be decrypted using the proper encryption key. For encryption to be effective, it’s critical to carefully manage and protect encryption keys; if your keys are found by a hacker, your encryption efforts could be for naught. In fact, if your data is encrypted and there is a breach, you will likely need to show a compliance auditor that encryption keys were adequately secured.

Encrypting data at rest

Third-party encryption solutions for IBM i are used to encrypt sensitive data “at rest” (the data resides in some form of storage). Before V7R1 of the operating system, encrypting data at the field level within databases required application changes in order to call encryption APIs. Today, however, application changes are not needed thanks to IBM adding a column- or field-level exit point called Field Procedures (FieldProc). Third-party encryption solutions provide exit programs that can be called by the FieldProc exit point to encrypt and decrypt at the field level without application integration projects. Additional IBM i objects such as IFS files or backup files can also be encrypted through command lines or APIs.

Encrypting data in motion

It is essential that the transfer of personal data over a network, whether as streams of data or entire files, be encrypted to prevent this data from being exposed should it be intercepted by a bad actor. When data streams are sent, they are typically encrypted by technologies embedded within network protocols, such as encrypted Telnet, HTTPS, etc. When entire files are sent between servers or entities, this is typically done using SSH Secure File Transfer Protocol (SFTP) or FTP over SSL (FTPS). Third-party managed file transfer solutions help execute and manage these secure file transfer processes and can also encrypt data at the source and target using PGP to prevent unauthorized access before or after the file is transferred.

Additional methods of obscuring data

Other technologies besides encryption can be utilized to make sensitive data unreadable to an unauthorized party. In essence, these technologies replace sensitive data with nonsensitive substitute values.

Tokenization

Referred to as pseudonymization by CCPA and elsewhere, tokenization replaces sensitive data with nonsensitive replacement values (tokens). The technology utilizes a database called a token vault to store the sensitive data along with information about the relationship between the sensitive data and its replacement token. By tokenizing the data on production systems and storing the original data within a token vault on another server, the production server is effectively removed from the scope of compliance. Of course, the token vault must be aggressively secured from breach, which is why many companies encrypt the contents of the token vault. Because there is no algorithmic relationship to the original data (as there is with encryption), there is no way to crack the token value to derive the original data. Third-party tokenization solutions for IBM i are available to automate tokenization and detokenization processes.

Anonymization

As a form of tokenization, anonymization permanently replaces sensitive data with a substitute value, making the original data completely unrecoverable. Anonymization is never used for production data, although it can be used on a copy of that data when it’s needed for development or test environments. When data needs to be sent to a third party for reporting and data-aggregation purposes, anonymization can be used to remove any personally identifying information before it is sent.

Masking

Not an encryption or a deidentification technology per se, masking is instead used in conjunction with encryption and tokenization solutions. This technology obscures portions of a database field with an “X,” an asterisk, or another designated character when that data is decrypted or detokenized to ensure that the application user sees only the data required to accomplish their job. The type and length of the mask that’s used can vary based on the user and the context in which the data is being viewed.

Protecting IBM i systems from a breach: the importance of a multi-layered approach

In addition to obscuring sensitive data so it’s rendered unusable should a breach occur, from a CCPA perspective it’s equally important to prevent a breach from happening in the first place. A skilled intruder might break through a single security approach or technology and gain unauthorized access to systems and data, but when multiple layers of security are in place, hacking becomes much more difficult. That’s why IBM i shops need a defensive posture that addresses each potential type of attack. Beyond the general IT essentials of physical security, network security, IT security policies, and periodic risk assessments, there are several critical IBM i-specific layers of security that must also be implemented.

Configuring security in the IBM i OS

Strong IBM i security requires proper configuration of the IBM i OS and related resources. This includes appropriate settings for system values, object permissions, user authorities (more about this shortly), and more. In addition, it’s critical to keep OS versions and PTFs up-to-date.

Comprehensive access control

Traditional object-level security on IBM i is insufficient when it comes to protecting access from network protocols (e.g. FTP, ODBC, JDBC, OLE DB, DDM, DRDA, NetServer, etc.), open-source database access protocols (e.g. JSON, Node.js, Python, Ruby, etc.), and commands. IBM provides exit points for each of these access vectors, which can be utilized by rules-based exit programs to reduce the possibility of intrusion.

Taking control of logon security (beyond implementing strong password policies) and controlling access to elevated authorities are also important steps toward preventing external and internal parties from accessing sensitive data. Multi-factor authentication strengthens logon security by requiring users to provide one or more additional identifying factors beyond username and password before accessing systems, objects, commands, etc. Tight control of users’ abilities to obtain powerful authorities is best done by giving users only the authority they need to do specific tasks for a limited amount of time and within strict parameters (i.e. time of day, IP address, etc.). Revoking that authority after the specified time is key to maintaining control.

Third-party solutions are available that streamline the management of each of the above access control strategies.

Security auditing and monitoring

Quickly spotting suspicious activity is vital to preventing a breach or at least minimizing damage should one occur. That’s why putting in place tools and processes that provide comprehensive auditing and monitoring of IBM i activity is another important layer of security.

In addition to tracking activity through system message queues and QHST entries, IBM i shops can utilize the journaling capabilities of the operating system to record a rich layer of system activity. This unalterable information makes it possible to log and trace user authentication, system access, data changes, object configuration changes, and more. The output from journaling is both prolific and cryptic, but third-party solutions greatly simplify and automate the analysis of journal activity to pinpoint suspicious events, as well as to trigger alerts, create reports for auditors, and more. For organizations that use an enterprise-wide security information and event management (SIEM) solution to aggregate and analyze security activity across disparate IT systems, third-party solutions are available to forward IBM i security information to a SIEM.

Organizations that keep particularly sensitive information can go beyond analyzing the database changes tracked in log files and actually monitor user views of Db2 data. Knowing whether an unauthorized user viewed sensitive data is something that journaling can’t track. Third-party IBM i security solutions are beginning to offer this capability.

Get a head start toward better IBM i security

As stated at the outset of this article, the time to prepare for data privacy regulations is now. Even if your organization isn’t affected by CCPA, it’s likely that one or more data privacy regulations will affect you in the not-too-distant future. In order to get a head start toward complying with these regulations, your organization must:

• Know where data about individuals is located within your systems
• Be able to respond efficiently to requests from individuals
• Harden the systems containing this sensitive information against a breach
• Obscure sensitive data in the event of a breach

But regulations aside, given the significant cost and disruption of a data breach, it is only prudent that every organization make regular improvements to its IT security. The goal of this article is to give you a road map that guides your journey toward more secure and resilient IBM i environments.

To learn more about how to ensure that your IBM i installation is ready for CCPA, please download our ebook on CCPA and IBM i Data Privacy.