Carol discusses why it's important to protect administrative profiles and provides options for protecting them.

If you've paid attention to the news of stolen data, you've heard that many of the attacks come after malware is installed somewhere in the network. Once installed, the malware often sniffs the network to get credentials (user IDs and passwords). The malware keeps trying these credentials until it captures an admin's, and then the hackers gain access to servers with admin rights to gain access to other parts of the network and your data.

Unfortunately, much of this activity is undetected by intrusion detection and log aggregators. The reason? The activities often look like "normal" behavior. Activity using administrator accounts is often not flagged in these product rules or it's of the sort that's used to run most processes, so the activity that's sending data off the systems looks like a normal process. I'll explain the steps you can take to safeguard your IBM i administrator accounts from being abused.

What's an Administrator Account?

First, I want to establish my definition of an administrator (admin) account. My definition is a profile that has at least *ALLOBJ special authority or is a member of a group that has *ALLOBJ. Some people add profiles that have other special authorities, such as *SECADM. Whatever your policy is and definition of "admin" is, I'm good with that. I use this definition because it's easy and no one can argue that a profile with *ALLOBJ isn't powerful.

Change the Password

I still find many administrators' profiles have the password expiration interval set to *NOMAX, meaning that the password has to be changed. Always using the same password means that, if the password is sniffed off the network, then it can be abused forever because the password will always be valid. As tempting as it is not to, you must make sure that you regularly change your password. I would argue that you should be changing the admin profiles more frequently (at least once a month if not every week) than the general user community to limit the time a stolen password can be exploited.

Limit How They're Used

Some people use the same admin profile to do everything—sign on, run batch jobs, FTP files to banks, establish an ODBC connection to a Windows server, etc. Many of these tasks don't require a profile with *ALLOBJ. I recommend that you perform these tasks—especially ones that require sending a user ID and password over the network—with a profile that has only the authorities needed to perform the task, avoiding the assignment of *ALLOBJ whenever possible. For profiles used to run jobs in your job scheduler, set the profile to password *NONE since it isn't being used to sign on to the system or establish a connection to another system.

Use Encrypted Sessions for All Connections

Better than changing your password regularly is making it so it's not readable in the first place. Every session—whether it's 5250 emulation, iNavigator, or Navigator for i—should be run over a TLS (aka SSL) session. I say TLS because you want to be using TLS 1.2. SSL and earlier versions of TLS have vulnerabilities and should be avoided.

Use Two-Factor Authentication

One of the best ways to protect your admin account is to require two pieces of information to authenticate to the system. Products exist that allow you to authenticate via an RSA fob or through a biometric device such as a fingerprint reader. This means that, even if your password is guessed or stolen, it won't be able to be used without the second piece of information.

Don't Have a Password at All

You can eliminate the use of passwords altogether by authenticating using a Kerberos ticket. This is the authentication method used in single sign-on (SSO). If you have a Windows network, you're already authenticating to an Active Directory and creating a Kerberos ticket. You can configure your emulation session to use this ticket to sign on rather than entering a user ID and password.

Elevate Your Privileges Once You've Signed On

I fully accept that many tasks—especially if you're a system or security administrator—require *ALLOBJ special authority. Several options exist for gaining *ALLOBJ. One is to assign an initial program that is owned by and adopts a profile that has *ALLOBJ. Once signed on, you have the authority needed. Another option is to use one of the vendor products that allow you to elevate your privileges after sign-on. The limitation with these two options is that they only work when signing on to an emulation session.

Vendor Profiles

Many software packages create a profile to own the product. Some of those profiles get created as an admin profile. In some cases, such as products that work with the audit journal, this is warranted because of the authorities required by the operating system. However, most products shouldn't require *ALLOBJ special authority. When you install a vendor product, examine the authorities of any profile created and remove those that are not required. I encourage you to require the vendor to justify the reason the profile was created with any special authorities—especially *ALLOBJ—and push back if the justification isn't reasonable.

Another attribute to examine is the profile's password. Unless the profile is being used to establish a connection, it doesn''t need a password. And no vendor profile should require a default password. We were recently able to demonstrate to a client how a vendor profile created with a default password and *ALLOBJ special authority was able to be used to run a remote command and modify an end user's profile to have *ALLOBJ.

Business Partners' Profiles—Used to Sign in and Do Work

Many of you have business partners that help you administer your system or your applications. You need to determine whether these partners really need all the authority they typically request. First, do they really need *ALLOBJ special authority? If that's the case, don't automatically give them all of the other special authorities. Give them only the authorities they need for their job functions. Under no circumstances should you let a vendor convince you to allow them to have a non-expiring password. In fact, consider setting their password to *NONE and only give them a password when they need to gain access to your system.

Use of QSECOFR

QSECOFR is the first profile hackers will try to abuse if they're randomly trying to gain access to your systems. Limit the use of QSECOFR to only system upgrades and, yes, the time when an irresponsible vendor requires you to sign on to install or upgrade their product. The operating system will prevent you from setting the QSECOFR password to *NONE, so, to further protect this profile, set QSECOFR to status of *DISABLED. This requires you to either sign on to the console to use QSECOFR or set it to status *ENABLED prior to using it.

Final Thoughts

I've said it before and I'll say it again: IBM i is one of the most securable systems available. But if you're allowing the bad guys to swipe your administrator credentials off your network, you're opening your organization up to the potential of having those credentials abused. I, personally, wouldn't want to attempt to explain why my profile was used to download all of the files containing Personally Identifiable Information (PII) data. Would you? And of course, if you haven't implemented object-level security to protect your database files, you have to protect all users' credentials, not just administrators'.