Don’t ignore the risks presented by objects, profiles, and products that are no longer in use.

I don’t know about you, but I like to start the year with a fresh slate. I create a new set of files for the new year, start new status reports for my clients, etc. But I also like to get rid of things—files containing old sample code or white papers that are no longer relevant, for example. What does this have to do with your IBM i security strategy? Just like it would do damage to my business if I were to send out inaccurate or irrelevant code or recommendations, it may do your business harm if you keep old stuff in your system. This is a great time to make a fresh start with your IBM i and make sure you don’t have outdated stuff lying around. In this article, I discuss the areas of the system you’ll want to examine and provide ways to determine what’s old and not in use.

User Profiles

I’ve said it before, and I’ll say it again: Leaving inactive user profiles on your system poses a risk to your organization. If it wasn’t obvious before, given the recent social-engineering attacks, it should be apparent now that leaving inactive profiles is a door into your system. Depending on how well your help desk is trained to reject social-engineering attacks, it usually doesn’t take much for a bad actor to get an inactive profile re-enabled and reset the password to make an inactive profile usable again. So why are you leaving inactive profiles on your system?! Sorry to harp on this, but this is a real pet peeve of mine! If you don’t already have a method of identifying inactive profiles, running the following SQL provides a list of profiles that have not been used or created within the last three months.

SELECT user_name,

       date(last_used_timestamp) as last_used,

       timestamp(previous_signon, 0) as last_signon,

       timestamp(creation_timestamp, 0) as create_time,

       status,

       text_description

   FROM QSYS2.USER_INFO

   WHERE (last_used_timestamp IS NULL

             OR last_used_timestamp < CURRENT TIMESTAMP - 3 MONTHS)

         AND (creation_timestamp < CURRENT TIMESTAMP - 3 MONTHS);

I know that some of you are hesitant to delete profiles for fear that you’ll delete profiles that are actually needed. But the key is to look at the right dates. You must be examining the Last used date. If you look at the Previous sign-on date, you’ll miss profiles running batch jobs or making ODBC connections. And don’t worry about orphaning objects: IBM i won’t delete a profile if it owns objects. Perhaps you’re uncomfortable deleting profiles that have only been out of use for three months. Fine, change the timeframe, but please don’t leave inactive profiles on your system!

Old Objects in Libraries

I’ve heard the QGPL library being nicknamed Q Garbage Pail Library. Because it ships as *PUBLIC *CHANGE, it is a known library where objects can be created, and they often are. But how often are these objects cleaned up? Rarely. I’ve seen files in QGPL from queries that contain very sensitive data, are publicly available, and are literally years old. Here’s the SQL that looks for all objects in QGPL that haven’t been used for the last year.

SELECT *

   FROM TABLE (

           qsys2.object_statistics('QGPL', '*ALL')

       )

   WHERE last_used_timestamp < CURRENT TIMESTAMP - 1 YEAR;

Obviously, this IBM i service isn’t limited to QGPL. You can (and should) use this service to look for old objects in other libraries, especially user libraries. Why? One example is developers: They will often make a copy of production data to either test a fix or to make a copy of the database file prior to adding a column. These copies are rarely secured the way the production version is secured. The result is production data widely available via user libraries. I’m sure you can think of other examples.

Old Objects in the IFS

The IFS is probably an even larger repository of old data. And just like you can find old objects in a library, you can also discover old objects in a directory. (Thank you, Scott Forstie and your IBM team, for making this so easy!)

SELECT path_name,

       object_type,

       create_timestamp,

       last_used_timestamp,

       object_owner

   FROM TABLE (

           qsys2.ifs_object_statistics(start_path_name => '/tmp', subtree_directories => 'YES', OBJECT_TYPE_LIST => '*ALLSTMF')

       )

   WHERE last_used_timestamp < CURRENT TIMESTAMP - 6 MONTHS

order by path_name;

Obviously, this example is for the ‘/tmp’ directory so you’ll want to modify it and run this against the directories on your system. I wouldn’t change it to ‘/’ (root) unless you want this to run for quite awhile! I’d rather run it against a subdirectory so I get a more manageable list of objects.

Other Old Stuff

Inactive profiles and old objects aren’t the only things that need to be examined and removed from your system. Take a look at the products you have installed. Over the years, I’ve found clients with products they had once implemented but no longer use. Why is this an issue? Think of the log4j exposure we experienced a couple of years ago. All vendors with log4j exposures notified their clients so their products could be upgraded to a version with the exposure removed. What if you’re no longer in the vendor database but their product remains on your system? Your system may have serious security exposures and you won’t know it. Another scenario I’ve seen are old copies of vendor products currently in use. This often occurs because you make a copy of the product before upgrading it. I understand this practice. But what I don’t understand is not cleaning up (that is, deleting) the old version once you’re satisfied that the upgrade was successful. Why is leaving these old versions around a problem? Increasingly, vendors are providing more security services or ways to restrict access to their product or shipping their product’s objects with more restrictive permissions. By leaving the old versions around, users may be able to access the older, less secure version, circumventing the new restrictions.

Summary

It should go without saying that you’ll want to back up your system before you start this housekeeping project! But once you’ve done that, I hope that you’ll start the new year with a cleaner (and more secure) system.

More examples of using SQL to manage your IBM i security can be found in my book Mastering IBM i Security. Click here to order.