Carol provides guidance on protecting data in printed reports.

I get inspiration for this column from a variety of places, but I have to give credit to one of my clients for this article. As he duly pointed out, 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 write about this important topic.

At this point, I'd like you to pause for a moment and think about your organization's policy on retaining both spooled files and other types of reports. I know 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, I'd like you to consider the type of information that's contained in the PDFs in your directories and spooled files in your outqs. 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 pretty obvious that when reports are known to have credit card numbers or other personal information they need to be protected. But I'd like you to 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). 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 outq.

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 not just to reports you intend to share but to every spooled file on the system, regardless of the user's authority to the outq 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 outq (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 outq's configuration. Bottom line is this: you may think your spooled files are secure, but it's likely that more users have access than you realize. Use the Print Queue Authority (PRTQAUT) command to get a listing of all outq 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 often deleted once the conversion is successful; however, the PDF is often retained. What is the authority of the directory containing those PDFs? For our Policy Minder and Risk Assessor products, 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? I find that most organizations have not, leaving this as a significant vulnerability on most systems. Given the fact that 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 that 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?