Your IFS Is Probably a Treasure Trove of Unsecured Data

If your company is like most, the spooled files and PDF reports on the IFS include sensitive information that's widely accessible.

I get inspiration from many sources, but one of my clients deserves credit for this article. As he correctly noted, there's a lot of "interesting" information to be found in spooled files and in PDFs in IFS directories that are left on the system—sometimes for a very long time. So thanks to TJ for inspiring me to dig into this important topic.

At this point, pause for a moment and think about your organization's policy on retaining both spooled files and other types of reports. Some organizations have cleanup routines that delete spooled files after one or two weeks. Other organizations either have no policy or users insist on keeping spooled files around for historical purposes. And while spooled files are often managed, it's rare that I see PDFs residing in directories controlled—that is, purged on a regular basis.

Next, consider the type of information contained in the PDFs in your directories and spooled files in your output queues. Aside from taking up disk space and consuming time during a backup, what's the issue with leaving these reports on the system? The issue is the contents of those reports, along with who has access to them.

It's obvious that when reports are known to include credit card numbers or other personal information, they need to be protected. But, think beyond the obvious. What about reports that list prices or inventory levels? Wouldn't that information be helpful to your competition? What about reports containing financial information? For publically held companies, there's a quiet period that precedes quarterly reporting or other significant transactions. What damage would be done if these reports are leaked?

Finally, I'd like you to think about the reports that administrators create—both for their own use and for use by teams such as internal audit. For example, many of you run the Analyze Default Password (ANZDFTPWD) command. As the name suggests, the generated spooled file lists all profiles on the system that have a default password (that is, a password that's the same as the profile name). Who besides yourself can view this report? Certainly any user with *SPLCTL special authority has that ability. Other users may also have access, depending on how the Display Data (DSPDTA), Operational Control (OPRCTL), and Authority to Check (AUTCHK) parameters have been defined for the output queue. 

Spooled File Considerations

*SPLCTL is one of the most over-used special authorities, and I can understand why. By default, only the user creating a spooled file can view it. Many times, a user creates a report, but then the rest of the department needs access. The easiest—and most obvious—way to accomplish this is to grant the users *SPLCTL.

Unfortunately, access is granted to reports you intend to share as well as every spooled file on the system, regardless of the user's authority to the output queue containing the spooled files. (Think of *SPLCTL as the *ALLOBJ of spooled files.) The more secure way of sharing spooled files is to modify the attributes of the output queue (DSPDTA, OPRCTL, and AUTCHK) to allow sharing of its contents. (See Chapter 6 of the IBM i Security Reference Manual or Chapter 8 in my book, IBM i Security Administration and Compliance for a description of using these attributes.)

Users with *JOBCTL special authority may also have access to all spooled files on the system—again depending the output queue's configuration. Bottom line: you may think your spooled files are secure, but it's likely more users have access than you realize. Use the Print Queue Authority (PRTQAUT) command to get a listing of all output queue settings.

PDF and Image Considerations

Many of you have gone from using a spooled file version of a report to a PDF. Many PDFs start out as a spooled file but are converted into a PDF and emailed off the system. The spooled file is usually deleted once the conversion is successful; however, the PDF is often retained. What is the authority of the directory containing those PDFs? For Policy Minder and Risk Assessor, we've set the *PUBLIC authority to *EXCLUDE, so only those with *ALLOBJ can access the directories. We do this because of the sensitive information contained in the reports.

Have you given your organization's directories this consideration? Most organizations have not, leaving this as a significant vulnerability on most systems. Since many organizations share root, all someone has to do is map a drive to root using Windows Explorer, open root, navigate down to the directory containing the reports, read each report to determine what information is most useful, and be on their way to harming your organization (think disgruntled employee). Make sure directories are secured such that only users with a business need to know have access—that is, use the Change Authority (CHGAUT) command to set the *PUBLIC authority of the directory to DTAAUT(*EXCLUDE) OBJAUT(*NONE) and grant the appropriate users DTAAUT(*RWX) OBJAUT(*NONE) authority.

While not exactly a report, images also need consideration because they are often pulled into a report. What are those images of? Receipts? Healthcare information? Signatures that are used on printed checks or letters? Depending on what these are images of, these too can pose significant risk to your organization if they get into the wrong hands. The same authority recommendations for PDFs also apply to images.

Final Thoughts

I often discuss the need to protect the data on your systems, meaning the access users have to database files. But reports (both spooled files and PDFs) can contain valuable information as well. I encourage you to take a serious look at the reports and images that are retained on your system. Given the type of information they contain, are they secured adequately? Or is there a risk the information could be viewed and used against your organization?