Carol explains the benefits of implementing the features of IBM i security…beyond the obvious security-related benefits.
While the benefits of using the integrated features of IBM i security are obvious—confidentiality of data, data integrity, fully audited, etc. —benefits beyond the obvious exist. Let's take a look.
Eliminates the Accidental Error
One of the benefits of eliminating excess capabilities or objects' wide-open access settings is the reduction in accidental errors. If users don't have the authority to delete an object, they can't accidentally drag and drop it into their Trash bin when they've mapped a drive to the IFS. Nor can they accidentally click on the Upload button on the Data Transfer iAccess plugin button in Excel when they meant to click on Download. Of course, they can try these actions, but they will receive an error if they don't have sufficient authority. If they have the authority, well… you know the end of that story.
Security Projects Result in Cleaned Up Systems
One task we emphasize in our security consulting services is that objects, vendor products, user profiles, etc. should be removed from the system if they are no longer in use. Our point in emphasizing that objects not in use should go is that if the object (or product) is on the system, then you have to consider the security aspects. If it's not in use, why waste the time? A system with a carefully applied security policy ensures that the system is regularly purged of objects no longer in use. The non-security-related benefit is that this reduces DASD consumption as well as the time it takes to perform a full system save.
Shorter Time to Perform Save Security Data (SAVSECDTA)
A direct benefit of removing user profiles that aren't in use is that it reduces the time required to run SAVSECDTA, which is the function that saves user profiles. (SAVSECDTA is also performed when running a full system save.) An even more critical time-saver is that it reduces the time required to run Restore User Profile (RSTUSRPRF). If you have to recover a system, getting it up and running is your obvious priority. But one step you can't skip is restoring user profiles. It's rare that you'd pick and choose the profiles to restore. When restoring a system, you typically take the option to restore all profiles. If you are restoring user profiles that aren't in use, you are wasting precious time when time is literally money.
Take Control of Your System
Controlling excess capabilities means that there's a limited number of users who can make configuration changes to the system. In other words, you can take control and limit the amount of changes that happen on your system without your knowledge. For example, most system values take some special authority to change. If users don't have any special authorities, they won't be able to change a system value. If you restrict access to the Add Job Schedule Entry (ADDJOBSCDE) command, then you know that you, your fellow administrators, and perhaps operators are the only ones who can add a job to the job scheduler. Knowing that your system's configuration is not going to be changed by inexperienced users provides a lot of peace of mind.
Know Who Did What
You probably think I'm talking about the audit journal, and I am, but what I'm touting is that when you get rid of shared profiles, you'll know who took what menu option or ran a particular command. When multiple people have access to the same user profile and are logged on with it at the same time, if you have to chase down a problem with their job, it can be difficult if it's running as the same user. Get rid of shared profiles, and that problem is eliminated.
Additional Information to Help You Debug
Yes, the IBM i audit journal has a lot of information that would be interesting only in the context of security, but there is general information to help you determine what's happened from a system administration point of view. For example, I've sat in countless System Admin cubes where they've received either an email or phone call about some object that's been deleted and help is needed to determine how it got deleted. Enter the audit journal. The Deletion of Objects audit journal (DO entry type) will list when the object was deleted, the program running when it was deleted, as well as the profile. Without the audit journal, you're going to be looking through countless joblogs—assuming they're still around. You may still have to look through a joblog to determine the specifics of what went wrong, but if you start your investigation with the audit journal, you can limit your search to the joblog of the actual job that performed the delete. Other entries that can help you debug system issues include the System value changes (SV), Creation of objects (CO), and Password (PW). We've helped a couple of our Managed Security Services customers identify jobs that were causing profiles to become disabled by using the PW entries to find the IP address of an automated job that was trying to connect to the server with the wrong password.
I hope this has helped you see that there are more benefits to a fully implemented security architecture than the obvious data security and risk reduction benefits.