Carol discusses the security features coming in the new version of IBM i.
V7R3 provides some new and changed features in the IBM i integrated auditing function as well as a new feature that will take the guesswork out of implementing object-level security. I want to save the best for last, so I’ll start with the updated auditing features.
New and Changed Auditing Features
The CP (Changes to User Profiles) audit journal entry has always contained useful information about a user profile, but in previous releases it logged only the security-relevant user profile attributes when a profile was created or changed. CP entries never included attributes such as the Attention program, Job description, Limit device sessions, or Message queue. In V7R3, all of the attributes with the exception of the TEXT and AUT (*PUBLIC authority) attributes are part of the CP audit journal entry when a profile is created, and all fields except the TEXT field are part of the entry when a profile is changed.
Three new values can be specified for the QAUDLVL (Auditing level) system value: *NETSECURE (to audit secure network connections), *NETTELSVR (to audit Telnet connections), and *NETUDP (to audit UDP connections). In addition, *NETSCK is no longer considered a subset of *NETCMN. While the mail and DHCP functions logged with *NETSCK will still be logged when specifying *NETCMN, if you want to log accepts and connects of socket connections, you must specify *NETSCK separately for QAUDLVL.
Authority Collection
V7R3 introduces a feature called authority collection. Authority collection is part of the base operating system and requires no additional operating system features. Authority collection provides a way to determine exactly what authority is required when an object (such as a program, file, or directory) is accessed. The motivation behind IBM’s providing this function is to provide a tool to help security administrators and application providers understand the minimum authority required when accessing objects. If you think about the security scheme of most IBM i applications, they were designed with menu security but did not take care to properly secure the application objects (e.g., files, programs, data areas). As a result, many applications’ objects are set with *PUBLIC authority of *CHANGE or *ALL when a more restrictive setting would be sufficient. Authority collection will make changing the authority settings less risky because you can tell—prior to changing any settings—exactly what authority is required for each application function.
To use authority collection to rework an application’s security settings, choose one of your power users and run the STRAUTCOL (Start Authority Collection) command (see Figure 1). You have many options for specifying what data you want to collect. I’m guessing that you’ll be like I was when I first started to use this feature and specify that you want to collect everything! Once you do that and start to look at the data, you’ll quickly find out that the analysis is far less overwhelming if you narrow down what is collected. So in this example, I have specified that I want to collect the authority information whenever user CWOODBURY accesses *PGM and *FILE objects in the APPDTALIB, APPOBJLIB, and LOCLIB libraries.
Once you run this command, the collection starts immediately—no need to have CWOODBURY log off, then on again. You can also view the collected data at any time—no need to end the collection prior to viewing it. Once CWOODBURY has run through her tasks, you can examine what has been collected by running a query against the AUTHORITY_COLLECTION view.
Figure 1: The STRAUTCOL (Start Authority Collection) command
The amount of information recorded for each entry in the collection has more details than you’ll likely ever need or want to know. However, some information is invaluable—specifically the DETAILED_REQUIRED_AUTHORITY and DETAILED_CURRENT_AUTHORITY fields. The field names perfectly describe their contents. With the DETAILED_REQUIRED_AUTHORITY field, gone is the guessing game or trial and error when trying to determine how much authority to assign. Also incredibly useful are the AUTHORITY_SOURCE and ADOPTED_AUTHORITY_SOURCE fields, which list where the authority named in the DETAILED_CURRENT_AUTHORITY field comes from.
Authority collection is not limited to libraries and objects in libraries. You can also collect authority information about directories and objects in directories as well as Document Library Objects (DLOs) and folder objects.
I wish the authority collection feature had been available at one of our clients when we were trying to secure a directory containing sensitive information. Before we could secure the directory, we had to determine what authority the service account writing into the directory required. We thought we had granted the profile the correct authority, but when we ran the process, it failed with an authority error. Through trial and error, we finally got the authority set correctly. If authority collection had been available, we could have simply turned on authority collection for the service account, specifying the directory being secured, run the process, examined the DETAILED_REQUIRED_AUTHORITY field, granted the authority listed to the service account, set *PUBLIC authority to *DTAAUT(*EXCLUDE) OBJAUT(*NONE), and then know that the process would continue to work as it did previously.
Figure 2 shows the result of running a query against the AUTHORTY_COLLECTION view. In this case, I wanted to see only the pathname, the authority required, and the current authority. The first line of Figure 2 shows the entry that was logged when the attempt to list the contents of a directory failed. The second and third lines show the entries when the access completed successfully after I granted the user DTAAUT(*RX) OBJAUT(*NONE) to the /SkyView directory.
Figure 2: Using Run SQL Scripts to query the contents of the authority collection
Technical Note
The collection is not a log. In other words, the entries are not added to the collection in timestamp order. When I first began using the function, I assumed that new entries would be added at the end of the collection. I didn’t realize that I was incorrect in that assumption and thought the function wasn’t working correctly. The secret to working with the collection is to query on the objects you’re interested in. Don’t look at the full collection top to bottom (as you would a log file) and attempt to make sense of it!
Authority collection can be used to simply and verify the authority settings in many situations. Here are just a few:
- Run a query before rolling out a new security implementation to your entire user base and ensure your test users have all the authority required to run the application and that it’s coming from the source you intended.
- Determine which application objects (especially *FILE objects) can have their authority immediately set to a more restricted authority setting, without fear that the application will stop working. This is especially helpful when the QCRTAUT system value has been set to *ALL. Some file accesses (such as when adding a physical file member) require more than *CHANGE authority. So it’s difficult to know what will break if you change QCRTAUT from *ALL to the system default of *CHANGE. You can query the authority collection and list the files that require more than *CHANGE authority to run the application. You may want to secure the files even further, but you can at least make this initial step to start to reduce your risk.
- Determine the exact authority required to work with IFS objects prior to implementing a new FTP process or ODBC connection on production.
- Determine the authority required for service accounts to work with database files. Service accounts are often created with *ALLOBJ special authority because the authority that’s required is unknown. Simply turn on the authority collection for the service account, examine the entries, and determine the authority required. Undoubtedly, it will not require *ALLOBJ!
- Use the authority-required fields to prove to developers and application providers that *ALL authority is not required!
Here’s some additional information about authority collection:
- To run the authority collection commands, you must have either *ALLOBJ special authority or be authorized to the Database Security Administrator function (QIBM_DB_SECADM). You can administer this function via Application Administration (which is available as part of Navigator for i) or the Work with Function Usage (WRKFCNUSG) command.
- The Limit User Function (Application Administration) settings are not recorded.
- For those features where authority to an object plus some special authority is required, the special authority requirement is not recorded. For example, the CRTUSRPRF (Create User Profile) command requires the user to have *SECADM special authority. The special authority requirement is not in the authority collection.
- To display whether a collection is active and/or an authority collection repository exists for a user, run the DSPUSRPRF (Display User Profile) command and scroll to the end of the display.
- While a user’s collection setting is saved when running the SAVSECDTA (Save Security Data) command, the actual collection data is not. If you want to save the collection data, you’ll have to save it into a file, which can then be saved/restored through normal IBM i interfaces.
- If an authority collection exists and the profile is deleted, its authority collection is also deleted.
- If you specify to collect authority for all objects in all libraries, some objects, such as operating system programs are omitted from the collection; however, objects, such as IBM-supplied commands will be included in the collection data
- See Chapter 10 (new in V7R3 and dedicated to this new feature) of the IBM i Security Reference manual for more details of the authority collection, including the complete layout of the authority collection view.
Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies: SkyView Partners and DXR Security. Her practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.
Carol is known worldwide as an author and award-winning speaker on security technology, specializing in IBM i security topics. She has written seven books on IBM i security, including her two current books, IBM i Security Administration and Compliance, 3rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.
MC Press books written by Carol Woodbury available now on the MC Press Bookstore.
 |
||
 |
|
IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
|
 |
|
Mastering IBM i Security Get the must-have guide by the industry’s #1 security authority. List Price $49.95 Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online