What can organizations do when using “best practices” settings cause something to break? This article discusses your options.

Of course, implementing what is recommended as a “best practice” is what you should strive to do. However, I’ve found that there are instances when implementing a best practice setting in its most literal sense will cause issues. What should you do? Ignore that aspect of security and move on? No. You’ll want to find an alternative solution that meets the spirit of the best practice recommendation but fulfills it differently. In the security and audit world, that’s called a “compensating control.” Let’s look at some examples.

Inactive Session Time-Out

In addition to being required by several laws and regulations, this best practice just makes common sense. The best practice recommendation is to time-out a device after no more than 15 minutes of activity. You don’t want a device that’s been signed on left in a state where it can be used by someone else. For an IBM i shop, that would imply that the QINACTITV system value be set to 15. However, I’ve encountered numerous organizations for which this would cause issues—either in their application directly or with their user community. The compensating control? Time-out the entire workstation using a group policy at the network level. This avoids timing out the IBM i session when the user is doing something else on their PC. I like this compensating control because it protects more than just the IBM i session; it protects all of the information and restricts the tasks that are enabled on the workstation. If the time-out is reached on the workstation, when the user returns, they have to re-enter their network password. Another compensating control that some organizations use—but in my opinion is far from effective—is to have a written policy that users should lock their workstation when leaving their work area. It’s a good policy to have, but, to me, it’s not a compensating control because it depends on the appropriate behavior of an individual rather than technology that doesn’t forget to take an action when it’s late for a meeting!

All Passwords Must Be Changed Every 90 Days

While this best practice requirement may not be an issue to implement for profiles used for signon, what about those profiles used as service accounts—that is, those profiles used to make connections using ODBC and FTP? Obviously, having these profiles expire has the potential to cause processes to fail if you forget to change the password ahead of the expiration. And changing these passwords often requires careful coordination between two or more servers. Therefore, in most organizations, service accounts are configured with a non-expiring password. That is, PWDEXPITV(*NOMAX).

But with a non-expiring password and the fact that service account passwords are often known by multiple people, you’ll want a compensating control that limits how the profile can be used. First, when you configure the profile, set the Initial program (INLPGM) to *NONE, Initial menu (INLMNU) to *SIGNOFF, Attention program (ATNPGM) to *NONE, and Limited capability (LMTCPB) to *YES. This ensures the profile can’t be used at a signon screen.

But what about a service account used by a WebSphere application? It needs to make a JDBC connection but should not be used for DDM or FTP. In this case, the best solution is to limit what the profile can be used for via an exit program. If you have an exit point solution such as the Powertech Network Security product, you can put rules in place that will allow you to very tightly configure what connections service accounts are allowed to make. If you don’t have an exit point solution, you can use the Application Administration or Function usage feature of IBM i to disallow connections for ODBC/JDBC, DDM/DRDA, and FTP. For example, if you want to prevent the service account making that JDBC connection from using FTP or DDM, you’d go into the Host Applications tab of Application Administration and customize the access by running either of the following commands (either method accomplishes the same thing).

            CHGFCNUSG FCNID(QIBM_QTMF_CLIENT_REQ_0) USER(SRV_ACCT1) USAGE(*DENIED)

      CHGFCNUSG FCNID(QIBM_DB_DDMDRDA) USER(SRV_ACCT1) USAGE(*DENIED)

While not as complete a compensating control as using an exit program, using Application Administration to limit service accounts is better than doing nothing when service accounts are required to have a non-expiring password.

Audit All Actions

While some organizations have excess storage capacity, many do not. Therefore, turning on all of the IBM i auditing options may cause serious storage issues and/or you may be tempted to not save the audit journal receivers and just delete them from the system as soon as a new one is generated and attached. Or you may choose to not enable auditing at all. None of these options comes close to being a substitute for “Audit all actions.” What you can do in this situation is make an educated decision about what is appropriate to audit in your organization. When you make this educated decision, be sure to document your reasoning should an auditor ever ask why more features aren’t enabled.

The answer to “What should be audited?” is not a one-size-fits-all answer. The answer depends on the details of your organization. As you determine what to audit, remember that one of your goals should be to have enough information retained such that you could conduct a thorough forensic investigation if required. Another consideration are any laws or regulations with which your organization must comply. Finally, consider the information that would be helpful for system administrators in their daily work.

Here are some guidelines that should help in your decision-making process:

• My recommendation for the most basic auditing requirements is the following: QAUDLVL set to *AUTFAIL, *CREATE, *DELETE, *PTFOPR (V7R2 and above), *SAVRST, *SECCFG, *SECRUN, *SERVICE.
• Beyond that, you may choose to enable many of the other types of auditing, all of which provide good and useful information. However, some have the potential of creating a lot of entries. These include *JOBDTA, *SPLFDTA, and *PGMADP. Whether you enable these will depend on the value of the information to your organization. For example, if you have a lot of users with *JOBCTL special authority, you may want to add *JOBDTA or *JOBBAS (a subset of *JOBDTA) to QAUDLVL in the event you need to debug how a job was ended or held.
• Consider turning on additional auditing at the user level rather than the system value level. For example, if you want to know when certain profiles such as QSECOFR are being used but don’t want to enable *JOBDTA for the entire system, you can enable *JOBDTA at the individual level using the Change User Auditing (CHGUSRAUD) command.

Another audit best practice requirement is to audit all users who have command-line access. This means enabling *CMD auditing for all profiles whose limited capability setting is either *NO or *PARTIAL. This shouldn’t be an issue if you have your user profile settings under control. But for those organizations that haven’t made sure all non-administrative profiles are limited capability *YES, this could be an overwhelming amount of audit entries. If enabling auditing on all profiles that are LMTCPB *NO or *PARTIAL is out of the question, then at least enable *CMD auditing on all profiles with *ALLOBJ special authority that can be used for signon.

While neither resolution fully addresses the best practice auditing requirements, determining how to best implement auditing within the restrictions of your environment is key to coming as close to security best practices as possible.

Some Best Practices Have No Compensating Controls

While some best practice settings have a good alternative, some do not.

Running at QSECURITY Level 40 or 50

You can guarantee neither operating system nor data integrity at 30 or below. Users can easily run as a profile with higher authorities, and some auditing may be bypassed at lower security levels. The only option to meet this requirement is to run the system at QSECURITY level 40 or 50.

Default Passwords

I have recently heard two justifications for default passwords, neither of which justify (are compensating controls for) the use of default passwords:

1. The password is set to *EXPIRED. The justification is that the person signing on will have to set it to a different password. How is that protection for inappropriate use of a profile? The person exploiting the profile changes the password, signs on, and does whatever deed they’re trying to accomplish. The damage is done; an expired password doesn’t prevent that.
2. The profile has been set to INLPGM(*NONE) and INLMNU(*SIGNOFF), meaning that the profile can’t be used to sign on to a 5250 emulation session. While that’s true, as I discussed in the previous section, this reasoning totally ignores the potential of the default password being used to make an ODBC connection, download a file via FTP or submit a remote command!

Summary

While implementing best practices may be an all-or-nothing in some cases, in many instances it’s not. Rather than ignore the best practice and do nothing, I encourage you to find a way to implement a compensating control to fulfill the intent of the requirement.