It has only been a year, and the new data protection and privacy regulations have already hit a few companies with multi-million dollar fines. Every company with sensitive data on an IBM i (iSeries AS400) and has data protection and privacy requirements, should have implemented DB2 encryption already. Some of the companies seen in the news recently not only failed to secure personal data properly, could not accurately assess how much data was compromised, had a lax incident response plan and were slow to notify authorities. These factors all led to heavier fines, causing the total financial penalties to exceed 100s of millions dollars.
The latest data security and privacy regulations like
GDPR, PCI and NYCRR 500 extend globally, and have some pretty sharp teeth. GDPR’s
data protection and privacy safeguards have garnered such high praise, most federal, state and local governments like California are modeling their new laws after it. These new data protection and privacy laws have put a lot of overdue responsibility on companies to take better care of our personal data. There are several aspects of the new data security and privacy laws that will affect how much a company will be fined, and will vary on the compliance regulation. So far, GDPR appears to be the strictest and has the costliest consequences with a maximum fine equal to 4% of a company’s revenue. The number of records exposed will be a significant factor when determining a fine, but even more importantly will be the extent and measure of data protections the company implemented to protect personal data. Put simply, companies better due their due diligence to secure personal data.
The company fines that incurred the heaviest fines thus far, were incidents that involved unencrypted records. On the IBM i, DB2 database
encryption is the most important data protection mechanism for data security and privacy compliance. Here is why. Regardless of how the data is accessed, used or where the data ends up, DB2 database encryption for IBM i provides data security and privacy protection from both internal and external threats. No other security access control mechanism provides this all-encompassing protection. To monitor and control user access for all the IBM i exit points, a company would need to implement many exit programs to cover all the OS400 application servers, open database protocols, commands, legacy SNA exit points and all the ports that do not use an exit point. A more efficient and secure way to protect personal data would be to implement IBM i DB2 encryption.
The IBM i does not support self-encrypting drives SED, and the only ways to implement disk encryption is either by migrating to SAN storage or using ASP encryption (which is free with OS400 V7R3 and higher). However, neither of these encryption solutions would suffice as adequate data security methods for most data protection laws like GDPR, PCI NYCRR 500. These encryption technologies only protect data in the event the disk drives end up in the hands of an unauthorized individual and during specific data transmission operations. Disk encryption does not protect data in any other scenario.
The premise of the data protection laws is to protect data at rest and in motion. Whereas data privacy laws involve responsible management practices of personal data and honoring user requests and permissions they provided to collect, store and share their personal data. Companies subject to data privacy laws are also subject to data security, but not the other way around. Personal data a company collects may be stored and protected properly, but did the company have the user’s permission to store it in the first place? Did the company have proper access controls in place to prevent employee misuse of their data? Was the personal data shared outside the scope of the user’s explicit permissions? Was all the user’s data removed from the company assets and in their control when requested? Encryption cannot protect a company from data privacy infractions, but it can minimize financial penalties if or when an infraction occurs. Data privacy regulations will be addressed in a future articled explaining the importance of strict data privacy governance, incident response processes and proactive approaches to maintaining a good compliance posture. The remainder of this article will focus on IBM i data protection methods with DB2 database encryption.
Since ancient times, encryption has been used to protect sensitive information. Today, encryption is used to protect our data from every connection on a network, as every workstation, server, access point and device can be used to access sensitive data on the IBM i. If you run the NETSTAT command, you can view all the connections being made to and from your IBM i. You are likely familiar with many of these connection types, but there are likely even more you are unfamiliar with. All these different ports in use are examples of how users are accessing your IBM i, and probably have no or few access controls in place to control how users access and use personal data stored on the system.
Insiders are the biggest threats to companies with data protection requirements, and are the number one reason companies so often have to pay fines. Insiders make up all unintentional improper handling of data incidents, and IT rarely has implemented proper access controls (IBM i exit programs) to properly protect data. At every company, users copy data to their workstation, upload to Cloud services, download to a thumb drive, copy to a development environment and store reports in unsecure unmonitored locations. Everyone of these scenarios will cause the company a costly reportable data breach. It is a common misconception that native IBM i object or menu level security will stop these events from happening. To monitor and control user access to and from the IBM i, companies would need to implement many exit programs to cover all the OS400 application servers, open database protocols, commands, legacy SNA exit points and other ports that do not use an exit point.
Some OS400 Security Basics:
- Users with *ALLOBJ authority or which can adopt this All Object authority through an OS400 group profile or supplemental group can access any sensitive data on the IBM i.
- Users with *USE authority can download sensitive data to their workstation
- Users with Limited Capability can run CL commands
- Applications that use adopted authority or perform a profile swap typically use *SECOFR authority
A more efficient and effective way to secure personal data for data protection compliance requirements would be to implement IBM i DB2 encryption. In addition, companies may choose to anonymize, mask or scramble personal data as a compensating control for specific use cases. Encryption does not negate the need to implement security access controls, it only safeguards the data from unauthorized access. Companies must still control how their users use the data. If an employee has authorization to read data in plain text view, access controls must also be in place to prevent the employee from downloading or running a report over the data, where the personal data would then exist without any auditing or controls in place.
Implementing IBM i encryption really only involves three primary steps: Defining User Access Permissions, Creating Encryption Keys and Executing Encryption Policies. Where to begin? Identify all the locations where sensitive and private date is stored on the system. At most companies, it has been a wild west atmosphere for far too long. If your company has not already done so, this would be a good time to educate employees on the proper procedures for handling data. In fact, educating and reminding employees about the dos and don’ts should be an ongoing process.
Assess what data types will be in scope for this project, and identify all the IBM i locations this data stored (libraries, files, fields, directories, logs, and other storage areas). Administrators can use DDS and SQL Create source to locate the DB2 files and tables to locate personal data in scope. Document the characteristics of the data for implementation considerations later, particularly if it is a key field. Older RPG applications not using native SQL Query Engine (SQE) for database access, will first need to convert applications to use Open Access for RPG SQL. It sounds more work than it sounds, but it only requires changing a single line of code to switch to the native SQL Query Engine.
Next, consider how the different user groups use this data. Are they simply viewing data through an application menu? Or are they running reports, queries and extracting the data for external use? If so, determine which external devices are accessing, sharing, transferring or storing this data (PCs, Servers, Cloud Services, Trading Partners, Banks, Insurance Companies, etc.). You may need IBM i exit programs to determine how IBM i data is being used by user PC applications.
After completing the hard part, you can now outline your encryption game plan. Organize your User IDs into groups of whom should have full access, partial access (i.e. masking all but last 4) and no access for each data type identified. Segment these users into common primary and supplemental groups for simplicity of implementation and ongoing management.
Implementing encryption with associated master and data keys is the last and quickest step. Contact us for assistance or with any questions about implementing IBM i encryption. In just three quick steps, all sensitive and private data on your IBM i will be encrypted (fields, columns and files), and will remain encrypted regardless of how the data is accessed (natively or third-party applications) or where the data rests (backup tapes, replicated data to HA/DR target system, logs, etc.).
A few final notes IBM i encryption. Take into consideration the compliance regulation you are implementing encryption for, as it may have specific requirements for encryption or keys, such as FIPS 140-2 key management, and PCI section 3.5.3. Whether or not your company has requirement to store and manage encryption keys off the system, it is not only excellent advice, it is also a best practice. In addition, be sure to have your encryption policies backup of your keys external to the system and must be included in HA and DR implementations.
Companies exchanging sensitive data using unsecure FTP, data feeds and other file transfer processes will need transition to secure file transfer process, like SFTP with PGP encryption. Sensitive data will need to be decrypted and re-encrypted using PGP so that a public encryption keys can be shared with your trading partner.
Lastly, ensure necessary auditing of all access to sensitive data, encryption and key changes are logged and archived in your company’s SIEM, SYSLOG Server or SOC. These requirements are common for almost all security and privacy regulations, and will likely require a significant amount of very intelligent staff to enable and manage, or a very well thought out security product.
Please contact with any questions, consulting, implementation, demonstrations, POCs, training or other professional services your company may need. Below are a few of the services we offer that relate to the topics pertaining to this article.
IBM i Encryption Software or IBM i Security Consulting Services
Consulting Services by CISSP, CIPP, CIPM, GSLC, CISA, CCSK and PMP for:
Security Assessment, Vulnerability Management, Penetration Testing, Security Incident Forensics, Incident Response Planning or Training
Privacy Assessment, Training, Design and Data Inventory or Mapping
Compliance Breach Response, GDPR, PCI, HIPAA/HITRUST, NIST, ISO, CCPA, CIS CSC, CSA Star, SOC2 or Privacy Shield
