Security and Systems Management Newsletter for the IBM i                             Issue Date:     March 19, 2019
Security Training from

SecureMyi Services

Training from The 400 School

Training from The 400 School

Training from The 400 School

Security Training from The 400 School

Feature Article

Invisible Data Theft on IBM i - Detecting the Invisible

By Dan Riehl

How many times has your most sensitive data file been downloaded today?
For most of us, the honest answer is "I Don't Know."
That's Exactly Right! How could you possibly know?

Our great IBM i (iSeries and AS/400) has long been considered a security strongbox—a hacker's worst nightmare. Some even consider it to be unhackable. This gross misconception has caused some of us to become complacent in our due diligence related to the security and integrity of our systems and sensitive data. But IBM i security cannot rely upon it's perceived obscurity as sufficient protection in a world of potentially malicious insiders and highly trained and well-financed cyber criminals.

Securing the data on the IBM i is made especially difficult by our ubiquitous tools(e.g. FTP, ODBC, DDM) that access our data but leave no footprints. How can you reasonably expect to protect the sensitive information in your care when it can be accessed without your knowledge and without leaving ANY footprints?

Invisible Data Access Methods

When a thief steals your car, it's very easy to tell. Ug, it's not in your driveway. But how can you know when someone has stolen a sensitive database file? The file is still there and there are no traces of any access to the file. But, does that prove that the file hasn't been breached or stolen? Obviously NO.

IBM ships the IBM i with a variety of data access tools, many of which access data invisibly. We often add third-party data query tools, and we even write our own data access methods using socket programs and the database APIs. Although non-IBM data access tools might reside on your systems, I want to focus this article on the built-in or otherwise IBM-supplied tools that access data, and do not leave a trace of the activity.

If I download a database file using FTP or the IBM i Access for Windows file transfer utility, there's no built-in audit trail of that activity. There is no FTP log for the FTP server and no logging or history of IBM i Access for Windows file transfers. These file access and transfers are invisible, even to the system administrator. If I use one of these common tools to download an employee personnel file, a payroll file, a customer file, or any other file to my PC, you can't know it. Neither the IBM FTP server nor the IBM-supplied file transfer facility makes or keeps a record of that activity.

What about using ODBC applications, Distributed Data Management (DDM), and other data access methods shipped as part of IBM i? All data movement using these services is also invisible.

(Caveat: Database Journaling can be used to produce an audit trail of add, change and delete record level activity. But, if the data is accessed for "read-only" in order to steal the file(e.g. FTP or ODBC download of a file), there is no record level activity recorded, and no footprints to follow.)

What is your Security Culture?

I often visit IBM i customer sites to teach technical classes and perform IBM i security vulnerability assessments. In too many of these places, I find a shocking indifference to data security. While teaching a programming class at a rather large regional bank, class members didn't hesitate to volunteer that none of the bank's data was encrypted. Account numbers, Social Security numbers and Driver's License numbers, and even ATM PIN codes were stored as clear text in Customer Account files.

In another example, I was teaching an IBM i Security Workshop which was open to the public. During the workshop I referred to Payroll data as an example of data that must be secured from prying eyes. Two young men at the back of the classroom exchanged quizzical glances. When I asked if there was a question, one of them piped up and asked, "How are we supposed to know what to ask for on our next review if we don't know what the other people are making?" I was floored. These fellows were their company's top IBM i security staffers, and they felt it was just fine to pry into employee payroll data.

Building a strong Security and Compliance culture within the organization is critical to data security and privacy.

Security Through User Ignorance

If your users don't know how to use FTP and the IBM i Access File Transfer utility and don't understand ODBC and DDM, you might reason that their ignorance protects you. Further, you might believe that outside hackers don't care about your data. Let's examine these rationales.

Most of us have employees who came from other IBM i shops. It's not unusual to have a user who, from prior employment, knows applications by J.D. Edwards, Infor/Infinium/S2K/Lawson Software, BPCS, MAPICS or JDA Software. At their previous job, those employees might have learned the names of files and libraries for use with query tools or file upload and download tools. They might have routinely used FTP or IBM i Access for Windows file transfer. Many power users, such as data analysts and sales and marketing folks, are familiar with file names and libraries. In schools today, students are taught tools such as Microsoft Excel and Microsoft Access and learn how to use ODBC to directly access data.

And let's not ignore the technical staff. Programmers and operators, Help Desk, and Technical support people know how to use FTP, ODBC, and file transfers, and they know the names of the sensitive files.

How many salespeople leave your company to go to work for a competitor? How difficult would it be for them to tuck a USB drive loaded with customer information and sales activity reports into their pocket as they leave? While they're at it, they might get the pricing files, too. Or instead of a USB drive, maybe they just download the files and email them to a buddy who works for the competitor.

If you work in the healthcare industry, what would happen if your patient's personal health information were stolen and published on the Internet? Company financial data such as a retailer's comparative store sales can drive a stock up or down. Stealing such information and making it public before the company formally reports its earnings can be hugely profitable. But, thankfully, it is also illegal, as are other types of data theft.

You cannot rely on the technical ignorance of your employees and contractors to secure your sensitive data. They are likely not as ignorant as you might suspect.

I am not trying to impugn our fellow workers. But, under certain circumstances, I have seen even the most trusted employee succumb to the allure of a big pay day through stolen or manipulated data.

Object-Level Security Will Protect Me - Really?

IBM and industry pundits have long embraced the concept of object-level security, which stipulates that every user be granted access only to the files, programs, and other objects necessary to perform his or her job and receives only the minimum permissions needed to each object.

Click - to Read the Entire Article for the details

Training from 400

In This Issue

Featured Article - Invisible Access

Featured Video - Limited Capabilities??

Security Shorts - Authority - 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

    The 400 School, Inc

IBM i Security Resources

IBM Security Incident Response BLOG

IBM i Security Videos - from SecureMyi

SecureMyi Newsletter Archives

Search Security for IBM i - SecureMyi

IBM i Security Reference - 6.1

IBM i Security Reference - 7.1

IBM i Security Reference - 7.2

IBM i Security Reference - 7.3

QAUDJRN Journal Entry Types 7.3

QAUDJRN Entry Layout 7.2

QAUDJRN Entry Layout 7.3

QAUDJRN Entries by AUDLVL 7.2

QAUDJRN Entries by AUDLVL 7.3

RedBook - Security Guide for IBM i 6.1

National Vulnerability Database - NIST

PCI Security Standards Council


HIPAA Resources

EU GDPR Information Portal

CISSP - Certification

Follow SecureMyi on Twitter
Follow SecureMyi on LinkedIn=
Follow SecureMyi on YouTube

Training from The 400 School

Training from The 400 School

Featured YouTube Educational Video

IBM i Security

Misconceptions on User Limited Capabilities LMTCPB(*YES)

Featured Video - Misconceptions on User Limited Capabilities LMTCPB(*YES)

Training from The 400 School

Security Shorts

Security Shorts

Assigning Object Authority to Newly Created 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.

Sponsored Links

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

IT Security and Compliance Group

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

LIVE Training from The 400 School, Inc

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

LIVE Online Hands-On Workshops

  • ILE RPG IV Programming
  • RPG/400 and RPG III Programming
  • ILE COBOL/400 Programming
  • Interactive Programming Workshops
  • System Operations Workshops
  • System Administration and Control
  • Security and Auditing Workshops
  • Control Language Programming
  • IBM i Concepts and Facilities
  • Query Workshop

Training from The 400 School

Training from The 400 School
Security Training from The 400 School

Security Training from The 400 School

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

Copyright 2014-2019 -, all rights reserved | St Louis MO 63017