Command Processing: A Template for Going Beyond Binary IBM iSecurity
Command processing security is a huge issue on an IBM i system. However, IBM i operating system security treats command processing security as a binary event. A user or group is either authorized to run a command or they aren’t. A command can be run in batch or it can’t. There isn’t any flexibility to allow selective access to commands using approved parameters.
11+ Ways to Run Commands
Because the IBM i is a command driven OS, there are at least eleven different ways that commands can be run inside the operating system, including:
- Using the green screen command line
- Using the FTP RCMD subcommand to run commands inside an IBM i FTP session
- Using the Run Remote Command (RUNRMTCMD) to execute commands on a remote IBM i system
- Calling a command from within a CLP or RPG ILE program
- Using the Run Command feature within IBM i Navigator
- Inside an SQL Call statement
- Inside the Qshell environment
- Submitting a command to run in batch using the Submit Job command (SBMJOB)
- Running a command from an API such as QCMDEXEC, QCMDCHK, or QCAPCMD
- Using a REXX procedure
- Creating a command to run another command
The traditional ways to lock down command processing security
The problem is that with so many different ways to run IBM i commands, most shops only lock down command access by using these traditional techniques:
- Updating user profiles to remove command line processing capabilities (only effective when running a command from the green screen)
- Limiting where individual commands can be run (batch, interactive, remotely, etc.)
- Denying user access to specific commands by changing the command’s user authorization list
- Denying user access to the command line through menu security (used with older menu-based third-party software)
These techniques can all be implemented through native IBM i capabilities or through application software.
A Template for going beyond binary command security
As I mentioned above, the traditional methods of locking down IBM i commands involve binary solutions. A user can either run a command or not, mostly from the command line. There isn’t any native option to expand on IBM i’s binary command line security to make it more flexible, allowing users to run commands with one set of parameters but not with another.
At SEA, we realized that what most shops need (but may not realize) is an environment where they can run approved commands in a restricted and secure way, rather than cutting off command access altogether. This environment would use rules to determine which commands and their associated parameters should be approved to run and which commands should be rejected. This environment should also provide reporting capabilities that allow administrators, auditors, and others to detect issues as they’re happening or to perform forensic research to determine how and when past issues occurred.
The template we created for running approved commands in a restricted and secure environment like this has the following three characteristics.
1: Control command security at the command access level AND at the parameter level
Users who have no business running a command should still be restricted from running that command. Only users who need to run a command should be authorized to that command.
Command security should also be flexible enough to restrict users as to what parameters they can use when running a command. A second layer of security should be available that defines which command parameters a user can enter when running a command. Defined by rules, parameter access would be controlled by user or groups and by what values they can enter for specific command parameters.
A programmer for example, could be allowed to use the Delete File command (DLTF) but they could only delete files in the programmer test library (as defined by restrictions on what the user can enter in DLTF’s Library parameter). Similarly, programmers could only use the Change Job command (CHGJOB) on jobs in the QPGMR subsystem and be restricted from using it to change other jobs in the QBATCH, QINTER, or any other subsystem.
Different levels of command parameter access can be defined for different users. The IT Manager may have more authority to command parameters than a programmer. A secure and restricted command environment uses rules to allow users different parameter access to the same command.
Using rule-based access to define access to both the command and its parameter values provides maximum flexibility over just using the binary command security provided with the operating system.
2: Logs, auditing, and reporting
A secured and restricted command processing environment also includes log files for auditors and other investigators to determine who ran a command, when they ran it, and what parameters they used. Logging and reporting capabilities should be available.
Command line usage logging should also be compatible with Security Information and Event Management software (SIEM), such that the command logs can be exported to a syslog server for predictive analysis and forensic research.
3: Alert the authorities when commands are run
Alerts can be generated via several modes when a command is run, including email, adding messages to a message queue, SMS & texting, Twitter, and SNMP. Security personnel should know immediately when a user is running an IBM i command.
Getting all this on your IBM i
This is our template for improving IBM i command security that goes beyond the binary command security offered with the operating system. We implemented this template in our iSecurity Command product. If you want to learn about this more flexible way of executing commands and reporting on their usage, feel free to contact us at SEA software.
