SecureMyi.com Security and Systems Management Newsletter for the IBM i             December 11, 2013 - Vol 3, Issue 40
Software from Cilasoft


iSecurity from SEA


Software from Cilasoft


Security software from Powertech

Feature Article

Forensic Analysis - Detecting Database Changes

By Dan Riehl - SecureMyi.com

Who added that new vendor to the vendor file? Who changed that purchase order dollar amount? And who changed that employee's hourly pay? When did it happen, and how was it accomplished? In this next article in the forensic analysis series, I examine how to audit and report on database changes. I examine the topic of DB2 for i database journaling and how you can extract meaningful data out of a database journal for your forensic analysis.

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 Activity and Forensic Analysis Part 3: Access to Sensitive Objects from the SecureMyi Security Newsletter.

And Now, Detecting Database Changes

IBM i provides two methods for collecting information on database record changes, additions, and deletions. You can write your own database trigger programs (customized for each required file), or you can use the database record-level journaling support built into the operating system. Given the complexities of database record changes when commitment control is active (i.e., with Commit and Rollback operations), trigger programs can be devilishly difficult to write correctly. In addition, the database record audit trail created by an inhouse-written trigger program may be considered "suspect" by your compliance auditors. IBM i database journaling can provide an audit trail of each record add, change, and delete operation made for the journaled file. Database journals have long been a trusted accounting of record-level activity. However, the journaling environment must be configured in a manner consistent with your ability to extract the important information about record additions, changes, and deletions.

Creating the Journal for Forensic Analysis

Several enhancements to the database journaling support have been made over the last several releases of the operating system. Some of these enhancements relate to the size and content of database journal entries.

When you want to perform forensic analysis of journaled database record changes, you do NOT want to use "skinny headers" as described in the IBM Redbook Journaling – Journal Receiver Diet tip 2: Consider using skinny headers. You implement skinny headers by shrinking the size of the journal entry headers, which can eliminate information such as the job name, user name, and program name that made the change. You can implement skinny headers by specifying on the CRTJRN or CHGJRN command a receiver size option of RCVSIZOPT(*MINFIXLEN) or by using the Fixed Length Data (FIXLENDTA) parameter to specify a value, such as FIXLENDTA(*USR). When a record is added to, changed, or deleted from a database file, you want to be able to report on ALL pertinent information, including the job, user and program used to make the change. Therefore, you do NOT want to use skinny headers.

Another enhancement in journaling support lets you specify that the journal-entry–specific data be minimized. To shrink the size of the entry-specific data, you use the CRTJRN/CHGJRN parameter MINENTDTA. To reiterate: When you need to be able to perform forensic analysis of the journal entry data, you need all the available journal-entry–specific data to be intact. Therefore, the MINENTDTA parameter needs to be specified as *NONE, meaning that complete entry-specific data will be present in each journal entry.

Read More

In This Issue


Featured Article - Detecting Database Changes

Security Shorts - Misconceptions on QINACTITV

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

    PowerTech

    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 Entries By AUDLVL

QAUDJRN Entry Layouts

RedBook - Security Guide IBM i


OSF - DataLoss DB

PCI Data Security Standard

COBIT - ISACA

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


December Events

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


Would Your IBM i Pass an Audit?
Live Webcast - Presented by Townsend Security
Wednesday, December 11 Noon CST
More Information and Register to Attend


IBM i's Top 10 Security Risks in 2013
Live Webcast - Presented by Powertech
Wednesday, December 18 1:00pm CST
More Information and Register to Attend


Merry Christmas! And Happy New Year!

We'll be back again in January, 2014.


iSecurity from SEA

Security software from Powertech

Security Shorts -

Misconceptions of QINACTITV System Value

The Inactive Job Time-Out Feature

By Dan Riehl

The System Value QINACTITV allows you to specify the amount of time (in minutes) that a job may be inactive before the system initiates an action against the offending job. The associated System value, QINACTMSGQ determines the action that is performed. Typically, the action taken is to terminate or disconnect the inactive job, resulting in the workstation display of the log-on screen which requires a re-entry of UserID and Password.

It is a good security practice, to specify a time-out value of 60 minutes or less. A signed-on workstation left unattended for any period of time presents a security risk from intruders that would take advantage of a signed-on session. We should protect our systems from this potential unauthorized workstation access. But there are some specifics about the QINACTITV System Value that are often not understood.

For example, if you are signed-on to an active workstation session and then, from that session, initiate a workstation session to another system, as in TELNET, or Display Station Pass-thru, the local interactive job will not be considered as inactive.

FTP is another example, in which, the QINACTITV value is not considered. In order to control the time-out value for FTP you use the command CHGFTPA(Change FTP Attributes) and specify the time-out value on the INACTTIMO parameter.

If you use the System Request key to start an additional interactive job from the same workstation, an action on one session will keep both sessions from being affected by the QINACTITV value.

Any action key will cause activity to be registered to the interactive workstation session, thereby marking the session as active. Action keys are keys like ENTER, PageUp/Down, Function Keys, and Help.

QINACTITV "30 Minutes" Really Means "Up to 60 Minutes"

AND, did you know that if the QINACTITV system value contains the value 30 minutes, a job may not actually be considered inactive for up to an hour? The job that monitors for inactive jobs comes alive at the interval specified in the system value.

Here is the relevant quote about this issue from the IBM Information Center.

"When the system is started, it checks for inactive jobs at the interval specified by the QINACTITV system value. For example, if the system is started at 9:46 in the morning and the QINACTITV system value is 30 minutes, it checks for inactive jobs at 10:16, 10:46, 11:16, and so on. If it discovers a job that has been inactive for 30 minutes or more, it takes the action specified by the QINACTMSGQ system value. In this example, if a job becomes inactive at 10:17, it will not be acted on until 11:16. At the 10:46 check, it has been inactive for only 29 minutes."

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



Security? See how SKYVIEW PARTNERS can help!

Security Services from SecureMyi.com

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

Copyright 2013 - SecureMyi.com, all rights reserved

SecureMyi.com | St Louis MO 63017