“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.

Configuring Telnet for SSL

By Rich Loeber

I was recently asked to secure remote access for 5250 terminal sessions for one of my customers.  I did not have any experience securing Telnet on the IBM i, but I located some good documentation from IBM and was able to get the Telnet connection secured fairly quickly and easily.  This tip will show you how.

Many IBM i shops still use the 5250 terminal interface for administration and operation of their systems.  For them, the interface is well known and comfortable.  The problem is that when used for remote access, the Telnet data stream is passed as open text and it is easy for someone with malicious intent to snoop in on the data stream and capture user profile and password information.

Fortunately, there is a way on the IBM i to encrypt your 5250 terminal sessions by implementing SSL (Secure Sockets Layer) for your Telnet connections.  The IBM i uses a Telnet connection to support your 5250 terminal sessions.

There are two steps that you need to complete in order to set up SSL for Telnet.  Part one involves configuration work on your IBM i server.  Part two is what is needed on your client (your PC) in order to use the SSL connection.

The server configuration will require that you have option #34 (Digital Certificate Manager or DCM) of the base OS installed along with the HTTP server functions.  On our 6.1 test box, the HTTP Server is 5761DG1.  Before plunging into the project, I strongly recommend that you make sure that you have the latest HTTP server PTFs installed.  When we first tried to use DCM after upgrading our OS, it would not work and we needed the PTFs.

To do the configuration work on your host, we found the following article with step by step instructions from IBM and I recommend that you use this procedure:

http://www-01.ibm.com/support/docview.wss?uid=nas8N1010449

This process will require you to set up a self-issued digital certificate on your system and then assign it to several applications, including Telnet.  If you have never used the Digital Certificate Manager on your system, be prepared to take some time to get used to it.  The instructions from IBM are actually quite good.

After you get this configuration work done, make sure that you update the Telnet Attributes on your system using the CHGTELNA (Change Telnet Attributes) command.  When starting, make sure that the Allow Secure Socket Layer (ALWSSL) parameter is set to *YES.  This will allow both SSL and non-SSL Telnet connections.  Once you are satisfied with the way the SSL connection is working, you can consider changing this setting to *ONLY which will then refuse non-SSL connection attempts.

Once the server configuration work is done, you can move on to the client configuration work.  Again, I found a good set of instructions from IBM on this that you can access here:

http://www-01.ibm.com/support/docview.wss?uid=nas8N1011018

This process may require that you install additional Client Access components on your PC, so access to your Client Access install CD may be required.  The process will call for your to import the certificate you created into your PC and then reconfigure your terminal session to use SSL.  When importing the certificate, there is a standard password to use.  That instruction is easily missed, so watch out for it.

In addition to setting this up for my customer, I also took the long delayed step of setting this up for my own server.  It is something I should have done long ago and I encourage all IBM i shops to adopt this standard for remote access Telnet session.

After initially posting this tip, a friend contacted me to suggest that implementing SSL on Telnet also helps customers with their PCI compliance requirements.  PCI requires 2 factor authentication.  He reported that one of his customers was able to meet this requirement using SSL.  The two factors involved are the password and the digital certificate.  Two factor authentication calls for something you know and something you have.  SSL for Telnet does just that.  (They also require use of VPN for any remote access.)

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.

Securing Programmers On Your IBM i

By Rich Loeber

When planning out the security policies for your trusted IBM i installation, security officers can often overlook the special requirements that programmers will have.  This tip will try to provide some ideas of how to best deal with this situation.

The programming staff for your IBM i, whether they are in-house staff employees or outside consultants, provide unique challenges to security.  On one hand, they are almost always an expensive resource so the fewer hoops they have to jump over to get their work done, the more efficiently (and cost effectively) they can get their work done.  On the other hand, giving them full access to your system is a huge security risk and one that you would not grant to anyone else in your organization.

Programmers will always take the position that they need full access to your system in order to work effectively.  In some cases, that may even be true; especially in small to medium sized shops where there is only a single programmer or a small programming staff.  When problems arise during the day with normal production, someone needs to be in the position to jump in and address the issue, regardless of the system or systems affected.  In order to be able to do that effectively, full system access may be required.

But, for development projects and for programmers who are working on specific task assignments, full access is never going to be required.  Library and object controls can be kept in place and the assignment of all object authority (*ALLOBJ) should be avoided at all costs.  The fewer user profiles you have with *ALLOBJ authority, the better.  Each user profile with this high level of access authority represents a significant security risk.

So, how do you best deal with your programmers?

One good approach is to segregate your programmers on a separate system so that they can work in an unrestricted environment, but not work with live data.  Many shops that I’ve worked in or worked with have maintained a separate system just for the use of programmers.  In this day of the logical partitioning (LPAR), many organizations just carve out a test partition for their programmers.  New code can be created, compiled and tested in a test environment without exposure to live data.  If you can afford this, it is a great compromise.  You do have to create a strong change control turnover policy so that new programs and data files get the right security configuration when making the transition from test to production, but that should be easy to control.

For your programmers who support daily production, a lot of what they do will not require all object authority.  For those situations where it is an absolute necessity, consider setting up a super user profile that can be activated by your security officer as needed.  Then, when the situation is found where more than normal access rights are called for, your security officer can activate the super user profile for use by the programmer in question.  As soon as the fire is out, the security officer can then deactivate the super user profile and all will be well.

As a last resort, if you can’t pry all object authority away from a user profile, then you should at least be journaling activity for each programmer user profile that has this authority granted.  While this will provide after-the-fact reporting, at least you will have a track record of events.  To set this up, security journaling must be active.  Then you can use the “Change User Auditing” (CHGUSRAUD) command to configure what you want to track for the user profile in question.  For more information on how to set this up, see my previous security tip titled Watching Your Super Users.  Even if you are able to remove all object authority for most of your programming staff, I’d recommend taking this approach for every user profile on your system that has full access to the system.

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

IBM i Password Rules

By Rich Loeber

The first line of defense for most systems is the combination of user profile and password.  For most IBM i shops that I’ve worked in, once you know one user profile, you can usually guess most of the rest of the user profiles.  Different shops use different approaches, but they all seem to key off the user’s name or initials.  Some shops may use a more obscure method, but that only tends to make support more difficult when you need to quickly identify the user based only on their profile name.

Given that guessing a user profile can be pretty easy, it makes it very important that passwords not fall into the category of being easy to guess.  For many years, the IBM i OS has provided tools to let you implement a variety of measures to help you with this goal.  This tip will look at some of these and point you in the direction where you can find even more.

The keys to knowing how to enforce password rules are found in the system values that are included in the IBM i OS.  The OS includes a whole set of system values that start with QPWDxxxxx.  Each of these can be used to do things like set the password expiration time period, limit specific characters in a password, limit adjacent characters and digits, enforce password length minimums and maximums, control how often a password can be reused and more.  My personal favorites in this of rules is to disallow any vowels in a password, disallow repeating characters and require at least one digit.  These simple rules go a very long way in forcing users to create passwords that are hard to guess.

With more recent releases of the IBM i OS, there are a wealth of new password options open to you.  These are all available under the system value of QPWDRULES (Password Rules).  This single system value can be set with a maximum of 23 different rules.  You can enforce all of the earlier rules that were available in earlier OS releases plus you can implement new rules.

If you like the way you’ve had things set up before, then you need to make sure that the QPWDRULES parameter is set to the value *PWDSYSVAL.  This will tell the OS to use the individual settings.

A word of warning at this point.  If you are planning on using any of the new values available to you, then you need to first document how each of the old QPWDxxxx system values is currently set.  Once you change the QPWDRULES to any value other than *PWDSYSVAL, then the older system values will all be ignored (with the exception of QPWDLVL which is always in force).  You must first make sure that the current settings you are using are duplicated within the new  QPWDRULES that you set up.

Some of the newer possibilities that I’ve seen that appeal to me include:

•    *LMTPRFNAME – when this is set, the user profile cannot appear as a string anywhere within the password.  For example, user profile JOHN cannot have a password of DOEJOHN.

•    *MIXCASEn – allows you to require that a password contain at least n upper case characters and n lower case characters.  This is only valid on systems running with a QPWDLVL setting of 2 or higher.  For example, if you specify *MIXCASE2, then the password A12bC45 is not valid because it is missing one lower case character.

•    *REQANY3 – requires that a password must contain at least one character from the four character types of uppercase letters, lowercase letters, digits and special characters.  For example, the password of ABCabcd is rejected since it does not contain any numbers or special characters.

For a complete list of all of the QPWDRULES options, go to the IBM i Information Center at the following link: http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i/welcome.  Select the IBMi OS version option and then enter the value QPWDRULES in the search box.  Look at the first article that comes up called “Password Rules” and you’ll find a complete list of the options.  Keep in mind that this is only available if you are running a currently supported OS level (6.1or higher).

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.

A Case For Contextual Security

By Rich Loeber

My wife and I live in the Adirondack Mountains of northern New York state.  During most of the year, except for 10 weeks during the summer, we have very few neighbors with the closest being almost a mile away.  On a normal day, we get a handful of cars that drive down our road (unless you count the number of times the snow plow goes by).  In this context, we’re not very concerned about security.  We rarely, if ever, lock our doors.  We know all of the year round residents and they know us.  We all look out for each other and that seems to be all of the security that we need.  Our biggest security consideration is the local bear population, they get into the trash if you’re not careful and make quite a mess.

In the IBM i world, context can define how you handle security.  Security in the OS is not attenuated to context, so you have to think about your requirements and implement contextual considerations as they apply.

What do I mean by contextual security?  Here’s the classic example.

Suppose that you have an order processing application that records credit card information and then processes that information to obtain credit card authorization approvals.  Obviously, the clerk entering the order needs to have access to your customer database in order to enter the credit card information or validate the information that you already have on file.  Within your standard security model, you will need to grant this user access to the information with sufficient authority to add new information, change existing information or even delete current erroneous information.  For their normal order processing tasks, this user can be configured easily to provide for database access and change authority.

But, what about other possible accesses to this data that do not fall within the normal context of their job execution?  The same level of access that they normally require is inappropriate when accessing your customer credit card information via FTP or by using IBM iAccess download functions.  When using these functions, this same profile can make a copy of all the credit card information on their desktop, then copy the information to a flash disk or memory stick and walk out of the office with all of your credit card information in tact and nobody would be the wiser until the story breaks in the NY Times.

Given this reality, obviously the single context approach to database security is not going to work.  The user does need access rights to do their normal job requirements, but they need to be restricted from access for other contexts.

Fortunately, there are several ways to accomplish this on the IBM i and I’ll just mention three of them here so you can start thinking of how to get this taken care of.

First, and possibly easiest although not always cheapest, is to buy and install a good exit point security solution.  There are several such solutions available on the market from reputable software developers.  (I recommend SafeNet/i, the solution from my company.)  The exit point solution lets you define a network access context for your users and restrict network accesses that might otherwise be wide open to them.  You won’t have to change the security setup in the IBM i OS, but the extra layer of security from the exit point solution will add the contextual security you need from network based applications like those already mentioned.  You could write your own exit programs, but exit point programming is not for the feint of heart and the rules periodically change as the OS goes from release to release, so it is better to go with a good solution from a trusted software supplier (like ours!).

There are two other approaches that are similar in nature and can also let you define security on your IBM i based on context.  One is adopted authority, the other is profile swapping.  In both cases, the security in force when you application runs is NOT based on the user profile doing the work but on some other method.  With adopted authority, your program is set to base security decisions on the user profile that owns the program, not on the profile that is running the program.  This way, you can control who gets to use the program, then the program itself can control the resources that it needs access rights to.  With profile swapping, you can let the requesting user profile control things up to the point where different access rights are needed, then under program control, you can call an API in the OS to swap profiles and run under a different profile for a given duration of processing.  Either way, the user profile used to determine access rights is different from the user signed into the application, giving you contextual control over the situation.

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.

Watching Your Super Users

By Rich Loeber

Every IBM i shop has a few super users that you, as security officer, have to be concerned about.  For one reason or another, a few user profiles just have to have full access to your system.  This tip will show you one way to check up on what these users are up to, using the system security journal.

For specific user profiles, you can implement additional security auditing that is over and above what your system is configured to capture.  To make sure that your super users are not over stepping their bounds, you can set up the security journal to capture additional security events for these specific profiles.

To get started, you need to have the security journal active on your system.  If it is not active, you can just run the Change Security Auditing (CHGSECAUD) command.  Running the command with the defaults shipped with the OS will set up the security journal (QAUDJRN).  By setting the default values to *NONE, you will limit what the security journal captures so you can experiment with tracking an individual user profile’s activity.  Of course, if you already have the security journal active and running on your system, you can skip this step and continue on with setting up the individual profile controls.

With the security audit journal active, you are now able to set up specific event controls at the user profile level.  This is done using the Change User Auditing (CHGUSRAUD) command.  Type this command in and use the F4 key to prompt for the parameters.  For this tip, we’ll concentrate on the “User action auditing” (AUDLVL) parameter and what things you can track at the user profile level.  These include the following:

 

  • *CMD – this setting will record command strings used by the profile in the journal for your review.  With this setting, you can see what specific OS commands the super user is using and make sure that command line abuse is not happening.
  • *CREATE – this setting will let you track all new objects created by the super user.
  • *DELETE – using this setting, you can see when a super user deletes an object.  Since this is a concern for super users, you can track it easily using this method.
  • *OBJMGT – this setting tracks object renames and moves.
  • *SAVRST – this setting lets you track save and restore operations by the super user.
  • *SERVICE – this setting lets you track the super user’s use of system service tools.
  • *SPLFDTA – this setting lets you track actions taken on spool files.
  • *SYSMGT – this setting tracks system management functions.
  • …. more

Different levels of IBM’s i/OS include a number of new/different functions that you mAY want to explore.  The AUDLVL parameter accepts many more options thaN I’ve listed here.  For your installation, you may find some of the other values of particular interest.

A nice side benefit of logging super user activity to the security journal is that it is a good proof for your auditors that super user profiles are being used responsibly.  Every auditor I know of who knows what they are doing is concerned about what super users are up to.  This method goes a long way to satisfy their requirements.

If you have any questions about anything included in this tip you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.

Recovering Your IBM i Security Configuration

By Rich Loeber

I once worked, many years ago, with a company that had a disaster recovery plan in place and actually tested it once or twice.  The plan called for us to arrive at the recovery center and then, almost immediately, turn security on the recovery box OFF to make things easier during the recovery.  There was no corresponding step later in the recovery to reactivate security, so for the duration of any disaster, the backup system was exposed to security violations.  Now, to give them some credit, this was in the days before networks and the Internet, so their exposure was probably pretty limited.  In today’s world, however, when you have to switch over to a disaster recovery site, you will need to have your security plan in place and built into the recovery process.

To understand how best to do this, you first have to understand what the different security objects and settings are on your system along with how and where they are saved.

System values make up a large component of your security policy implementation.  The system values are all stored in the QSYS library.  They are saved when you run a SAVSYS, the “Entire system” or “System data only” options on the SAVE menu or when you save your entire system using the “Run Backup” (RUNBCKUP) command.  When you get to your recovery site and restore your OS from one of these, your system values will get restored in the process.  Keep in mind that these settings will be restored the way they existed when your SAVSYS was created.

User profiles, including group profiles, are also stored in the QSYS library and are saved when you save the OS.  Since these can change more frequently than the OS, you can also save them using the “Save Security Data” (SAVSECDTA) command.  When you restore your OS, you will get the profiles as they existed when that backup was taken.  If you have saved the the profiles separately, make sure that you restore them again as soon as the OS has been restored so that you get the most current set of passwords available.

Job Descriptions can also have an important affect on how jobs run and how security is enforced on your system.  IBM generally recommends that you create your job descriptions in the QGPL library where they keep theirs, but a job description can be created and stored in any library on your system, especially if you are running any third party software.  When you backup a library using the “Save Library” (SAVLIB) or “Save Object” (SAVOBJ) command, the job descriptions will travel along and will be restored when those libraries are restored.

Finally we get to your resource security setup.  This, by its very nature, is a bit more complicated than the above items, but certainly manageable.  The good news is that a lot of the resource security information is stored directly with the object.  This includes its public authority setting, its object audit setting, the profile of the object’s owner, the primary group and the link, if any, to an authorization list.  So, when you save the objects in your library, you will also be saving these security items.  The two resource security pieces that are not included are the authorization list itself and the private authority configuration.

All authorization lists are stored in the QSYS library.  They are saved when you save your OS and they are also saved when you run the SAVSECDTA command.  As with the user profiles already mentioned, these can change more dynamically than the OS, so having a separate SAVSECDTA is a good idea.  After you restore your OS, make sure to include a restore of your security data to get the most recent versions of your authorization lists.

Private authorities are also stored in the QSYS library and are included as a part of the user profile data.  So, when you save the most recent profile information, you are also saving the most recent private authorities.  When you recover your profiles, you are also recovering the private authorities.  But …. there is a catch.  After your system has been recovered, including the most recent profiles and ALL application libraries, you will also have to run the “Restore Authority” (RSTAUT) command for *ALL users.  This will restore the private authorities to objects and to authorization lists.  This is a step that can be overlooked with dire consequences as far as your security implementation is concerned.

There is more information about all of this in IBM’s Security Manual for the OS.  I recommend you review the manual for more details.

If you have any questions about anything included in this tip, you can reach me at rich at kisco dot com,  All email messages will be answered as quickly as possible.

How Much Security Is Too Much?

By Rich Loeber

Last time, I posed the question “Just how much security is enough security for your IBM i?”  This tip will explore the contrary thought of “Just how much security is too much?”.  Is there a point where security is just too much for your installation?

First, we need to admit that all security involves overhead expense.  If you are running security software features in the operating system, they take some computing resources to perform access validation routines.  When you run additional security validation, such as exit point processing, that adds more processing overhead.  When you require users to regularly change their passwords, that requires time every so often on the part of every user on the system to reset their password to a new value.  When someone has a problem during the normal course of their business day that ends up being related to security, this is additional overhead not only on the part of the end user but also by your support staff.  No matter how you look at it, good security costs money.

But, is there a point where you have too much security and the benefits are outweighed by the security protection deployed?  I think the answer is a clear yes, in certain circumstances.

Some time ago, I did a consulting gig for a large company located in North America.  This company had a very aggressive security implementation for outside vendors.  And, they apparently use a lot of outside vendors who need access to their network.  They had a complicated VPN installed which required a remote token generator be shipped to me.  When the token arrived, it included indecipherable instructions on how to gain access which ultimately did not work.  It was a long and drawn out process, but it ended up taking me three days and countless hours of trial and error with various members of their support desk team to get access to their system just to get started on a project that was behind schedule at the outset.  Once I got into their IBM i processor, I found that my profile had not been properly set up and there was a further delay in getting started.

In this case, the costs associated with the security implementation became excessive.  I was on the clock for this entire experience and the customer ended up paying dearly for this wasted time.  For this customer, I’d conclude that too much security was in place or that the security deployed was insufficiently funded.  The whole point was to provide a secure signon to their IBM i from a remote location, but the number of layers needed to get through was just too much.

When is there too much security?  One check is to see if normal business transactions are regularly stopped due to security checking.  If people in your organization can’t get their normal day-to-day work done due to security hurdles, then maybe there is too much security in place and a review of your setup is in order.

Another check is to see if your support costs are on budget or running way over.  If you’re spending significantly more money on support and that can be traced to security issues, that’s another red flag that something is quite wrong in your security environment.

I know that some of you security officers out there are going to cringe at this, but security is always a compromise between operating efficiency and data integrity.  You need to have a good balance, tempered by an honest assessment of what you’re protecting.

If you have any questions about this topic you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.