The short answer to that question is no, but there are at least two scenarios where it makes more sense to use the Authority Collection feature added in V7R3 than the audit journal. Read on for details!
During a class I was teaching, someone asked if they should stop auditing the commands a user was running and enable Authority Collection to log users’ activity instead. Since her need was to log users’ activity to satisfy audit/compliance requirements, the answer to her question was a resounding no. That made me wonder if others have similar questions about replacing the operating system’s auditing features with the Authority Collection features. While there are two instances where I think you’ll want to use Authority Collection rather than the audit journal, there are no scenarios that justify reducing what you’ve currently configured for auditing.
Why Authority Collection is Not a Replacement for the Audit Journal
Several reasons immediately come to mind as to why the authority collection isn’t a replacement for the audit journal:
1. Authority Collection could never be a full-on replacement for the audit journal because it simply doesn’t collect all of the actions that the audit journal logs. The purpose of the Authority Collection feature is to collect access to objects—either by user or by an object itself. It doesn’t collect specific actions, such as changing a system value (logged via the SV audit journal entry) or accessing the system via FTP or ODBC (logged via the GR audit journal entry) nor does it log the “before” as well as “after” values when changing an attribute of a user profile (via a CP audit journal entry), to name a few examples.
2. Another reason is the way audit journal entries are stored. When auditing was added to the system way back in V1R3, a journal receiver (*JRNRCV) was chosen as the storage repository because it preserves the integrity of the entries. Given the design of a journal receiver, you cannot modify or remove an entry, thus ensuring the integrity of the entries, which is why you don’t need file integrity monitoring software for the audit journal on IBM i if you have to maintain compliance with the Payment Card Industry’s Data Security Standard (PCI DSS). An Authority Collection is stored in an internal object and, while not easily modified, doesn’t come with the integrity features of a journal receiver object.
3. Journal receivers are much more easily saved than an Authority Collection. If you have enabled Authority Collection on a user profile or an object, the fact that the collection has been configured is saved when you save the profile or the object, but none of what’s been collected is saved. To save the Authority Collection entries, you must select the entries and save them to a file using SQL and then save that file. This is much more cumbersome than simply saving *JRNRCV objects.
4. Finally, the authority collection doesn’t log every access; it only collects information on the first unique access. For example, if the same user accesses the same file 100 times using the same program to open that file and that program has the same authority requirements (for example, it requires *USE to the SALARY file to run successfully), only one entry will be in the authority collection for that user. This is so the collection is not flooded with duplicate entries. This is what disqualifies it as a replacement for the audit journal, especially when you have a compliance requirement. For audit and compliance purposes, every access must be logged.
When Should You Use Authority Collection Rather Than the Audit Journal?
I did say that there are two scenarios where I believe the Authority Collection is a more appropriate tool to use than the audit journal.
The first is when you’re trying to determine what authority a user requires to access an object. With the integrated audit feature of IBM i, you can enable *ALL object auditing on objects. Accessing an object with this audit configuration will result in either a ZR (object read) or ZC (object changed) audit journal entry. However, when trying to find information on a specific object, one must first “harvest” this information out of the audit journal by gathering ZR and ZC entries and then parsing out the results to find information about the accesses for the specific object you’re interested in. If you’re trying to determine who is accessing your application’s master file, the number of audit journal entries logged can become huge as users go through their normal activities. Then, if you have an extremely busy system (think casinos (pre-COVID)), simply logging that access can cause a tremendous bump in the storage consumed for all of the journal receivers storing all of even one day’s worth of ZR and AC audit journal entries. Finally, pulling all of those entries from the audit journal for all of those entries can take a long time. Let’s just say I’ve easily been able to walk down the street, order coffee, and enjoy that coffee long before that job ends! On large and busy systems, it can be a massive about of entries to process and parse through. Authority Collection on an object (added in V7R4) is a much easier way to determine who is accessing an object. Remember, only unique accesses are collected, so even on a busy system, the number of entries will be significantly reduced in comparison to what’s collected in the audit journal. In addition, although it’s obvious what authority is required when a user’s access has generated a ZR entry (that would be *USE), it’s not obvious when the access generates a ZC entry. That’s because operations such as adding a physical file member, clearing a file, and creating a duplicate object all get logged as a ZC entry, but all require more than *CHANGE authority. Authority Collection logs the exact authority required by each user so you can know exactly what authority is required. It used to be a bit of trial and error when reworking an object’s authority when the user generated a ZC entry. I’d start by granting the user *CHANGE and, if an authority failure occurred, then grant more, sometimes asking the developer what’s happening at that particular point in the application to try to eliminate some of the guesswork. No need for any of that now if you use the Authority Collection on an object.
The second scenario is when an authority failure occurs. Rather than looking at an Authority Failure (AF) entry in the audit journal, simply starting the Authority Collection on the profile and having the user re-create the failure will allow you to quickly determine what object the failure is occurring on, what authority is required, and where the user’s current authority is coming from. I’ve had cases in which a user’s authority should have been coming from adopted authority, but for some reason, the program accessing the object wasn’t adopting at all or was incorrectly owned and therefore not adopting the right profile. All of this can easily be discovered using Authority Collection—not so much if you’re attempting this via the ZR /ZC audit journal entries. All the audit journal will tell you is the object the authority failure is occurring on and the program running at the time of the failure. It takes some detective work to determine the actual cause.
Summary
While the Authority Collection is not a replacement for the audit journal, there are at least two examples where the Authority Collection can make your life significantly easier than attempting to use the audit journal. If you haven’t tried the Authority Collection feature, give it a try the next time you have one of these two scenarios I’ve described.
For more information on authority collection:
- Chapter 16, IBM i Security Administration and Compliance, Third Edition by Carol Woodbury
- Chapter 10, IBM i Security Reference
Previous articles:
New Release! What New Security Features Does IBM i V7R4 Bring Us?
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