Compliance requirements are responsible for driving most access control policies, however implementation is always subject to interpretation and quite frequently poorly executed. Passing an audit and addressing audit findings, does not necessarily mean compliance. Most auditors simply do not know the IBM i security vulnerabilities or your applications well enough to find all or most of the vulnerabilities. System administrators will likely have the best sense of where vulnerabilities exist, and might be best suited for locking down the system. Knowledgeable IBM i administrators know menu level security controls will not prevent users from accessing sensitive data they should not be accessing. Menu level security only works when users are in the application. Likewise, object level security does not honor the IBM i security schema when users access the system over exit points and TCP/IP ports.
Multi-Factor Authentication (MFA), a.k.a. Two-Factor Authentication (2FA)
IBM i MFA should be your first line of defense to ensure the users accessing your system are who they say they are before authorizing logon. When choosing a multi-factor authentication solution, it’s important to choose a product that performs single step authentication, as multi-step is considered to be insecure and commonly not compliant by many compliance regulations. It’s also important to understand the different scenarios for which you want to invoke MFA when evaluating a solution for your environment and data access policies.
Exit Programs for Exit Point Security
IBM i Exit Programs provide network security, database and command controls that enforce library and object level authorities for users, regardless of how powerful their profile is (including QSECOFR). Exit programs allow administrators to control how users access the IBM i, as well as control how users use the data. When a user requests access to the IBM i (such as a Read, Write, Delete, Execute, Upload, Download, Logon, etc.), OS400 associates and routes the request to the appropriate application server (i.e., Database, FTP, File Server, RMTSRV, Telnet, RMTCMD, etc.). If an exit program exists for the exit point, the operating system calls it, and passes along the requested transaction parameters. The exit program analyzes the requested transaction to determine if it should be permitted or rejected based on the user’s policy defined. The exit program then sends a return code to allow or reject the request before returning control to the server. The return code from the exit program instructs the server to process or reject the request. Additionall, exit programs capture critical audit information QAUDJRN does not capture for these user network activities, such as real user ID, IP address, functions user performed, library/object accessed and any commands or SQL statements users may have been run.
IBM exit points that can use exit programs for access controls include:
Application Servers (Networks Protocols) such as FTP, ODBC, JDBC, RMTCMD, DDM, DRDA, RMTSQL, File Server, and other exit points allow users to connect directly to the IBM i DB2 databases.
Open Database File exit point can be used to protect sensitive data from any kind of access, including through open-source protocols such as JSON, Node.js, Python, Ruby, interactive STRSQL, open Query OPNQRYF, Process Extended Dynamic SQL, IBM Query, XCOM and other tools that allow updating, deleting and downloading data. A Open Database File exit program significant protection because it can be invoked whenever a specified file on the system is opened, whether it’s a physical file, logical file, SQL table, or SQL view.
Command exit points control the use of specific commands that supersede OS400 user profile and object-level security authorities, even for users that possess powerful authorities such as *ALLOBJ or *SECADM.
Network protocols (communication ports) do not have their own exit points, such as SSH, SFTP, SMTP, and others. Therefore, IBM provides socket exit points that allow access controls to secure connections to the IBM i by inspecting packets of specific inbound and outbound ports, much like a typical firewall would. Furthermore, if users should not be accessing the system using unsecure communications, make sure these ports are not listening.
SNA exit points consist of legacy communications over DDM, DRDA, Pass-Through, File Server and others. Although Client Access no longer supports these connection features, they can still be used from any command line or application to access database files, run SQL or CL programs if these SNA ports are listening.
User and application authorities defined by exit programs are enforced ahead of OS400 object-level security, providing an additional layer of access controls and provide much more flexibility to control powerful user’s actions above and beyond OS400 security schema.
Exit programs can enable very flexible and specific rules to be defined for specific users or groups of users and for specific application permissions. Preventing users from running specific commands, functions or remote commands is another example of how exit programs can be used to control user actions. These type of access controls are not inherent to the operating system, and enable locking down access to sensitive data for compliance. At a minimum, if an unauthorized user was able to by-pass MFA access controls, exit programs can help prevent or significantly minimize damage the breach would have caused.
Profile Swapping and Elevated Authorities (a.k.a. Privileged Access Management PAM)
Almost every IBM i system has too many powerful profiles with authorities and command line access that are only needed on occasion. The greater in number the power profile list is, the greater the security exposure and liability the system is to the company. Powerful authorities and the users that use them, should most often be strictly controlled, and only users with a business need should be granted authority to use them. Elevated and adopted authority policies can be used to grant a user or group of users the necessary authorities they need to perform a task on a temporary basis by means of a profile swap that has been approved by a manager and or ticketing system.
Encryption
When an IBM i has sensitive data or when a compliance regulation dictates, encryption will be the primary and last security defense for protecting your data at rest, in motion, and regardless of how it is accessed. If and when all other access control policies have been circumvented, DB2 database encryption is the end all solution that prevents misuse. Even if your data is accessed from a stolen backup, and the data was encrypted, the sensitive data is safe. If the encrypted data is replicated to a target system in a HA or DR environment, the data will remain in an encrypted format. If you were only going to implement one access control security defense for your IBM i, and it has sensitive data, choose encryption. Encryption can be used for any type of data on the IBM i, including DB2 Database files, columns, rows, fields, messages and backup media.