[IMAGE]
[IMAGE][IMAGE]
Rich Loeber
[IMAGE]
[IMAGE]
This is the fifth chapter of the Ensuring security on i runbook. The aim of this is to provide AS/400 users advice from security experts for the i on how you can advocate for security in your organization effectively, and what to watch out for, and how to review your System i security situation to ensure it's working as well as it needs to be.
[IMAGE]
As a System i security officer, you've spent a lot of time doing two main tasks. First, establishing a security policy and then setting your system up to enforce that policy. Once you have these two tasks set up, then you can sit back and relax .... right? Not really. In the real world, you have business changes to assess against your security policy, you have new technology to evaluate and determine changes in policy that might result from their implementation and the list goes on.
But, what about all that hard word you did to get your initial security policy implemented?
I have found during my career that things have a way of changing over time -- a sort of entropy in the digital world. A security implementation that was perfect once deteriorates over time unless you give it some attention. I found this out on my own server recently when going through the process of moving to a new system. Some of the security setup for specific objects had changed between when they were set up several years ago and when I went to do the migration. I've traced some of it to programmers (i.e.: me) who updated file descriptions without enforcing the right security settings. I'm sure there are other ways this happens too such as file restores that change security authorizations and object ownership.
Ideally, it would be good for you to go over your entire ...
To continue reading for free, register below or login
To read more you must become a member of Search400.com
security implementation periodically to make sure that it is still set up the way you initially designed it. If you recall the process, however, this could be a significant investment in time.
A better solution is to just use existing Security Tools reports to create listings on your system of how the security is currently set up. Scanning a report for items that stand out as different from the others is a lot easier than going back and examining every object to see how it is set up.
The System i has quite a few security reports that you can run from the Security Tools menu (SECTOOLS). Option #20 will get you to the Security Reports menu (SECBATCH). Different options on the menu will produce different reports, many of them very useful when scanning for security implementation entropy. Each of these options prompts for a Submit Job command so that the reports run in batch. Pressing the F4 key from the Submit Job command line will let you review and change parameters.
In the case of the problem that I found on my system, I ran option #11 and then prompted the command to limit the report to a specific library that I needed to check. In my case, I found several objects that should have been secured by an authorization list, but they were only being secured by object authority.
When you get some extra time, take a look through these reports and start running them to see what you find. Chances are very good that you'll uncover some issues before too long.
If you have any questions about this topic send me an email, I'll try to answer any questions you may have. All email messages will be answered.
---------------------------
About the author: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.
