Security and Systems Management Newsletter for the IBM i             November 13, 2013 - Vol 3, Issue 39
Software from Cilasoft

Security software from Powertech

Software from Cilasoft

iSecurity from SEA

Feature Article

Forensic Analysis Part 3 - Tracking Access to Sensitive Files

By Dan Riehl -

In this third installment of the series dealing with forensic analysis using the QAUDJRN journal, the focus is on detecting access to sensitive files. In our heavily regulated environment, it's crucial that we keep prying eyes out of personal, private, and sensitive data. We also need to protect our files against unauthorized changes. The information I present here doesn't let you block unsanctioned access, but it does tell you when this access happens, after the fact. I once heard it said, "That which we cannot prevent, we must be able to detect."

in this article, I discuss how to audit and report on file access under everyday scenarios. I also discuss the various auditing options and how to configure the correct level of auditing you need to accomplish your reporting objectives. As examples, I examine how to audit and report on every event in which an IT staff member accesses the sensitive CREDITCARD file, whether for inquiry or for update. I also examine how to audit and report on every file accessed by using ODBC and whether the access was for inquiry or for update. The object-auditing methods I present here don't let you detect or report on database record updates—rather, I'm dealing with file access only, and whether the access was for inquiry only or for update. I cover detecting and reporting on database-update events in an upcoming installment of this Forensic Analysis series.

Auditing Revisited

I encourage you to review the previous articles in this series Forensic Analysis Using QAUDJRN, Part 1: CL Command Usage and Forensic Analysis Using QAUDJRN, Part 2: User Acitivity from the SecureMyi Security Newsletter.


Object Auditing

To audit and report on file access and access to other objects, the system value QAUDLVL must contain the value *OBJAUD. Once you've set the system value, you need to tell the system which objects you want to audit and the level of auditing you require. To begin auditing an object, you use the Change Object Auditing (CHGOBJAUD) command. Here's the command's format:

CHGOBJAUD   OBJ(Library-name/Object-name)   OBJTYPE(Object-Type)  +
                            OBJAUD(*ALL, *CHANGE, *USRPRF, *NONE)

To begin auditing ALL access to the file named CREDITCARD the command is:


Once this command is run, each time the file is accessed, an entry is written to the QAUDJRN journal. If the file is accessed in a read-only operation, a journal entry type of ZR (object opened for read) will be written. If the file is accessed for an update operation, a journal entry type of ZC (object opened for change) will be written. The formats of the ZC and ZR journal entry types are virtually identical. The ZC format fields start with ZC, and the ZR format has the same fields, but they begin with the letters ZR. Figure 1 shows the entire ZR journal entry format (as defined in the IBM-supplied file QASYZRJ5).

Read More

In This Issue

Featured Article - Tracking Access To Files

Featured Video - Virus, Worms & Malware

Security Shorts - Security for New Objects

Industry News and Calendar

Security Resources

Quick Links

Search Security Site for IBM i and i5/OS

SecureMyi Website

Security Training from The 400 School

SecureMyi Newsletter Home/Archives

Our Newsletter Sponsors

Platinum Sponsor

    Cilasoft Security Solutions

Gold Sponsor


    Skyview Partners, Inc

    Software Engineering of America

IBM i Security Resources

John Earl Memorial Tribute

IBM i Security Videos - SecureMyi

SecureMyi Newsletter Archives

Search Security for IBM i

IBM i Security Ref - 6.1

IBM i Security Ref - 7.1


QAUDJRN Entry Layouts

RedBook - Security Guide IBM i

OSF - DataLoss DB

PCI Data Security Standard


HIPAA Resources

HITECH Enforcement

CISSP - Certification

Follow SecureMyi on Twitter

Follow SecureMyi on YouTube

Security? See how SKYVIEW PARTNERS can help!

Software from Cilasoft

Security news and Events

Live Security Related Webcasts and Training for IBM i

November Events

The Truth About Viruses on IBM i
Live Webcast - Presented by Bytware
Wednesday, November 13 1:00pm CST
More Information and Register to Attend

Secure Managed File Transfer on the IBM i - Meeting Compliance
Live Webcast - Presented by Townsend Security
Thursday, November 14 Noon CST
More Information and Register to Attend

A Primer on IBM i User Profiles and How To Properly Deploy Them
Live Webcast - Presented by Powertech
Tuesday, November 19 1:00pm CST
More Information and Register to Attend

The Truth About Viruses on IBM i (International)
Live Webcast - Presented by Bytware
Wednesday, November 20 14:00 London, 15:00 Paris
More Information and Register to Attend

December Events

Live Hands-On - IBM i System Administration and Control Workshop
with Dan Riehl

Full Length Training Workshop - December 2-6
Dan Riehl presents this 5-Day Live Online Hands-on Workshop.
More Information and Register to Attend

Top 10 Vulnerabilities of IBM i Security Configurations
with Carol Woodbury

Live Webcast - Presented by Skyview Partners
Wednesday, December 4 Noon CST
More Information and Register to Attend

Security software from Powertech

iSecurity from SEA

Security? See how SKYVIEW PARTNERS can help!

Featured YouTube Educational Video

IBM i Security

Is IBM i Vulnerable to Virus, Worms and other Malware?

Featured Video - IBM i Security - Is the IBM i Vulnerable to Virus, Worms and other Malware?

Cannot Access YouTube from your office? Download the video in wmv format.   Click to Download the wmv file

Security Shorts -

Setting the Authority for New Objects

By Dan Riehl

When you create a new file or program, you have the option of specifying the authority to the new object. But we typically do not specify that authority. Each CL command used to create objects has the parameter Authority (AUT), which is used to specify the *PUBLIC authority for the new object. For most of us, we do not even see the AUT parameter because we seldom prompt the CRTxxx commands. Even if you do prompt the CRTxxx commands, the AUT parameter is usually the very last parameter in the long list. We seldom get that far in the prompt.

Understanding CRTAUT and *LIBCRTAUT

For almost all object types, the CRTxxx command uses the default value AUT(*LIBCRTAUT). This value *LIBCRTAUT is specified to assign the new object authority based upon the library in which it is created. So for one library, the value *LIBCRTAUT may mean AUT(*CHANGE), for another library it may mean AUT(*EXCLUDE), depending all on the library's CRTAUT value.

The CRTAUT setting for a library can be set explicitly, or can be derived from the System Value QCRTAUT, which ships from IBM with a value of *CHANGE. Allowing the QCRTAUT System Value to determine the CRTAUT value for your sensitive program and data libraries is usually not what you want.

When you create or change a library (CRTLIB, CHGLIB), one of the parameters is Create Authority (CRTAUT), as shown in this command to create a library:


When the library's CRTAUT value is *EXCLUDE, new objects created within the library will be set to *PUBLIC AUT(*EXCLUDE), based upon the CRTAUT of the library. Note: Be careful to specify the correct CRTAUT for your libraries, since CRTAUT(*SYSVAL) is the default value when initially creating a Library.

Overriding the Library's CRTAUT Value

You do not need to accept the CRTxxx command default of AUT(*LIBCRTAUT). You can specify the authority for the object as needed, as in the following command to Create a Data Area:


Here, the CRTAUT value of MYLIBRARY is not considered, and the data area is assigned *PUBLIC AUT(*USE) authority.

Using an Authorization List

When setting the value for a library's CRTAUT parameter, the name of an authorization list can be assigned, as shown here on the Change Library (CHGLIB) command:


Then, when a new object is created in the library, the new object will be secured by the MYAUTL authorization list. This assumes that we accepted the default value on the CRTxxx command of AUT(*LIBCRTAUT) or that we specified AUT(MYAUTL).

Using an authorization list to assign the authority for a newly created object gives you some nice flexibility. You are not limited to only assigning *PUBLIC authority, but when using an authorization list, you can assign all private authorities to the object at the time the object is created.

Object Ownership: The Gotcha

The only gotcha when it comes to assigning authority to a new object is that the object will be owned by the creator or by the creator's primary group profile. The owner will have *ALL authority to the new object, which might not be what you want, especially if you are securing the new object with an authorization list. In these cases, you will need to develop a method to reassign the ownership of the new object.

I'd be anxious to hear your ideas on the best way to set the exact authority that you want on a newly created object when the creator/owner should not have a distinct authority to the object.

I am one who believes that most objects types should be owned by an "owning" profile, whose sole purpose for existence is to own objects. For example, create the user profile PRODOWNER. Assign PRODOWNER as the owner of your production objects. This owning profile PRODOWNER is not a group profile. It is simply a profile to own objects.

This works great until someone creates a new object, which makes them (or their primary group) the owner of the new object, and not PRODOWNER.

What I'd Like to See

It would be great to have an OBJOWNER parameter on all the Create commands, where you could specify something like OBJOWNER(*LIBOBJOWN), which would assign the ownership of the new object based upon a library attribute of "Library Default Object Owner." But alas, right now we may need to retrofit the ownership of these newly created objects to set them correctly. Another option may be to restrict users from creating new objects in sensitive libraries.

Sponsored Links

IBM i, iSeries and AS/400
Security Services from SecureMyi

Expert IBM i Security Consulting
IT Security and Compliance Group. LLC

In Depth Security Assessment of IBM i
Upgrade to QSECURITY level 40 or 50
Forensic Research and Analysis
Audit Assistance and Remediation
Security Training for IT and Audit Staff
Security Software Selection & Configuration
Customized Security/System Programming

Live Training from The 400 School, Inc

Customized IBM i (AS/400) Training -
    Presented Live at your offices

Live Online Hands-On Workshops

Intro RPG IV Programming
Intro RPG/400 Programming
IBM i COBOL Programming
Interactive Programming Workshops
Introduction to System Operations
Expanded System Operations Workshop
System Administration and Control
Expanded Security Workshop
Control Language Programming
IBM i Concepts and Facilities
Concepts & Control Language
Query Workshop

Software from Cilasoft

Security software from Powertech

Security Services from

Send your IBM i Security and Systems Management News and Events!           Send your Questions, Comments, Tips and Stories

Copyright 2013 -, all rights reserved | St Louis MO 63017