Carol provides her pet peeves when it comes to IBM i security configuration.

At this time of year, many lists of favorites are published, but I thought I'd take a slightly different twist and publish my list of IBM i security pet peeves.

#1: Administrators with non-expiring passwords

Among the items we check when performing a security checkup are the password rules on the system, including the password expiration interval (that is, how often a password has to be changed). We also check to make sure that the password expiration interval has not been overridden at the user profile level. Now, it's appropriate to have service accounts with a non-expiring password, but it's not appropriate to have profiles used for sign-on with a non-expiring password. My pet peeve is when I see administrators' accounts with a non-expiring password. These accounts are some of the most powerful on the system. If compromised, the profile can be used—and abused—forever.

Administrators, change your passwords!

#2: Granting *ALL authority instead of what's actually required

Application profiles—especially those making an ODBC or JDBC connection to IBM i to access a database file—will need authority to the file to be able to read or update it. My pet peeve is when an administrator (usually a system administrator or application manager) grants *ALL authority for this profile to the database file or directory being written to rather than granting only the authority required. For example, if a file is being read, the application profile only requires *USE authority. Granting *ALL authority gives the application the authority to delete or modify records, delete the file, or authorize others to the file. Same with granting *ALL authority to a directory. If the application simply needs to write a file to a directory, the application profile should only need *W authority. It should not be granted the ability to read the contents of the directory, clear the directory, or grant others access. My pet peeve is not just that this is a security risk, but this practice makes it incredibly difficult to modify access later. The personnel familiar with the process have often moved on, so you have to try to determine what the process is doing and then use the trial-and-error method to determine what authority is actually required.

Administrators, determine what authority is required when you first set up the process! Don't just grant *ALL to any profile requiring access!

#3: Granting all special authorities to service accounts

A slight variation to the #2 pet peeve is my #3 pet peeve—the assignment of all special authorities to service accounts, regardless of whether they actually require them to perform their tasks. Many service accounts are used to make a connection between IBM i and another server or to FTP files. In these cases, there's no need for the profile to be granted any special authority. Users performing those tasks simply need authority to the files being accessed. Blindly granting all service accounts all special authorities just because they are service accounts presents an even greater security exposure than #2 because most service accounts have non-expiring passwords that are often known by multiple individuals. Over-authorizing these profiles provides these individuals (usually programmers) access to a very powerful profile.

Stop granting special authorities to profiles when they are not required!

#4: QCRTAUT system value set to *ALL

Along the same lines as granting *ALL rather than just the authority that's required, changing the QCRTAUT (Create authority) system value has the same effect. Setting the QCRTAUT system value to *ALL means that the *PUBLIC authority of newly created objects will be set to *ALL. Once again, this is a significant security risk because any user on the system has the authority to read, modify, and delete objects. My pet peeve is that, once set to *ALL, it's very difficult to change back to a more restrictive value because it's unpredictable what will break. For most object types, it won't be a problem. Failures typically come when accessing database files. One would think that *CHANGE authority on a database file would be sufficient. But if the process is adding a physical file member, the process requires *CHANGE plus *OBJMGT authority. Unless someone is intimately knowledgeable about these processes, it is impossible to know that this additional authority is required until you start testing.

Please avoid any temptation to set QCRTAUT to *ALL!

#5: Auditing is not configured

One excuse I often hear when I discover a system where auditing has not been configured is, "Nothing has ever happened, so why should I bother auditing?" To that I reply, "If you're not auditing, how do you know nothing's happened?" Another excuse is, "We don't have time to look at all of the audit entries, so why should I bother?" My reply to that excuse is that, even if you don't plan to examine the audit journal regularly, you want to have the logs just in case they're needed for an investigation. Many of you know the story of my being called in to investigate a breach only to discover that the client had deleted all of the audit journal receivers, history logs, and joblogs; therefore, there was nothing I could review for inappropriate behavior.

Please avoid this pet peeve and enable auditing—even if you don't intend to review the activity regularly.

#6: Leaving inactive profiles on the system

If a profile is on the system, its security implications must be considered; therefore, if a profile isn't being used, it should be deleted. Let me give you some examples. If a profile has excess special authorities, they should be removed, right? The answer is yes, but if the profile is inactive, why not just delete the profile and not bother with removing the authorities? The same applies to profiles with a default password. If the profile has a password that's the same as the user name but it has either never been used or not used in the last 90 days, why bother doing something with the password? Just remove the profile from the system. And profiles of employees that have left the company should always be removed to avoid the possibility that the profile could be accessed by the former employee. Also, inactive profiles add unnecessary time to the Save Security Data (SAVSECDTA) process and worse, to the Restore User Profile (RSTUSRPRF) process should the system have to be rebuilt.

On some systems I've seen thousands (no exaggeration) of inactive profiles; this is a huge exposure and such a waste of system resource that inactive profiles have become one of my pet peeves.

#7: Inactive profiles that must remain on the system due to poor programming practices

How a programmer thinks these are good idea is beyond me, but I've seen cases where administrators have no choice but to leave profiles on the system—even though they're inactive—because when a history report of a user's application activity is generated, the description for the user is taken from the user profile's Text field parameter. If the profile has been removed from the system, the text field says, "User not found." What programmer in their right mind would program a history file and not keep all of the history—that is, the user's text field—and instead rely on the profile remaining on the system indefinitely? Another scenario that baffles me is when a profile's existence is used to verify that a user can run an application. Not a valid user id and password combination, mind you—just the presence of the profile on the system. So in this case, the profile's "Last used date" isn't updated. So, to the system, the profile appears to be inactive since the Last used date is never updated. However, if you delete the profile, the user can no longer access the data.

This pet peeve is best described as stupid programmer tricks.

#8: Vendors that require the use of QSECOFR

The QSECOFR user profile should be used only for system upgrades, not for regular sign-on or daily tasks. My pet peeve is when vendors require application administrators to sign on with QSECOFR to install or configure their application. This is pure laziness on the part of the vendor, and there's absolutely no need to require this authority.

Vendors, stop requiring the use of QSECOFR!

#9: Vendors that require too much authority to run their application

Some vendors require their application users to have *ALLOBJ and other special authorities assigned to their profile even though the application performs no function that requires them. My pet peeve is that vendors fail to determine what special authorities are truly required and cause organizations to have to excessive special authority assignments for no reason.

Vendors, stop requiring special authorities you don't need!

#10: Vendors that don't care

Back in the day, it was quite easy to secure application data. All a vendor had to do was tell administrators how to configure application users' profiles so they went into the correct application menu. Between that and ensuring profiles were set to Limited capabilities (LMTCPB) - *YES, data was secure. No technology existed that allowed direct access to data. So at that time, it really didn't matter what authority vendors set on their application objects, including database files. However, those days are long gone, and now it does matter what the authority settings are because of the plethora of methods that allow data access in addition to menu access.

I've heard many complaints about the wide-open settings that vendors configure for their application objects. Unfortunately, it's not just a simple matter of changing an application's security configuration. If vendors suddenly changed from setting *PUBLIC *ALL authority on their application files to *PUBLIC *EXCLUDE, after an upgrade, all processes using protocols such as ODBC, DDM, and FTP would stop working due to authority failures. No one would appreciate that outcome. What is possible, however, is for vendors to (1) start shipping their applications in a way that makes it easier to secure the application data and (2) provide guidance for their customers on how to achieve either read-only or deny-by-default access for their application database files. Some vendors such as JDEdwards and Infinium provide such guidance. My pet peeve is when vendors simply don't care about their customers' data security concerns, refuse to provide guidance, and threaten to pull support if the security configuration of their application is modified. I cannot believe how irresponsible that is in today's world! I was actually escorted out of a vendor's office because they didn't want to hear what I was telling them about their application…true story!

Vendors, you need to care about your clients' security!

Final Thoughts

You've gotten some insight into things that really annoy me, but the reason they annoy me is because of the unnecessary vulnerabilities they pose to IBM i and to your organization's data. I hope you take a few minutes to think about whether any of these scenarios exist in your organization and then take measures to eliminate them.