PowerTech Command Security controls command use on your system.

Recently, I was approached at a tradeshow by the CIO of an organization running IBM Power Systems servers. He asked if I could help with a security dilemma his company had encountered. It seems that they had recently experienced an "unplanned outage" after an administrator inadvertently issued a PWRDWNSYS command while mentoring a new operator.

I cringed as I recalled a few occasions early in my own career when I wished the Enter key had ignored my instruction! While this administrator was authorized to perform this type of system task, there certainly was no desire to run it in the middle of the workday with the IBM default of RESTART(*NO)! The CIO wanted to know if there was any way he could enforce restrictions on users who typically are authorized to run commands. This was similar to a request I had received from another company, asking how they could prevent their programmers from using any of the CRTxxxPGM commands to compile directly into production.

Commands = Power

I explained that commands are objects and that you can grant and revoke authority to them much the same as you can with any application object. Some commands require that the person executing them have certain special authorities (in the case of the embarrassing PWRDWNSYS command, the user needed *JOBCTL special authority.) Unfortunately, once these requirements are met, the operating system does nothing additional to oversee execution of the command. This means that a user who is authorized to a command has total control of when and how it's executed.

Control Command Use with Command Security

PowerTech Command Security is a new rule-based security solution that's designed specifically to audit and control commands. To configure Command Security, you start by selecting which commands you want to monitor. Then, specify the conditions under which the command should be controlled. And finally, define the actions to take when those conditions are met. Conditions can be based on a value specified on a command parameter, the name of the requesting user or group profile, the calling program, the requester's IP address, or a number of other powerful and flexible filters. If a condition is met, Command Security performs the actions you've defined. Actions can include overriding a parameter (like the RESTART parameter!), sending a message, or even preventing the command from executing.

While there are endless ways to use Command Security to control the command use on a system, consider the following common, and simple-to-configure, scenarios:

• Permit security administrators to run the CHGUSRPRF command, but only if they're listed on a specific "change-allowed" authorization list.
• Notify the high availability administrator whenever someone creates a new library to determine if it should be a candidate for replication.
• Prevent any user from deleting an audit journal receiver.
• Block the use of DFU (STRDFU, UPDDTA) and STRSQL commands on critical files.
• Prevent programmers from using CRTRPGPGM or CRTCLPGM commands to compile directly into a production library.

And last, but certainly not least, for my CIO friend:

• Reject a Power Down System command from anyone but QSECOFR if the following conditions apply: it's between the hours of 8 a.m. and 5 p.m., the RESTART parameter is set to *NO, and the command was issued from an interactive command line.

There are many companies, just like the one this particular CIO works for, that constantly struggle with managing their most powerful users. By partnering with PowerTech, the leading provider of security solutions for IBM i, you can deploy powerful solutions to secure all aspects of the environment without preventing these critical users from performing their jobs.

It's a win-win for everyone! Click here to learn more about Command Security.

as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7, V6R1

Robin Tatam is the Director of Security Technologies for PowerTech, a leading provider of security solutions for the System i. As a frequent speaker on security topics, he was also co-author of the Redbook IBM System i Security: Protecting i5/OS Data with Encryption. Robin can be reached at 952.563.2768 or This email address is being protected from spambots. You need JavaScript enabled to view it..