About admin

Founder of Kisco Information Systems

Monitoring For Security Events

By Rich Loeber

Your system is in use by your user community all day long.  Depending on the size of your shop and the number of users, there could be hundreds or even thousands of security decisions being made by your security setup on a minute by minute, hour by hour, day by day basis.  If you’ve done your homework well, those security arrangements will all work to protect your data from being used incorrectly.

But, how do you know when a security violation has been made?

One way is to keep security auditing active on your system and run regular reports from the security audit journal.  In fact, that is a good practice to implement, but it is not going to give you quick feedback when a serious security violation occurs.

When a critical security violation happens, an error notice is posted to the system operator message queue (QSYSOPR).  The problem, however, is that LOADS of messages in most shops go to the system operator message queue and it is easy to loose one in the haze of all that activity.

To address this problem of the security messages getting lost in the system operation message queue, the IBM i OS has an alternate message queue capability set up.  Check your system to see of the QSYSMSG message queue exists in QSYS library.  If you don’t see one, just create using the CRTMSGQ command.

Once the QSYSMSG message queue is on your system, all critical security related messages will also be posted to this message queue along with your system operator queue.  Now, all you need to do is make sure that you end up knowing when a message has been posted.

The quick and easy way is to log on to the system and run the following command:

CHGMSGQ MSGQ(QSYS/QSYSMSG) DLVRY(*BREAK)

Once this is done, whenever a message is posted to the QSYSMSG message queue, it will be displayed on your terminal session as a break message.

But, this could be a problem.  First, it requires that you always be logged on and it limits the number of people who can monitor for security events to one.  A different solution is to create a little CL program to “watch” the message queue for you and then forward the message on to your user profile (or a series of user profiles) when they happen.

This way, you and your security team can find out about security problems in real time and won’t have to wait for audit journal analysis to see that serious security violations are happening.

I have put together a simple little message monitor CL program that works with a set of up to 5 user profiles stored in a simple data area.  If you’re interested in getting a copy of this code, or if you have any questions about this tip, send me an email (rich at kisco.com).

An even better solution is to implement a flexible message queue monitoring software tool such as Kisco Information Systems’ iEventMonitor software.  This will add email and text notification for you and you can implement many of the other features to monitor your system.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Terminal Session Security

By Rich Loeber

Like all modern systems, the IBM i requires a user profile and password before you can log on and use the system.  You might think that this simple requirement would always ensure that only authorized users will have access to your system.  But, with the proliferation of devices that can connect to the system, it is not always that simple.

In the old days, we used to have devices that are now called “dumb terminals”.  To use the system, you’d log on to the sign on screen and when you were done, you’d log off.  You could tell by looking at the screen whether the session was active or not.  If the signon screen was displayed, then the session was inactive.

Today, with a proliferation of PCs, tablets and cell phones and with easy access to Telnet based terminal emulation software, it is not always that clear.  On a PC using IBM i Access, the first time you log into the system for the day, there is an IBM i Access logon that establishes connection from the PC to your host system.  Then, there may or may not be another logon for your terminal session.  If you have your PC set up to bypass terminal sign on to the host, then there will be no second signon process.  Once your connection to the host system has been established, the only way to break it is to either log off from Windows altogether or reboot your system.

There are a couple of potential problems with this configuration.  It makes working with your system a lot easier just like leaving the keys in your car makes getting going a lot easier, but you wouldn’t want to do it on a regular basis.

If you are using bypass signon, once your initial connection has been established, anyone can come by and start up your terminal emulation session and gain access to your system without knowing either your user profile or your password.  If you’re a programmer or a systems administrator, that could be a significant exposure to your system as you will probably have very generous access rights to objects on your system.  If your PC is located in a public or semi-public setting, you should think twice about having this setup.

Another exposure, which can happen when you leave a terminal session active, is that anyone can come along and use the Client Access upload or download functions to gain access to your system, again without knowing your user profile or password.  If you have any virtual drives mapped to your host, those could also be compromised by someone using your PC without your knowledge or approval.

One simple solution is to activate your PC’s screen saver with a password requirement to unlock the keyboard when it goes into screen saver mode.  That way, if you go for coffee and get delayed by a dumb question from the boss, the screen saver will kick in and protect your system in your absence.  The problem comes from user systems that you, as security officer, are responsible.  Each user can probably reset their screen saver settings on their own, thereby defeating this important additional security measure.  A periodic inspection of all PCs installed in public and semi-public settings for these exposures would probably be a good idea.

Most terminal emulation software for use on tablets allow you to build in a macro for the signon process.  So, anyone picking up your tablet, might be able to establish a connection to your system.  If tablets are available in public areas, then disabling the signon macro function would be a good idea.

If you have questions about details of the report, feel free to contact me directly by email (rich at kisco.com).

Is The Light On, but the Door Unlocked?

By Rich Loeber

IBM i owners regularly boast about the security built into their systems, and rightly so, but if you don’t implement and use the features, they’re not going to do anything for you.

I have mentioned before that I live in upstate New York, in the heart of the Adirondack Mountains.  In our neck of the woods (literally), security is not much of an issue for most people.  In fact, most of our neighbors never lock their homes or cars since theft is just not a problem.  At our house, we have extensive outdoor “security” lighting installed, and we use it whenever we go out at night.  We even have one light on a motion detector that comes on automatically in case we forget the other lighting.  But, even with the lighting on, we usually leave the door unlocked just because it is easier to get back in when we return home.  If we ever get ripped off, we shouldn’t be surprised as to how it happens.

I’m surprised, however, when I hear about and work with IBM i shops that have this same approach to computer security.  An alarming number of shops just do not pay attention to security issues and are surprised when a problem develops.  The IBM i OS provides robust security capabilities and tools, but too often they go unused just because it is easier without them.

I remember an IT director I knew, I did some consulting work for his company.  I encouraged him to move up to security level 30 and implement object level controls on several mission critical files on their system.  He gave it a try and, without any planning, moved the security level from 20 to 30 and IPL’d their system.  When nobody could sign on except the security officer from the console, he backed the system back to level 20 and never tried it again.  It would still be running at level 20 today if the company had not gone out of business.

My company sells a number of security solutions for the IBM i market.  I am always amazed at the number of customers who buy our solutions and then never fully implement them.  Some of these, it turns out, purchased our software just to satisfy an audit recommendation or someone else’s concern.  For others, they probably just don’t have the time or the people resources to do the implementation correctly, so they shelve it or put it on the back burner.

The same is true for the shop that never bothers to set up the IBM i OS security.  They’ve made a significant investment in IBM i, but are not bothering to use what they’ve paid for.  Security is just as much of an investment as the computer hardware that it runs on.

You would probably never think of leaving the front door of the building open all night with the lights on.  By that same measure, you should not leave your system exposed to intentional or even accidental abuse when you have it within your grasp to correct the situation and you have all the tools to do so at your disposal.

If you’re reading this and see your own shop (or even yourself), don’t worry.  Its not too late to do something.  Take an incremental approach and develop a plan.  Don’t rush into it, like my friend above, and do something you’ll regret, but don’t just sit there leaving your system exposed.  The important thing is to get started and stop putting this off or waiting for enough resources or budget support.

If you have questions about details of the report, feel free to contact me directly by email (rich at kisco.com).

Hacking Report For Our IBM i – A Current Update

By Rich Loeber

In 2013, we issued quarterly reports about attempts at hacking our IBM i system.  At the outset of that series, we explained that Kisco keeps a lone IBM i server connected directly to the Internet in order to test it’s SafeNet/i exit point security software in a real world environment. This article will update the information from that study and review the current state of observed intrusion attempts from more recent activity.  The landscape of what we are seeing in the way hacks are being attempted has changed quite a bit since our last report.

The biggest shift that we have observed is a significant fall off in hacks attempting to gain access using brute force FTP attacks.  However, the overall access attempts have increased from an average of 14 times as day in 2013 to nearly 50 times a day now.  Even after a recent change in IP address for our server, the hackers found the new location almost right away.

Thanks to our SafeNet/i exit point network control software, we successfully thwarted all unauthorized accesses.  Of these, 351 were attempts to gain access via FTP and another 6,009 attempts were to get a Telnet signon session during the analysis period that went from October 2016 through early February 2017.   The big change here is that hackers seem to have given up on FTP Script attacks in favor of just pounding away at the Telnet port.

For the FTP attacks, the profiles named ADMINSTRA and ADMIN were the most popular ones used.  This was true for the 2013 study as well.  Other profile names used included ANONYMOUS, FTP, and WWW-DATA.  Once again, these users were consistent with profiles tried in the 2013 study.

Our SafeNet/i Telnet exit point stops access before a signon screen is presented, so all we have to look at for the 6,009 Telnet attempts that were thwarted is the source IP address that was used.  We continue to see certain IP addresses with repeated access attempts.  The leading violator for this study period traced back to the Asia Pacific Network Information Center in Australia.  This hacker attempted to open a Telnet session more than 1500 times over a 2 hour period.

Some good news from the study, which we also observed in 2013, is that most hackers have no idea that our server is running IBM i OS.  No attempts were observed to connect to the system using connection points other than FTP and Telnet.  It may be that this is because hackers have so much success using FTP or Telnet, but it indicates that a lot of other avenues of access are not being employed, at least in our experience.

For the full study period, our server posted close to 300 thousand network transactions.  This is nothing in today’s computing environment, some of our customer’s servers can record that level of activity in just a few minutes.  But, 2.1% of those network access attempts were not authorized by us.  This is up from 0.5% for our 2013 study.  That is a four fold increase!  You have to take hackers seriously.  Failure to do so will get you in the headlines as the next Yahoo.

If you have questions about details of the report, feel free to contact me directly by email (rich at kisco.com).

Securing the Save/Restore Function

By Rich Loeber

On today’s open IBM i system, the save/restore function can be used to transfer critical files and programs between systems.  With this comes the specter of data and program theft, so it is important to make sure that this avenue of data transfer is secure.

Most IBM i installations run a scheduled save of their system to transfer files, programs and other objects to tape or other media for safe keeping.  Saving the system on a scheduled basis is just good practice since the catastrophic loss of a single disk unit on your system can mean that you loose everything on your system.  Since introduction, IBM has hounded its customers (and rightly so) to do a regular save on your system.  Once objects have been saved, you can also use IBM i/OS functions to restore objects from the saved media.  This can be part of either a full system restore or to recover objects that get damaged or corrupted in any number of ways.

The problem, from a security viewpoint, is that once data and programs have been saved to offline media, they can then be transported to another system and restored.  Mission critical information must be guarded to prevent theft from occurring.  Physical security on the media is critical for this, but I want to talk more about securing the save/restore function on your system.

Today, with an open TCP/IP world in which we work, you can save a critical file to a save file and then FTP or SNDNETF it to any system in the world.  IBM i software developers regularly use the FTP save file to transfer program updates onto customer systems.  With the ease of data transfer that this provides, restricting the use of the save/restore functions on your system is more critical than ever.

The first line of defense for this is found in the user profile.  Before someone can use the Save/Restore commands in the IBM i/OS, they must have *SAVSYS special authority in their user profile.  If you have not done so, I recommend that you review your user profile base to find out which user profiles have *SAVSYS configured and make sure that they have a real business reason for it.  Certainly, your operator(s) will need this authority, as will anyone who runs the scheduled backup or restore functions.  But, I would be hard pressed to think of any other users in a regular environment (including programmers) who really need to have this ability.  I know some programmers are going to howl at this, but they will have to be able to make their business case before you give them these keys to the kingdom, so to speak.  You can always look at granting them this authority on an as needed basis, revoking it once the task to be done has been completed.  Some shops even keep a special user profile around for this use.  When needed, they activate it temporarily and the deactivate it with full documentation kept on how it was used.

The next place to look for restricting Save/Restore use on your system is the IBM i/OS authority setup for the the RSTxxx and SAVxxx commands.  The RSTxxx commands are shipped from IBM with public *EXCLUDE, but the SAVxxx commands have a public setting of *USE.  You might want to consider setting up an authorization list for these commands and then listing the users that you want to be able to use them in the list.  Once the list is built, associate it to the commands and then change the SAVxxx commands to be public *EXCLUDE.  (You can also do this with direct authority, but having the authorization list will make IBM i/OS upgrades easier to implement.)

There are several system values that you should take a look at too.  The QALWOBJRST value lets you restrict certain objects at restore time.  These include system-state programs, programs that adopt authority and objects with validation errors.  QVFYOBJRST controls restoring signed objects.  QFRCCVNRST wil force object recreation on certain objects at restore time.  Lastly, you can specify *SAVRST in the QAUDLVL command to audit save restore operations on your system.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Hiding Places for Malicious Code

By Rich Loeber

The last time I wrote, it was about tracking down hidden programs on your system that you might not know about (see article).  That time, it was trigger programs that could be sitting on your system just waiting for a specific event.  But, as I’ve thought about this issue since then, there are other places where someone could “hide” a call to a malicious program and easily get overlooked.

This time, we’ll look at two other areas for concern.  These are the system job scheduler and exit programs.  Both are ways that someone intent on doing harm to your system could hide some malicious program waiting for something to happen so it can jump out and cause problems.  In each case, the IBM i OS contains a way to review the programs that are sitting there and you should take a look periodically to see how each is being used on your system.

The IBM i OS has had a nice, easy to use job scheduler built into it for a long time now.  Most shops where I’ve done consulting work seem to know about it and use it for regularly scheduled jobs.  But, that also means that the programming staff is aware of it and could misuse or abuse it.

To review the current contents of the system job scheduler, use the i/OS command Work with Job Schedule Entries (WRKJOBSCDE).  This command will display information about every job in the system job scheduler.  It will tell you what the job is, how it is invoked and when it is next scheduled to run.  You should review each entry to make sure that you know what it is doing and when it is next scheduled to run.  A suspicious job, to me, would be one that is not set to run for quite a while in the future.  Most scheduled jobs happen frequently, either on a daily, weekly or monthly basis.  If you see something on a different schedule than one of these, I’d pay particular attention.

Another place you need to periodically review are the registered exit point programs on your system.  Exit points are hooks into i/OS processes.  These are provided in the i/OS so customers can add their own customized processing called from the OS during normal operations.  For example, many of the third party network security products now available on the market (including our own SafeNet/i) use exit points to add security checking to the various network operations in i/OS.  The potential problem is that a rogue program could get registered to an exit point just waiting for a specific OS event to occur before it jumps up and gets noticed.

To review exit programs registered on your system, use the i/OS command Work with Registration Information (WRKREGINF).  This will display a list of the i/OS exit points on your system, and remember that they are different for every level of the OS.  For each exit point, use the option ‘8′ to see if there is a registered exit program for the exit point.  If you find any, make sure that you know what they are there for.  Don’t be surprised to find some exit programs already registered.  If you are using a network security system, you should find many programs registered.  Also, some come registered with i/OS.  For example, you will find that the IBM product Service Director, uses some of the exit points as does the i/OS Mail Server Framework (MSF).  Just make sure that you can identify each program that shows up as a result of your review.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Can You Trust All Those Trigger Programs?

By Rich Loeber

If you’ve seen the movie “Troy”, or if you were paying attention in history when you were in school, you know that the Greeks brought down the city of Troy with the gift of a large wooden horse.  Of course, unbeknownst to the Trojans, the horse was filled with soldiers and as soon as things settled down in Troy, the soldiers broke out of the horse and took the city.

These days of rampant computer viruses, worms and other malicious programs moving their way around the Internet, the concept of the Trojan Horse is alive and well.  But, you say, I’m sitting here working on my completely safe and secure IBM i system running the most secure operating system in town!  These things can’t affect me.

Think again.  A malicious program can still get written and installed on your system, hidden away waiting for the right event to come out and strike.  How, you ask?  As a trigger program.

When I heard about this, I was much like most of you thinking that this just didn’t apply to me.  But then I ran the audit report that IBM is included in IBM i OS.  Boy, was I surprised at the number of trigger programs that are installed on our closed development system.  I thought that the report would come out empty.  Lo and behold, I got an eleven page report with information on more than 110 trigger programs in place that I had no idea were there.  Granted, most of them appear to be parts of the IBM i OS, but I did find some application triggers that I did not know were there.  Fortunately, I found that none of these were malicious, but I had my doubts for a while since one of them was written by a programmer who left our employee under somewhat of a cloud.

The IBM i OS includes a command that lets you keep track of the trigger programs that are installed on your system.  The command lets you run a master list of all trigger programs and then, periodically, just list the trigger programs that are new or have changed.

To get started on understanding the trigger programs on your system, run the following command:

PRTTRGPGM LIB(*ALL) CHGRPTONLY(*NO)

This will produce a baseline report of all the trigger programs on your system.  Review the listing closely and make sure that you know what each of these programs does.  If you see a program that you suspect, track down the source code and make sure you know what it is about.  If it is from a third party software provider, get a statement from the software vendor that describes what the program is doing.  Since trigger programs react to events, they are good candidates for malicious actions just waiting for the right action to happen on your system.  Be prepared that the command may take a long time to run and you might want to consider running it in batch.

Once you have your baseline report, you can then periodically run the same command just changing the CHGRPTONLY parameter to *YES.  This version of the report will list changes and new trigger programs on your system.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Password Levels

By Rich Loeber

Ever since the introduction of IBM i/OS V5R1, a system value for “Password Level” has been available (QPWDLVL).  This value lets you have control over the kinds of passwords you use on your system and how the system treats them.  Using the features provided through this value, you can implement passwords of up to 128 characters in length.

Why would anyone ever want to have a password that long?  I asked myself that very question, but when I started looking into the issue, some things jumped out at me that make perfect sense.  With a long password, you can implement a “pass phrase” rather than a password.  The implementation of the long passwords allows for case sensitive passwords and will accept embedded blanks and every character on the keyboard.  This complexity in your password can easily increase the difficulty for people trying to break into your system.

The system value that controls this is QPWDLVL and it can have the following settings:

“0″ – the default setting which sets up 10 character passwords and is what you are probably used to now if you’ve been working with the IBM i system for some time.

“1″ – uses the same 10 character passwords, but the IBM i/OS NetServer passwords for Windows Network Neighborhood access are not kept on the system.  If your system does not communicate with any Win-X machines using Network Neighborhood, you might want to consider this.

“2″ – allows you to have passwords of up to 128 characters that are comprised of any character on the keyboard, are case sensitive and may contain blanks (but not all blanks).

“3″ – implements the same level “2″ passwords but adds the restriction on Windows Network Neighborhood that level “1″ includes.

If I were implementing a new system, I’d seriously consider adopting level “2″ as a standard right from the get go.  But, most of you out there in IBMiLand have an embedded culture of 10 character passwords with specific rules in place that you have your users well trained for.  The good news is that you can move to a new password level as long as you do a little planning in advance.

Moving from level “0″ to level “1″ is pretty simple and does not require much planning.  This will simply eliminate the storage of another set of encrypted passwords on your system.  Moving from level “0″ or “1″ to a higher level should take some planning before you take the plunge.

One of the nice things is that whenever you create a new profile, the IBM i/OS creates the associated level “2″ and level “3″ passwords just in case you want to move to the higher password level.  So, the codes are already there on your system.  The possible downside is that embedded code and certain client software may not get along with the longer passwords.  Consequently, if you decide to make this change, you really should get a full backup of your current security profiles and passwords using the SAVSECDTA command.  This way, if things go south on you, you can recover back to where you are now quite easily.  You can use the DSPAUTUSR command to check your profiles for users with passwords that will not work at the higher levels.  There is a good, comprehensive discussion on how to move to a higher password level in the IBM i/OS manuals “Planning and setting up system security” or “Security Reference” that you should also take a close look at.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Testing Resource Security

By Rich Loeber

Last month, I talked about the need to test your security setup on a regular periodic 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 that 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 that 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 for each group on the system that is used 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 your 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 to make sure they have 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 about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Testing User Profiles

By Rich Loeber

If you’re reading this, you’re probably either a Security Officer or working in the security group in your IBM i shop.  I’ll bet, however, that you didn’t start your career in the security area, but worked your way into your current position, starting as a programmer or a database administrator or some other related field.  In your earlier positions, I’m sure you learned a lot of principals about testing.  Don’t let this fall by the wayside in your current position.  Security testing is just as important as application testing.

Today, we’ll take a look at testing your user profiles.  In future articles, I’ll also be taking a look at other testing regimens for your security setup.

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.  This article will assume that you have your user profiles organized into groups with group profiles active.

As with all testing, the objective is to check and make sure that the security setup for a user profile (or group) is meeting the objectives you designed.  To do this with a new profile, make sure that you set the password to a temporary code and that the PWDEXP parameter for the profile is set to *YES.  Using this method, the system will allow a single signon with the temporary password and then prompt you during signon to change your password immediately.  When you signon to test the profile, you can then change the password to the user’s final password or to another temporary code.  If you do assign a new temporary code, you’ll have to set the PWDEXP back to *YES when you’re all done.

The first thing to check on any new profile is to make sure that the signon completes successfully.  If it fails, look in the special QEZJOBLOG output queue for a joblog for the failed logon session.  It is amazing what a joblog can tell you about failures on your system and a close examination of the joblog starting from the top should reveal any problems that have happened to cause the logon process to fail.  Typical problems you will encounter include missing or misspelled library names, incorrect initial menu names and incorrect initial program references.

Once you’ve signed on correctly, then you should exercise the profile to make sure that it meets your objectives.  Ask yourself the following questions as you work with the new profile:

  • Is the right menu displayed?
  • Does the user have access to the command line?  If yes, should they?
  • If an initial program was called for, did it execute correctly?
  • What happens when you press the Attention key function?  Is it what you want the user to see?
  • Where is printed output going for the session?  Is this where you wanted it to go?
  • What happens when you attempt to run the application or applications that this user should be using?
  • Are there any system tasks that the user should be able to run?  Can they?
  • Are there specific functions that the user should be barred from?  Can you access them?
  • Can the user access their printed output spool file?  Do they have access to view other user’s spool files?  Should they?
  • Check the user’s desktop environment for remote access tools.  Using the user profile, can the user access data on your system that they are not authorized for?

Make notes for yourself on any issues uncovered, then go back and make any changes that need to be done to bring the profile or group into compliance with your security objectives.  If you detect any problems, be sure to repeat the test until everything is OK.  At that point, you can turn the profile over to the user.

If you have never tested or audited your current profiles, you can use this same method but you will have to warn the users that you are doing a review.  You can use the PWDEXP parameter on the user profile to help with this testing.  Change the user’s password to a temporary code for your testing logon.  Once you’ve completed your test, change the PWDEXP parameter to *YES and set a temporary code that you’ve already told your user about.  Then, the next time they log on to your system, the IBM i OS will ask them for a new password and they’re back in business with little interruption to their daily job tasks.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.