Admin Alert: What To Do with Vendor Profiles During an Audit, PLUS Two Other Great Features
November 2, 2011 Joe Hertvik
|
System auditors generally don’t like i OS vendor-supplied profiles. You know, those user profiles that vendors require for software installation, ownership, or running special jobs. Some vendors even require you to give these profiles security officer (*SECOFR) or security administrator (*SECADM) authority. This can create audit points because auditors generally don’t like excessive security officer-enabled profiles on the system. Here are two strategies for handling this situation. What Is a Vendor-Supplied User Profile? A vendor-supplied user profile is any profile that exists on your i OS system in order to load software objects, or run vendor programs. It may also be used as a group profile for vendor software access. Most well-known Power i third-party software packages install their own user profiles for these purposes. Vendor user profiles often have system privileges far above what a standard user possesses, such as being security officer enabled or having all objects authority to the system. And that’s where the problem comes in. Two Ways To Set Up Vendor-Supplied Profiles To Pass Audits Financial, Sarbanes-Oxley, Payment Card Industry (PCI), and other system auditors generally dislike active vendor-supplied user profiles that possess one or more of the following characteristics.
A system auditor may ask for a listing of all active users who fall into one of these categories: a.k.a., a super user list. If your vendor profiles contain any of the features listed above, they should show up on the super user list. But there is an out. You may be able to omit these profiles from the list if a profile meets one or both of these criteria.
Changing your vendor profiles this way may be enough to drop that profile off your super user list. This is because they will no longer possess an audit danger. Let’s look at why these techniques may allow you to neutralize that profile, in the eyes of an auditor. Technique #1: Disabling the vendor profile. How to use: Run the following Change User Profile (CHGUSRPRF) statement. CHGUSRPRF USRPRF(profile_name) STATUS(*DISABLED) What it does: Prevents the user from signing on to the system. Not only will this stop them from signing on to a 5250 green screen, it will also stop them from signing on to the system from any client connection, such as an FTP session, an ODBC connection, or even a Web server. Situations to use this technique for:
Disabling a user profile should satisfy an auditor that a hacker cannot sign on to the system and perform work with that profile. Technique #2: The profile has no password for signing on. How to use: Run the following CHGUSRPRF statement. CHGUSRPRF USRPRF(profile_name) PASSWORD(*NONE) What it does: Prevents the user from signing on to the system. The profile remains enabled. However since it has no password, profile access remains disabled. Situations to use this technique for: No password profiles can be used in the same situations as a disabled user profile. However, you will have to add a password to these profiles in order for them to sign on to a 5250 screen and perform software maintenance. While removing a password from a user profile will effectively prevent the profile from being used, auditors may be more comfortable accepting a disabled user profile rather than a profile with no password. Generally speaking, disabling vendor-supplied user profiles is a better audit strategy than removing their passwords. Of course, you can always combine the two strategies such that you disable your vendor user profiles AND remove their passwords. That would be the safest way to insure these profiles can’t be used to perform any damage. However, it might also be overkill. And that’s how you may be able to remove vendor-supplied profiles from your auditor’s super-user list.
The Challenge from Don K On a different note, reader Don K. recently wrote in looking for information on how to access the HMC system console in 132-character mode. Don needs to run a 132-character system console through the Web but couldn’t find anything in IBM‘s documentation to enable it. I tried enabling this feature on my own Web-based HMC systems consoles. But like Don, I was unable to find the key to enabling 132-column support on my system consoles. So if anyone out there knows of a way to configure the HMC system console to display 132-characters through the Web interface, email me. Correct answers will be forwarded to Don. Winners will also be awarded prestigious Friend of the Column status for their good work. For Redundant Power i SMS Monitoring, is VOIP the same as using a POTS line? After my article on adding redundancy to Power i SMS Monitoring, reader RP wrote in to ask me about running i OS 6.1 SMS on Voice over Internet Protocol (VOIP). I was running the same setup as you detailed in your article, using Bytware‘s MessengerPlus and a Multimodem GPRS wireless modem. This worked great until we moved to another location that wasn’t able to provide regular 110V power to plug in my modem. In this case, I can’t use an external modem and I have no internal modem available. What do you think about using VOIP in this situation, where the VOIP line is my backup in case my Ethernet-based monitoring goes down? Is that defeating the purpose of installing a redundant line for SMS? –RP I’d have to agree with RP on this one. The whole idea behind putting in a redundant POTs landline for text alerts is that the POTs line would still be functioning if your Ethernet network goes down. If you use VOIP over Ethernet as your backup, you will have Ethernet routing redundancy. One message will go to a wireless carrier email address and another message goes to a Telocator Alphanumeric Protocol (TAP) number through your VOIP provider. But you won’t have transmission redundancy, because both messages are still going out over your Ethernet network. If your Ethernet network fails, your SMS messages will not be able to get out. That’s the trade-off with substituting VOIP SMS backup for POTs line SMS backup. Still, if you can’t get 110V power or a POTs line, I suppose Ethernet routing redundancy is better than nothing. It will still send a text alert if your email system goes down. One way to improve this situation could be to run your iSeries connection to your mail router and your VOIP network on totally different networks that reach the outside world on two different T1 connections. And if you can provision the two T1s from two different carriers, that would make the segregation even better. While this might be effective in providing redundancy for iSeries text alerts, it may be prohibitively expensive for what you’re trying to accomplish. If you’re going to go through all that trouble and expense, it might be worthwhile just to buy a modem card and install it in your machine. One final note on using a POTs line to transmit SMS messages from your i OS system. This week, I tried to modify my configuration to send POTs-line SMS messages to a T-Mobile cell phone. I quickly discovered that T-Mobile doesn’t support public TAP transmission. So while TAP may be a good idea to provide a secondary text alert path from your Power i box, be aware that it may not be available for all carriers. RELATED STORY Adding Redundancy to Power i SMS Monitoring
|
