The Long and Short of Setting Up Level 40 Security
February 14, 2007 Hey, Brian
|
We are at security level 30 in i5/OS and we have been told by our auditors that we need to move to security level 40. What are some of the benefits that we will see going to level 40, and is it as simple as changing the QSECURITY system value? Some of what I read tells me I have to start journaling in order to see if I can run at level 40, but then it says I can go to level 40 just by changing the system value. What is the real answer here? –Bob Besides all of the marvelous built-in security facilities brought to the System i and its predecessors through its unique capability based addressing, there are also a number of very powerful security tools available for your use. The QSECURITY system value sits right at the top of the list in terms of making your system secure. Through the effective use of QSECURITY and all of the various security tools that come with your System i, your shop can be as secure as you wish to make it, and you can please your auditors. All together, however, it is not an easy task. First of all, let’s talk about the visible benefits of moving to security level 40 from level 30. In a word, there are none. In fact, the issue is quite the opposite in terms of visibility. If you move to level 40 from level 30 by changing the system value (which is all that you need to do to turn on level 40), your wish should be that you see no differences of any kind in any respect. Yes, there are benefits, but you will not see them. However, if your system is not currently capable of running level 40 security for a number of reasons, which are noted later in this reply, you will see a difference. It will be a bad difference. Jobs will fail and messages not from heaven will begin to populate your job message queues and your system operator message queue. Life as you know it will change and you will be compelled to quickly retreat to level 30. Therefore, you may ask if you should move to level 40 on System i at all if it can create such issues for you? The answer is “yes, absolutely, but carefully.” So, please do not go over to your console right now and change the QSECURITY system value to anything until you have read this entire response. As you may know, the System i is a table-driven system and the major table entries for the system are contained in a set of values that are called System Values. The QSECURITY system value is just one of hundreds of values that control the operation of your machine. In many ways you can think of all these values as tools that help you configure the run-time options of your system. Security level 40 is about as good as you need to be to pass any audit by any firm, other than of course national defense purposes or C2 level security. In this case, Level 50 would be required. The notion of security levels and the QSECURITY system value to control those levels is one of the easiest tools you have to help assure security on your system. So, the real trick is not how to set the value but how to assure that you can run your jobs at level 40 security. You can choose how much security you want the system to enforce by setting the security level (QSECURITY) system value. Besides the levels 40 and 50 which we have discussed briefly, there are three other levels of security available. Level 10 is your way of telling the system that you want no security at all, including password security. Beginning in V4R3 and future releases, the system honors level 10 security but does not let you set the QSECURITY system value to 10. Moreover, with security level 10 you have basically voided your software support contract. IBM will not provide support for any problems that occur at security level 10 unless the problem can also be created at a higher security level. Of course, if you set your level higher to solve the problem, you cannot set it back. Level 20 security provides user id and password security. However, once they get on the system, all users have all security capabilities–as much as the security officer. In System i terms, they have *ALLOBJ (all object) authority at level 20 and with *ALLOBJ authority at any level (can be granted to specific users at other levels) you can do just about anything you want to objects on the system. Level 20 is not good. Level 30 provides resource security. You can grant authority to specific objects for specific users or all objects for specific users etc. In this scenario, resource security is active. In your case, I would suspect that you have been running with this level of security for some time now. With level 30, your resources are not secure however, unless you have spent the time to specify which resources are to be protected. Level 30 is the first level from 10 to 50 in which you have the ability to secure resources at all but again, it is not automatic. Level 40 does everything that level 30 does plus it prevents potential integrity or security risks from programs that can circumvent security in special cases. Level 40 provides system integrity and it plugs some holes that at level 30 enable a user profile with *USE authority to a job description to be able to use the user profile specified in the job description, rather than their own job description to perform tasks that they otherwise would be forbidden to do. These capabilities of course include wreaking havoc on the system if they choose to do so. Level 40 is not a security level that takes superhuman mental strength to understand and implement though the devil is in the details. The facilities gained with Level 40 are outlined below in two tables from the IBM security manual. Level 50 is a concept that is rather onerous to understand at its detailed level and it takes more than a passing interest in security to deal with all the ports of entry that are closed with Level 50. If you want an overview of security level 40 and 50, see V5R4 Security: Rochester Rests Not on Its Laurels, Part 1 and Part 2 from this newsletter, by Steve Martinson. As a point of summary, I include below Table 1 of Chapter 2 in the V5R4 System i Security Guide to give you an overview of the various protection schemes that exist in V5R4 at security levels 20 through 50.
Figure 1: Table 1 from IBM’s V5R4 Security Reference Manual, SC42-5302 Besides the items in Table 1, an important thing to know about your security level is that it determines what the default special authorities are for each user class. To understand the notion of special authorities and how they relate to the user class, when you are creating your next user profile, press F1 (HELP) on the User class parameter and it explains this relationship. When you create a user profile, you can select special authorities based on the user class. Special authorities are also added and removed from user profiles when you change security levels. On your trip to level 40, it helps to remember that it affects more than RPG programs or other programs that happen to “steal” more authority than they should have and which get jiggered to operate at the system state instead of the user state. Level 40 affects almost every object if not every object on the system. So, since there are caveats in moving to level 40, it helps to know that there is a “best way” to prepare for such a major change. The tool that all experts recommend is the audit journal. You need to create and turn on the audit journal and monitor its contents for awhile to be sure that your system with your applications can sustain security level 40 or higher. This leads us to your final question. Do I need journaling to run at security level 40? The simple answer to this question is yes, but it is not the same exact notion as database journaling. You do need to set up the audit journal as a journal object on your system and associate journal receivers with it, just as in database journaling. Then you need to tell the System i via the QAUDLVL system value just exactly what types of security checks you are looking for. I call them security checks because they exist in level 30 as well. They are just not enforced in level 30. However they do happen. In other words, at level 40, the system knows that your code has violated integrity or other level 40 or level 50 rules. After the system files its exception report, which does impact performance at level 30, the system patches up the request to run despite the violation and your results appear unimpeded by the fact that the system knows that your applications have been naughty. At level 40 and 50, the exceptions create messages and jobs fail. The best news is that a level 30 to level 40 jump does not involve changes to any profiles or authorization lists, so if all is well, it is easy to start up and run. Moreover, it has absolutely no effect on programs that adopt authority since these use the standard interface. The “if all is well part” is what we are about to show you how to assure. Once audit journaling is set up to monitor for failures, you watch it for a period of time that hopefully can include as much processing as possible. Fiscal year end is the best followed by quarterly and monthly and daily runs. The objective is to exercise as much of your code (packages and home-grown) as possible to see if it generates audit entries that would be of concern. The entries in the audit journal will have an AF type and in no time, you may find that your journal is 100 pages or more when printed. This is no big deal typically in terms of storage use and the performance impact is just about nil. You will be amazed at what will show up on your audit reports as you examine them for the first time. In this reply, I am suggesting that you do just what is necessary (audit journal options) for level 40 assurance but there are a ton of other options described in Chapter 2 of the IBM security manual that can help you audit just about whatever you may find necessary. Then, you would need to make sure that your options do not generate more entries and thus take more disk space than you want. Before you even begin the audit journal procedure, you should take stock of all the packages on your system and call all those vendors to see if they are compliant with level 40. If they are not compliant and you need their code, you cannot implement level 40 security until they become compliant and you install their new version. Most vendors are already compliant at some software version (V5R2, V5R3, V5R4, etc.) but the onus is on the user to make the determination. That’s why, regardless of what the vendors tell you, you still must run the journal for awhile to be sure that all is well. Before we set up the journals and turn on auditing, let’s examine the type of entries that you should look for in the journal to understand whether you can proceed with level 40 or you need to take action first. The Best source for this is Table 3 of the IBM V5R4 security reference manual. We repeat it below for your convenience:
1 An authority failure (AF) type entry is written to the audit (QAUDJRN) journal, if the auditing function is active. See Chapter 9 of the IBM Security manual for more information about this facet of the audit function. Figure 2: Table 3 from IBM’s V5R4 Security Reference Manual, SC42-5302 If you use the auditing function at lower security levels such as level 30, the system logs journal entries for most of the actions shown in Table 3 above. You receive warnings in the form of journal entries for potential integrity violations. As you can see in the chart, at level 40 and higher, integrity violations cause the system to fail the attempted operation. The other thing that level 40 catches is the use of unsupported interfaces. At security level 40 and higher, the system prevents attempts to directly call system programs not documented as call-level interfaces. For example, directly calling the command processing program for the SIGNOFF command fails. The system uses its own tricks in order to enable this. Without getting into a detailed explanation, it checks the domain attribute of an object and the state attribute of a program to enforce this protection. Every object belongs to either the *SYSTEM domain or the *USER domain. *SYSTEM domain objects can be accessed only by *SYSTEM state programs or by programs that inherit system state status in a supported fashion (*INHERIT). Programs are classified as either *SYSTEM state, *INHERIT state, or *USER state. The *USER state programs can directly access only *USER domain objects. When *USER state programs directly use *SYSTEM domain objects, there is a failure as noted in Table 3. A domain or state violation causes the operation to fail at security level 40 and higher. At all security levels, an AF type entry is written to the audit journal if the auditing function is active. For a domain or state violation, when the auditing function is activated and the QAUDLVL system value is set to include *PGMFAIL, an authority failure (AF) entry, violation type D or R, is written to the QAUDJRN journal when an attempt is made to use an unsupported interface. At security level 40 and higher, a user submitting a job must have *USE authority to both the job description and the user profile specified in the job description, or the job fails. At security level 30, the job runs if the submitter has *USE authority to the job description. Journal Entry: When the auditing function is activated and the QAUDLVL system value is set to *AUTFAIL, an AF entry, violation type J, is written to the QAUDJRN journal. Anybody signing on without a User ID and Password at security level 30 by pressing the Enter key may be granted access with certain subsystem descriptions. At security level 40 and higher, the system stops such attempts to sign on. When the auditing function is activated and the QAUDLVL system values include *AUTFAIL, an AF entry, violation type S is written to the QAUDJRN journal. There is a hardware facility called Enhanced Hardware Storage Protection. This hardware facility allows blocks of system information located on disk to be defined as read-write, read-only, or no access. At security level 40 and higher, the system controls how *USER state programs access these protected blocks. This support is not available at security levels less than 40. This capability is on most reasonably current AS/400 boxes, but not on earlier 9402 models and 9404 deskside models and any rack-mounted 9406 B, C, and D series machines. When the auditing function is activated and the QAUDLVL system value includes *PGMFAIL, an AF entry, violation type R, is written to the QAUDJRN journal when such violations occur. While running with audit journaling security at level 30 before migrating to level 40, you have the opportunity to test resource security for all your applications. That’s why before you make the move, you begin the auditing process. By doing a thorough analysis of the journal entries that are produced, you will be able to know that you have no issues before you move to level 40. As noted above, the two values that are most critical to set as auditing criteria are the *PGMFAIL and *AUTFAIL parameters for the QAUDLVL system value. *PGMFAIL logs journal entries for any access attempts that violate the integrity protection at security level 40. *AUTFAIL catches invalid signons (blank) as well as improper authority to job descriptions & user profiles. So, after this auditing environment is set up and turned on, your job is to monitor the audit journal for *AUTFAIL and *PGMFAIL entries while running all your applications at your current security level of 30. The key things to watch are the reason codes that are included in the AF type entries such as:
These are the codes that would indicate the presence of integrity exposures in your applications and they are the things that would crash your applications if you moved to security level 40. One more item before we begin to create the objects that you need to implement audit journaling. If you have any programs that were created before OS/400 Version 1 Release 3, they have no validation codes. This is not a severe problem, but it will create an issue at level 40 when you try to restore these objects. The best action is to use the system command CHGPGM on each of these programs and pick the FRCCRT parameter to create validation values for those programs and they will pass the level 40 security check. At level 40, based on your settings in three system values, Verify Object on Restore (QVFYOBJRST), Force Conversion on Restore (QFRCCVNRST) and Allow Object Restore (QALWOBJRST), the system will take the action you request. At restore time, these values act as a series of filters to determine whether a program will be restored without change, whether it will be re-created (converted) as it is restored, or whether it will not be restored to the system. Once you have solved all of these issues, turn on security level 40. Setting Up the Security Journal and Turning on Auditing–The Long Way There are two different ways to set up audit journaling on your system. One is the long and winding road and the other is shortcut through the woods. First I will walk you down the long path because it provides more insights into what is happening on your system. After the long way, I will show you the short cut to manage security auditing functions. When you feel you “get it,” there is nothing wrong with using the short cut. To set up security auditing, you need *AUDIT Special Authority in the user profile chosen to set this up. For this type of action, the Security Officer profile QSECOFR is appropriate. Since this may not be the first time somebody has tried to set up security auditing on your system, it would behoove you to see if auditing is already alive and well on the system. So, the first step is to check out the system to see what journals and journal receivers exist. Then, create the audit journal receiver in a library of your choice by using the Create Journal Receiver (CRTJRNRCV) command. This example uses a library called AUDITLIB for journal receivers. 1. Check to see which journals and receivers are on your system.
WRKOBJ OBJ(*ALL/*ALL) OBJTYPE(*JRN) There is another way to do this that is shown below but it is a good idea for you to run this command to see what is journaled and what is not. If your shop runs DB journaling, you will be surprised at the number of journals and receivers you have. If you do not journal at all, you may still be surprised by all of the default DB journals that the system sets up for its work and for SQL schema work. The audit journal has just one name on the system, QAUDJRN. No other name works. Moreover, the QAUDJRN journal must exist in library QSYS. Since a journal is really a filter and control point for logging journal records, the QAUDJRN can and should be left in QSYS. You can move this to another library with restrictions but again, I would not recommend doing so since it really is a system facility. 2. If you find the list of journals and receivers too onerous to scan, you can use the WRKJRN command to see the status of the audit journal if it exists. For example, you can see how many receivers have been built for it. WRKJRN QAUDJRN In most cases, unless somebody in your shop has already implemented audit journaling you can either:
or
3. Create a library for journal auditing. CRTLIB LIB(AUDITLIB) TEXT(‘Library for Audit Journal Receivers’) AUT(*EXCLUDE) 4. Create the journal receiver for auditing. This will be connected to a journal later in the process. CRTJRNRCV JRNRCV(AUDITLIB/AUDRCV0001) TEXT(‘Journal Receiver for Audit Journaling’) AUT(*EXCLUDE) Since in this scenario, a new library is created, assure that the AUDITLIB library and its journal receivers are in your backup routines so that your audit trail gets saved regularly. If it is not possible to modify the backup routines, then you should place the journal receiver in a library that is saved regularly, such as QGPL, though this is not as desirable as the recommended option. Do not place the journal receiver in library QSYS, even though that is where the journal will be. Choose a journal receiver name that can be used to create a naming convention for future journal receivers, such as AUDRCV0001. You can use the *GEN option when you change journal receivers to continue the naming convention. Using this type of naming convention permits you to have the system manage changing your journal receivers when they are full. Specify a receiver threshold appropriate to your system size and activity in the Threshold parameter. The size you choose should be based on the number of transactions on your system and the number of actions you choose to audit. If you use system change-journal management support as recommended, the journal receiver threshold must be at least 100,000 KB. The default size as we selected above (by not specifying any value) is 1,500,000 KB, which is fine for the audit journal. Specify *EXCLUDE on the AUT parameter to limit access to the information stored in the journal. 5. Create the QSYS/QAUDJRN journal by using the Create Journal (CRTJRN) command. CRTJRN JRN(QSYS/QAUDJRN) JRNRCV(JRNLIB/AUDRCV0001) MNGRCV(*SYSTEM) DLTRCV(*NO) AUT(*EXCLUDE) TEXT(‘Auditing Journal’) Though audit journaling is a system function, the QAUDJRN system audit journal is not provided by IBM. You must create it. The rules for audit journal creation are as follows:
Setting the additional options for audit journaling. 6. Set the audit level (QAUDLVL) system value. For this initial work, we will not need the system value QAUDLVL2. QAUDLVL2 is needed only if there is no more room for entries in the QAUDLVL space. To set the value, use the WRKSYSVAL command. The QAUDLVL and QAUDLVL2 system values determine which actions are logged to the audit journal for all users on the system. Start by typing: WRKSYSVAL Hit Enter Page down once to get to the second page. On the second page, you will see: 2 QAUDLVL *SEC Security auditing level _ QAUDLVL2 *SEC Security auditing level extension Make note of the existence of the QAUDLVL2 value. This may come into play later when you have already migrated to level 40 and you wish to activate many other security auditing functions. For now, place a 2 on the value QAUDLVL to change it as shown above. Assure that audit journaling is not already active on your system (should have been done in step 1 and 2) and replace the prompt values on the next panel with just these two options: *AUTFAIL *PGMFAIL Once you have determined that the system may or may not move to security level 40 by examining the audit entries, you may add as many other options to the QAUDLVL value. While you are working with the system value, feel free to press F1 on the input line and you will see all of the options and their help text explanations. If as you are becoming an expert, you activate more features than can be held by the QAUDLVL value, then you would change one of the values in the list to QAUDLVL2 and this tells the system to examine both of these values for entries. 7. Turn on System auditing. Once you have set the QAUDLVL value, it is time to officially turn on auditing. The switch to turn auditing off and on is the QAUDCTL system value. You start audit journaling by setting the QAUDCTL system value to a value other than *NONE. This value is just up from the QAUDLVL option in the above partial display. On page 2 of the system values, you will find the QAUDCTL system value as follows: 2 QAUDCTL *SEC Auditing control Place a 2 on this value to change it and hit Enter. *AUDLVL *NOQTEMP Set this system value by assuring the two options above are selected. This is all you need to do the test for security level 40 or 50. Please note that the QSYS/QAUDJRN journal must exist before you can change the QAUDCTL system value to a value other than *NONE. When you start auditing, the system attempts to write a record to the audit journal. If the attempt is not successful, you receive a message and auditing does not start. Obviously, the journal and receiver must be in place for this to happen. Once you have set up the journal and these values for level 40/50 testing, let the system run for a good while–at least past month end. Setting Up the Security Journal and Turning on Auditing–The Short Way Knowing that they could have made this process lots easier for the user community and to help auditing be more accepted, IBM built two very powerful commands a few releases after enabling security audit journaling to reduce the set up work. These two commands replace all of the journal and system value work that we have done so far. With these commands, you can display the status of auditing and you can turn it on and off in a whisk. The commands are as follows:
DSPSECAUD: Display your auditing status To see if auditing is already started, you merely type in the DSPSECAUD command and press Enter. You will be presented with the following panel if you have already set on auditing manually as described above:
Current Security Auditing Values
Security Auditing Journal Values
Security journal QAUDJRN exists . . . . . : YES
Journal receiver attached to QAUDJRN . . : AUDRCV0001
Library . . . . . . . . . . . . . . . . : AUDITLIB
Security Auditing System Values
Current QAUDCTL system value . . . . . . : *AUDLVL *NOQTEMP
Current QAUDLVL system value . . . . . . : *AUTFAIL *PGMFAIL
Current QAUDLVL2 system value . . . . . . : *NONE
Note that this display says lots of things:
Now, assume that we do nit have all of the work done as we described above. To set up audit journaling the short way, including the creation of the journal and the receivers or to modify the setting accordingly, use the CHGSECAUD command as follows: CHGSECAUD QAUDCTL(*AUDLVL *NOQTEMP) QAUDLVL(*AUTFAIL *PGMFAIL) INLJRNRCV(AUDITLIB/AUDRCV0001) This simple command sets up everything. It even creates the journal and the receivers the way they should be set up. I personally think there should be a CRTSECAUD command but IBM chose to test the system to see if it exists and if it is not as specified, the command makes it as specified in the command. That’s a lot of work. Once this command is run, the DSPSECAUD as shown above would produce the results as displayed above. Other Commands and Options Used in Security Auditing for the Security Journal When you are ready for full blown auditing, use the following commands to activate features of journaling to capture activity that may be helpful in assuring that security commitments are being met: CHGUSRAUD This command sets the action auditing for individual users if necessary.
CHGOBJAUD These two commands set object auditing for specific objects if necessary. The CHGUSRAUD command may again be used to audit specific objects for specific users. Assure that the QAUDENDACN system value is set to *NOTIFY (the default0 rather than *PWRDWNSYS. The latter option will power down the system if auditing records are incapable of being logged while the *NOTIFY option sends a message to the system operator. *NOTIFY is the default so we did not describe it in the work above. You may choose to modify the value of the QAUDFRCLVL system value to control how often audit records are written from memory to auxiliary storage. Using the default *SYS entry, the system writes the journal entries to auxiliary storage only when it determines the journal entries should be written based on internal system processing. Using this option provides the best auditing performance, but it could also cause the most auditing data loss if the system ends abnormally. You can also specify a value from 1 to 100. This would represent the number of auditing journal entries written to the security auditing journal in memory before the auditing data is written to auxiliary storage (disk). The smaller the number specified, the greater the impact on system performance and the greater probability of capturing the last failure on disk in the event of a crash. Checking Out the Journal Once you have set up the journal and turned on auditing, you can begin to sample the contents of the journal. Without special assistance in deciphering journal audit codes, the easiest command to use, short of purchasing a first-class auditing package, is the DSPAUDJRNE command. The Display Audit Journal Entries (DSPAUDJRNE) command provides you a safe and easy to use vehicle to generate security journal audit reports. The reports generated by this command are based on the audit entry types and the user profile names that are specified on the command. You can limit reports to specific time frames, and you can search detached journal receivers. You can direct these reports to your workstation display or you can send them to an output queue. Of course, you must have the proper authority to run the command in the first place: *ALLOBJ and *AUDIT special authorities. To send the report to the workstation for all authority failures for all user profiles, the following command can do the trick: DSPAUDJRNE ENTTYP(AF) USRPRF(*ALL) OUTPUT(*) Of course you can change the output parameter to *PRINT to get this in report form so that you can either scan the spool file or work with hard copy. The output that thi command produces when you first turn on audit journaling may be as brief as the following screen shot or it may be quite voluminous:
Display Report
Query . . . : QSYS/QSECAF Report width . . . . . : 208
Position to line . . . . . Shift to column . . . . . .
Line ....+....1....+....2....+....3....+....4....+....5....+....6....+....7..
Violation User Object Library Object Office DLO
type profile name name type user name
000001 AF A QUSER Q2026A2BBD QTEMP *USRSPC
000002 AF A QUSER Q2026BF04B QTEMP *USRSPC
000003 AF A QUSER Q2026E566C QTEMP *USRSPC
****** ******** End of report ********
Notice the AF entries and the A next to the entry. The “A” type failure is a harmless accounting entry. The AF entries to be concerned with are B, C, D, J, R, and S. These were described earlier in this article. This sample has none of those. Considering that we had specified *NOQTEMP as an audit value, it is interesting to find the three exceptions to involve QTEMP. The experts suggest not to worry about authority failure (AF) audit journal entries for objects in QTEMP. Work management teaches us that there is a unique QTEMP library for every user’s job and objects in QTEMP aren’t accessible once the job is gone. They disappear. Since the objects for which the authority failure entries are being generated are not permanent objects (like a program or data area), you can simply ignore these entries. And remember the objective is to not have any of these bad entries. Once you solve the underlying problems that cause the bad entries, you can then make the switch to security level 40 by tying in the following command: WRKSYSVAL Then, type QSECURITY in the “Position To” area of the display and hit Enter. You will see a subset panel such as the following:
System
Option Value Type Description
2 QSECURITY *SEC System security level
Type a 2 to change it and hit Enter. You will see a subset panel such as the following:
Type choice, press Enter.
System security level . . . 40 20=Password security only
30=Password and object security
40=Password, object, and operating
system integrity
50=Password, object, and enhanced
operating system integrity
Type in 40 and press Enter. You are now using security level 40. Congratulations and best wishes. Remember this panel if something happens that spoils your day so that you can quickly turn back to level 30. RELATED STORIES V5R4 Security: Rochester Rests Not on Its Laurels, Part 1 V5R4 Security: Rochester Rests Not on Its Laurels, Part 2
|
