Last month, I talked about the need to test your security setup on a regular basis. That article focused in on testing user profiles. Today, I want to take a look at how you can go about testing your resource security setup.
There are two things you need to test and evaluate on your system. First, you have to make sure that users have sufficient authority to get all of their work done without a problem. Once that has been established, you then need to go back and make sure that users don't have too much authority, thereby compromising the confidentiality issues prompted you to secure specific resources in the first place.
After publishing my previous tip about testing user profiles, I heard from one reader who offered an excellent suggestion. In their shop, for user profile testing, they maintain a special user profile just for testing purposes. If you don't have this set up on your system, I strongly recommend this approach. Before testing, you can enable your test profile and then, as soon as you're done with your testing, you can disable it again. This idea applies when testing profiles and when testing resources on your system.
To test a user profile for sufficient authority, you will have to log on with that profile or your test profile for the group. Make sure the right menu comes up and then try exercising various menu options. Remember, resource security does not get checked until a file is opened, so just displaying menus is not going to get the testing done. Keep track of the operations that you perform, as some of them may have to be reversed within the application files before you end your session. Make sure that the person who owns the application knows about your testing so they can be on the lookout for any unusual transactions that come up in their system. Your testing should verify that the user can add records where they need to create new data and delete records where they should be able to remove data. If you come up with any security problems, note them, make adjustments to your resource security setup and then repeat the testing until it comes up clean.
If a user has access to batch processes, those will need to be tested as well. Great care must be taken in this area as some batch processes are not easily undone in a production environment. You might consider setting up a test environment for these purposes. When running batch testing, review the system operator message queue and the system history log for security error messages. These messages will be in the 2200 and 4A00 ranges for CPF, CPI, CPC and CPD errors.
Testing for too much authority is also very important and probably a little more fun in the process. After all, you have to have a little fun while you're working and pretending to be a hacker is great.
While you are signed on under the profile being tested, check some of the following items:
- Can you use menu options to gain access to a menu where you don't belong?
- Do you have access to the command line?
- Are you able to key in and run CL commands?
- Can you use the CPYF command to create a printout of a data file that you are not authorized for?
- Are you able to run a query tool on your system to get to files that you are not authorized for?
If you are checking resource security for a specific application, you should also log on with a typical profile that should NOT have access to that application and then repeat the above checks. You should specifically be looking to make sure that access to critical and confidential files is denied to users who should not have access. This is particularly important as it applies to query tools since they can, by virtue of adopted program authority, thwart your resource security arrangements.
If you have any questions concerning this tip, feel free to contact me directly. My e-mail address is rich@kisco.com.
Rich Loeber is president of Kisco Information Systems Inc., in Saranac Lake, NY. The company is a provider of various security products for the iSeries market.
==================================
MORE INFORMATION ON THIS TOPIC
==================================
Testing user profiles
Security guru Rich Loeber takes a look at testing user profiles. According to Rich, the best time to test a user profile is when you initially create it. If, however, you have never tested your user profiles, you may want to tackle a project to get the profiles on your system tested on a periodic basis to make sure that they conform to your security objectives.
Getting better control over user profiles
Every iSeries shop has the potential to have active user profiles on the system for users who have left the company. Unless your personnel department is extra careful about global notifications when people leave, you may have a security exposure that you don't even know about. But you can, if you're careful about setting up user profiles, take care of this problem when new profiles are created.
Limiting when a user profile can be used
Each user profile on your system is a window, of sorts, into the
computing environment for your business. Some profiles have a very
narrow and limited view while others have a panoramic scene before
them. Unfortunately, these windows can leave your system wide open for a user to wreak havoc -- either accidentally or intentionally. In this tip you'll learn how you can limit user profiles.
20 ways to improve your system's security
Is your system as secure as it can be? If you think it can be better, check out these hot expert Q&As. Use them to determine if you should be doing more.
