Why Security Level 40 or 50?

Security levels 40 and 50 provide "operating system integrity." This is important because operating system integrity prevents the use of interfaces not approved by IBM. In other words, applications are forced to use APIs or commands to access or manipulate OS/400 objects. At security level 20 and 30, applications can use a pointer to resolve, for example, a database file, and directly manipulate the data. This bypasses any object auditing you may have set on the object and in some rare cases also bypasses some authority checking. Because applications can manipulate data "unnoticed"--that is, no audit record is sent when accessing the data--you cannot ensure the integrity of your system.

For example, an application could be written using C or C++. Suppose a disgruntled programmer writes a program that resolves to the file containing the inventory for a retail operation. He invokes the program, and the inventory values are manipulated slightly--levels of some items are increased, some are decreased. The result? Inventory of the retailer is totally hosed. Items are out of stock even though the database indicates plenty of inventory. Other items sit in huge quantities in the warehouse. Even though there was object auditing set on the inventory file, the devious deed was not audited because the system is running at security level 30. "Well," you counter, "the programmer would have to have authority to update the database, wouldn't he?" Yes, you are correct. He (or she) would have to have sufficient authority. But at security level 20 or 30, this is easy to obtain by using a job description that names a powerful user profile. At security level 20 or 30, a user only needs *USE to use a job description. At security level 40 or 50, a user also needs *USE to any user profile named in the job description.

I cannot emphasize enough the importance of being at security level 40 or 50. Neither the security nor the integrity of your system or your data can be assured at security level 20 or 30. Systems at these levels can easily be exploited and security measures quickly circumvented. I feel so strongly that all systems should be at security level 40 or 50 that I would rather see a system at security level 40 and have all users have *ALLOBJ special authority than to see a system sit at security level 20. (A note of explanation: At security level 20, all users are given *ALLOBJ special authority when they are created.)

How Do I Know if It Is Safe to Move My System to Security Level 40?

Auditing is the answer to this question. You will want to run auditing for long enough to assure that the majority of your applications have been run--for example, over month's end or, better yet, quarter or year end. You are looking for two types of violations: One, applications that are doing something they shouldn't, and two, the use of job descriptions that name user profiles where the user doesn't have authority to the user profile. The steps below tell you what to look for and how.

1. Add the *PGMFAIL value to the QAUDLVL system value. This will allow you to start gathering information to determine if any applications need to change. It is unlikely that applications need to change, but you will want to audit to make sure. Otherwise, if the application is doing something it shouldn't, the application will fail at level 40 or 50, and you will have to change the system value back to the previous value and re-IPL to allow the application to run.

2. Add the *AUTFAIL value to the QAUDLVL system value. This allows you to gather entries for users that use a job description that names a user profile. An audit entry is generated when the user does not have *USE authority to the user profile named in the job description.

3. When you have audited over (at least) month's end, query the audit journal. Both the *PGMFAIL and *AUTFAIL parameters produce "AF" type audit entries. The first letter of the audit entry's specific data determines what type of AF entry it is. Look for the following entries:

• B--Restricted (blocked) instruction violation
• C--Object validation failure
• D--Unsupported interface (domain) violation
• J--Job description and user profile authorization failure (using a jobd that names a user profile)
• R--Attempt to access protected area of disk (enhanced hardware storage protection)
• S--Default sign-on attempt

The type of the entry will determine what action needs to be taken to ensure a successful move to security level 40 or 50. For example, if you see an entry that begins with B, you will know that the program that produced the entry is using a blocked MI instruction. The MI instruction will need to be replaced with either a command or an API call. All J entries indicate the use of a job description that names a user profile where the user of the job description does not have *USE authority to the user profile.

There are a couple of ways to query the audit journal. One is to use the Display Journal (DSPJRN) command. You would probably want to use this command if you intend to send the information to an outfile and run your own queries against it. If you just want a printed report, you can use the Display Audit Journal Entry (DSPAUDJRNE) command, specifying AF for the Entry type parameter.

Details about OS/400 auditing can be found in either the iSeries Security Reference or the book Implementing AS/400 Security.

My Third-Party Application Causes Violations

Sometimes, you will get audit journal entries flagging third-party applications. When security level 40 was introduced (in V1R3), many applications could not run at that level, but that is no longer the case. Today, it is rare to find an application that doesn't run at security level 40. However, some applications can be misleading. If you have audited as described above and found violations caused by a third-party application, don't assume that the application doesn't run at security level 40 or 50. When this happens, it's usually because the vendor takes one code path at security level 20 and 30 and another code path (one does not cause violations) at security level 40 and 50. You will see the audit entry at a lower security level, but when you move to the higher level, the application works just fine. To make sure, call the vendor before moving to the higher security level. In addition, some vendors claim that their application doesn't run at security level 50. It is highly likely that it really does run at level 50, but the vendor probably hasn't taken the time to test at that level.

We Can't Afford the Performance Hit

Rest easy. There isn't a performance hit at the higher security levels. In theory, there could have been a performance hit at security level 50 in releases prior to V5R2. However, it was never proven, and to my knowledge, no performance complaints were ever attributed to someone running at security level 50. Vendors may claim a performance advantage at security level 20 or 30, but, again, I have yet to see proof of these claims. Vendors typically fail to consider the extra processing done by the system at the lower security levels to process and "swallow" the exceptions their applications generate by using the unapproved interfaces. So while their code path may seem longer at the higher security levels, the system doesn't have to spend time processing any exceptions.

Security Level 40 or 50?

People often ask me about the differences between security level 40 and 50. Prior to V5R2, the primary difference was something called "parameter validation." Parameter validation makes sure that the pointers passed by user-written programs point to the right type of storage. It has been shown that when parameter validation is not performed, a user-written program calling an API can get back internal system information that is not retrievable when parameter validation is performed. That is why, prior to V5R2, my recommended security level setting is 50. But as of V5R2, parameter validation is now in effect at security level 40 as well as 50. (Kudos to the folks in Rochester for making this possible.) Since parameter validation was the primary reason for my level 50 recommendation, my recommended setting for QSECURITY is now 40 as of V5R2. Details on the exact differences between the two security levels can be found in Chapter 2 of the OS/400 Security Reference manual or in Chapter 2 of my book, Implementing AS/400 Security.

We Don't Have the Time!

There's not a lot I can do about this issue. I can't magically add an hour or two to everyone's day. However, I find that when many people say they don't have the time, it is often because they don't have any idea how to address the particular issue or where to start, so they don't know how much time the effort will take. Therefore, they don't have the time. Hopefully, the information in this column has clarified the benefits of moving to security level 40 or 50, explained how to get the information required, and given you an idea of where to start. Perhaps, after reading this column, time will no longer stand in your way of making the move to security level 40 or 50.

If you would like to submit a question or topic for possible inclusion in a future "Security Patrol," please send it to This email address is being protected from spambots. You need JavaScript enabled to view it.. Make sure to put "Security Patrol Question" in the Subject line.

Carol Woodbury is co-author of the book Implementing AS/400 Security as well as co-founder of SkyView Partners, a firm specializing in security consulting and services. Carol has over 13 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Carol can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..