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.

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.

Controlling Adopted Authority

By Rich Loeber

IBM i programs have a setting when compiled that controls the user profile that will be used for security reasons when that program runs.  You may think that your security configuration is all set and that you’ve made a final determination as to which users are allowed to have access to what objects on your system.  But, if a program on your system is compiled with the USRPRF attribute set to *OWNER, then all your preparation work may be out the window.

The USRPRF parameters for most program compilation commands is set to a default value of *USER on most systems.  This is the way it comes from the factory although it is easy for the default setting to be changed.  When programs are compiled with the *USER setting, then you can count on your object security setup to provide the proper control over access to objects on your system.  When this gets changed, however, then the access controls are based on the owner of the compiled *PGM object and not on the user profile of the person that is running the *PGM object.  (Note: This also applies to *SQLPKG and *SRVPGM objects, but for the purposes of this article, I’m just referring to all of these generically as “programs”.)

This situation is called adopted authority.  There are lots of good reasons why you would want to do this.  For example, you may have a CL program that creates backups of your system that is run by your night operator.  You may not want your night operator’s user profile to have all object authority, so you compile the CL program under a user profile that does have all object authority with the USRPRF parameter set to *OWNER.  Then, when the night operator runs the backup, it goes off without a hitch.  While the backup is running, it has access to the objects needed to complete the backup but the night operator profile is still restricted.  A lot of third party software developers use this technique to make sure that their programs can run without authority problems.

To make sure that your security is not being compromised by adopted authority issues, you should do a periodic review of programs that use this technique.

The first step is to identify the user profiles in your system that have all object authority.  This step alone might produce some interesting results that will surprise you.  One quick way you can do this is by running the following command:

DSPUSRPRF USRPRF(*ALL) OUTPUT(*OUTFILE) OUTFILE(QTEMP/USRPRF)

This will create a temporary physical file named USRPRF in your QTEMP library.  Once created, you can scan this file for the value *ALLOBJ in the first 7 positions of the field designated as UPSPAU.  Any query tool that you like should give you a quick report on what you’re looking for.  Check each profile listed to make sure there are no surprises.

Then, to see if there are any programs that adopt any of the profiles on your list, use the DSPPGMADP command for each profile.  This command supports on-screen display, print and *OUTFILE output.  Use the form that best suits your needs.  At a minimum, you should check for programs that adopt the QSECOFR user profile.  The command to review this looks like:

DSPPGMADP USRPRF(QSECOFR)

Once you have identified programs that run under a user profile that has all object authority, you should then determine if the requirement for adopted authority is absolutely necessary.  In some shops where I’ve worked, I have identified programs adopting the QSECOFR profile because it corrected a problem during testing and was just left that way in production.  One obvious problem would be if the program in question has an option to present the user with an IBM i command line.  In this situation, the user then has full access to your system that goes right around your careful security setup plans.

For third party software, contact your software provider and ask about the adoption situation.  A good software provider should have a ready answer for this question.

When you’ve identified a program that needs to be changed, you don’t need to recompile to make the change.  A simple Change Program command will work in most instances.  Use the following command to change from adopted authority to user authority:

CHGPGM PGM(MYLIB/MYPGM) USRPRF(*USER)

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.

Limiting When A User Profile Can Be Used

By Rich Loeber

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.  Some profiles can only look while others are allowed to look, pick things up, move them around, make changes and even throw them away.  Some only have access to a single library while others, perhaps even you, have the keys to the Kingdom.

As a security officer, you’ve probably given this a lot of thought already and you already have your profiles set up with the exact permissions necessary.  Users are allowed enough access to fulfill their job descriptions but not so much that they can wreak havoc for your organization either accidentally or intentionally.  And, to a large extent, your trust of the person behind the profile plays a large roll in how much access you give them to your system.

Problems come up, however, when a profile is compromised and is used by someone other than the assigned person.  When this happens to a profile that has the panoramic view of your system, real trouble can ensue.

The IBM i OS on your IBM i system has a nice little feature that can give you improved control in the event of a compromised profile.  This feature, the Activation Schedule, lets you specifically tell the system what days and what hours in the day that a profile can be used.  If a user profile is compromised, the chances are very good that the incorrect use will be attempted during off hours.  If the profile in question has been posted to the system Activation Schedule, the profile will not be available for use during the off-hours time frame.  This extends not only to terminal session signon but to all server activity, such as FTP, the system file server, etc.

There are two commands that you use to maintain the system Activation Schedule.  The “Change activation schedule entry” command (CHGACTSCDE) is the main command for maintaining the schedule.  This lets you add a user profile to the list or change a profile that is already on the list.  Once a profile is on the list, a message will be sent to the user profile that established the entry each time the profile is activated and deactivated.  When you create the entry, you specify the time of day when you want the profile available for use.  The system will activate the profile at the given time and then automatically deactivate it at the closing time that you enter.  You can specify this time for all days of the week or for given days of the week.

The other command that can help you with this is the “Display activation schedule” command (DSPACTSCD).  This command lets you review how your Activation Schedule is set up.  You can look at it interactively or create a report of the schedule.

When you first set this up, nothing will happen right away, so be prepared for that.  The system will post jobs into the IBM i system job scheduler to do the actual activation and deactivation.  The next time one of the time of day thresholds is passed, the activity to activate and/or deactivate users will start and you will begin to receive status messages from the system.

Using this feature of the IBM i OS, you can close the window of opportunity when a compromised profile can be used and make it more difficult for mischief makers to do their thing on your system.  One thing to keep in mind, if you adopt this process, is that you may need to make special arrangements when your users work a different schedule than normal, such as overtime work.  During these times, you may have to update the Activation Schedule to accommodate different work hours.

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.

Search For The Guilty Party

By Rich Loeber

Part of computer security is prevention, and a good access prevention policy along with good controls will go a long way to protect your data from improper access and use.  But, people with proper authorization make incorrect data changes that can wreak havoc on a system.  At times like that, it is sometimes nice to be able to backtrack and see who did what and when they did it.

Here is an easy way to implement a tracking system on an IBM i database without any significant programming on your part.  This technique takes advantage of the IBM i database audit journal features.

First, you have to create a Journal Receiver and a Journal.  In this example, we’ll set up to track data changes to a file named CUSTMSTR in library MYLIB.  Use the following commands to create these objects:

CRTJRNRCV JRNRCV(MYLIB/CUSTMSTR)

CRTJRN JRN(MYLIB/CUSTMSTR) JRNRCV(MYLIB/CUSTMSTR)

Now, you can activate tracing on your physical file by processing the following Start Journal Physical File command:

STRJRNPF FILE(MYLIB/CUSTMSTR) JRN(MYLIB/CUSTMSTR) IMAGES(*BOTH)

At this point, the database journal is active for your file and all activity against that file will be tracked and captured in the Journal Receiver.  Now, use your application program to work with your database file.  Make some file inquiries and also perform some record changes.  When you’re done, use the following command to take a look at the file tracking information:

DSPJRN JRN(MYLIB/CUSTMSTR)

You will see several different forms of tracking information displayed.  Each time the file is opened, closed, read and updated, an entry will be inserted.  The first few entries just track the fact that journaling has been started for the file.  After those, you will see the results of the testing transactions that you performed.

To review file changes, look for the audit records with type codes “UB” and “UP”.  The UB record shows you a record image BEFORE an update was posted and the UP record shows the record image AFTER an update was posted.

In your search for the guilty party, the DSPJRN command leaves a lot to be desired.  To give you a better way to look at before/after data changes, you can transfer the DSPJRN information into a database file and then use your favorite database tool to create more usable information.

To create the database for your query tool, run the following form of the DSPJRN command:

DSPJRN JRN(MYLIB/CUSTMSTR) OUTPUT(*OUTFILE) +
OUTFILFMT(*TYPE4) OUTFILE(MYLIB/CUSTMSTRJ)

In this sample, the database version of the Journal now resides in the database file named CUSTMSTRJ.  Use your query tool to select records with type codes UB and UP (the field name to select on is JOENTT).  If your database file record length is exceptionally long, you may have to parse the record data information to get at what you are looking for, but the report generated should point you to all of the record changes posted to the file and you should be able to sort out who did what and when they did it.

If you prefer an easier way to handle all this, take a look at iFileAudit from Kisco Information Systems.  iFileAudit will automate this entire process and show you file updates on a field by field basis telling you all of the who, how, when and where information as you search for the guilty party.

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.

 

“i Spy” – Checking up on a specific user

By Rich Loeber

For some reason, my career in Information Technology frequently included responsibility for the company telephone system.  Oftentimes, I would end up with a department head closeting himself in my office to obtain a report of telephone activity for an employee that they suspected of some malfeasance.   Most of the time when this came up, I had the luxury of having the data already collected in a call accounting software package and could just run a report and send the department head on their way.

In this day of heightened security consciousness, I can fully expect to see this scenario played out with data access as the expressed concern of this same department head.  Unfortunately, software for full implementation of security reporting can be very pricey.  But, if you just want to check up on someone, the IBM i has very good auditing capabilities that you can use down to the individual user level.  And, you can do this without a major headache.  You can target a specific user and leave the others out of it.

Setting Up Security Journaling

The IBM i OS lets you track a lot of different system security events and you can explore all of these in the OS Security Reference manual.  For our purposes, however, all we’re looking at it how to set up security auditing for an individual user.

If you have already used audit journaling, you can skip to the next heading in this tip.

To start security audit journaling, you can use the IBM i CHGSECAUD.  For our purposes, you can use the following command:

CHGSECAUD QAUDCTL(*OBJAUD *NOQTEMP *AUDLVL)

If your audit journal does not exist, this command will set up the journal receiver and create the system audit journal.  Two system values will also be updated.

Journaling Your User

Now to start tracking your suspicious user.  First, you’ll want to start auditing for the specific user.  You can do this with the following command:

CHGUSRAUD USRPRF(USERNAME) OBJAUD(*ALL)

You should key in this command and prompt it to see if there are additional events that you want to track in the AUDLVL parameter.   You should probably include *CREATE and *DELETE options at a minimum.

The final step in your setup is to specify user audit tracking for the set of objects that you want to track for this user.  You can do this with the CHGOBJAUD command.  For user profile audit journaling to work, the objects must be set to OBJAUD(*USRPRF).

Viewing the Audit Information

Once you have the audit journal active, you can view the tracking information on-line using the following command:

DSPJRN JRN(QAUDJRN)

If you have an active audit journal with a lot of activity for many users, you can limit the information displayed by using the USRPRF parameter.

As with all security matters within the IBM i OS, this is tip just scratches the surface.  You can see more information in the IBM i Security Reference manual.

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.

The Enemy Within

By Rich Loeber

For many, this has been a hard year.  In many IBM i shops, we have been forced to find new ways to save on expense while still being asked to provide the same level of computing support as in past years.  This is not always easy, and I have seen evidence that some shops are sacrificing security to conserve on their budgets.

One significant area where I’ve seen this is on data asset protection.  More than one shop that I’ve been in touch with this year has decided to put their complete trust for data asset protection into their firewall at the expense of all other ways of protecting their data.

With your system attached to a network on a full time basis, and with the network interconnected to the Internet on an around the clock basis, trusting your data protection to a single piece of technology is just a bad idea.  Imagine yourself living in a neighborhood with a high crime rate.  Would you have a single lock on your door?  Like most people in this situation, wouldn’t you use two or three (or even more) methods to keep your doors and windows secured?

When your system is connected to the Internet, you are in a high crime neighborhood and you need to use the same approach to protecting your data.  When someone breaches your single point of protection, that could leave your entire system open to malicious abuse.

Also, trusting your data protection to just a firewall completely ignores the issues of intrusion from sources within the “protected” network.  In a small shop, where you can see who is in and who is doing what, maybe this is not much of a concern, but in today’s large shops with widespread deployment of networks, you cannot keep an eye on what everyone is doing.  Anyone who is within the “secure” network can find access to your system using a variety of tools available to today’s savvy computer users.

If you have deployed your firewall as your primary defense against intrusion, you are completely ignoring the enemy from within your organization.  Most security experts will tell you that at least half of all intrusions today (some say more) come from within your organization.  With the ease of downloading data and storing it in a convenient portable form, anyone in your organization could easily take home critical data assets from your organization on a laptop or even on a USB drive that looks like a key fob.

The question you need to ask yourself is, am I saving money wisely or am I thinking short term just to look good.  In today’s environment, you simply cannot put all of your eggs in one basket.  To adequately protect your system, you need to present multiple hurdles for your enemies to overcome.  If they get past one, there is a good chance that the next one they encounter will defeat them.

The good news is that your IBM i comes with a lot of tools available to you so you can build these additional lockouts.  To protect yourself from the enemy within, you will need to build strong object level access controls.  You will need to rigorously enforce a policy of no user profiles with *ALLOBJ authority.  You will need to also enforce a policy of password rotation on a frequent basis with password controls that prevent the reuse of passwords and the use of passwords that are easy to guess.  Lastly, the strong lock of exit point controls will also help keep your data safe.

All of these options, and more, are open to you.  Some may cost you some money, but the alternative of seeing your organization on the front page of the paper for data theft would be much more expensive in the long run.

If you have any questions about this topic, you can reach me at rich at kisco.com, I’ll give it my best shot.  All email messages will be answered.

Tracking Changes to User Profiles

By Rich Loeber

A blog reader recently contacted me and asked how they could track changes to user profiles.  They had an audit requirement to be able to prove that when a user was dismissed, their profile was disabled or removed from the system on their IBM i server.

When I got the call, I was up to my eyeballs in work and did not give them a good response.  I suggested that they code and test exit programs to attach to the system exit points for user profile maintenance.  While that solution might work, eventually, it is like wielding a sledge hammer to crack open an egg.

When I had more time to think about it, the easy solution came to mind.  Use the information in the system security audit journal!

When the security audit journal is active on your system (a topic for a different blog post), then whenever a user profile is created, updated or deleted, records are added to the journal to record the fact.

So, if you want to track the history for a user profile, it is entirely possible to get all of the significant changes to the profile using the audit journal.  There are two specific journal audit records that you will need to consider when reporting on these events.

Audit journals are identified by a Journal Code (a one character alpha code) and by an Entry Type (a two character alpha code).  For our purposes here, we are going to look at journal records for Journal Code T (Audit Trail records) and Entry Type CP (Create, change, restore user profiles).  If you also want to look at profile deletes, you can look at the T-DO records for objects with object type *USRPRF.  The rest of this tip shows you how to work with the T-CP records, but a similar approach can be used for the T-DO records.

To trace user profile history using the T-CP records in the system security audit journals, I simply extracted them to a database file and then ran a report on them, sorting them by user profile and time stamp.

To produce the database file, first create an empty database file on your system using a system provided shell file for the CP journal records.  There are several of these available depending on the level of detail that you want, I used the shell file named QASYCPJ4.  You will find this in the QSYS library.  You can create your shell file using the following command:

CRTDUPOBJ OBJ(QASYCPJ4) FROMLIB(QSYS) OBJTYPE(*FILE)
TOLIB(QTEMP) NEWOBJ(TCPFILE)

This will create the file in your QTEMP library, but you can place it anywhere that is convenient for you.

To populate this database file with the right information from the system audit journal, it is a simple matter of using the Display Journal command (DSPJRN) selecting the right filter information.  The following command should work for most systems:

DSPJRN JRN(QAUDJRN) RCVRNG(*CURCHAIN) JRNCDE((T))
ENTTYP(CP) OUTPUT(*OUTFILE) OUTFILFMT(*TYPE4)
OUTFILE(QTEMP/TCPFILE)

Some things to note.  Using the *CURCHAIN parameter will pull all information from all journal receivers for the security journal that are currently available.  If you want to limit the extract to a specific period of time, there are additional filter parameters available on the DSPJRN command.  The output file format of *TYPE4 will format the data correctly for the shell file that we are using.  If you want more information, try a different format, but you will also have to use a different shell file.

Lastly, all you need now is to review the database file or list it.  Select the fields that you want to report on; there are a lot to choose from.  I’m old school and I created a query report using WRKQRY.  If you want a copy of it, just let me know and I’ll send it to you.

If you have any questions about this topic, you can reach me at rich at kisco.com, I’ll give it my best shot.  All email messages will be answered.