Be sure you're managing confidential data appropriately.

Editor's Note: This article is an excerpt (chapter 8) from IBM i Security Administration and Compliance, published by MC Press.

Many organizations fail to consider the fact that they may have confidential or private information that gets printed. If your security policy requires you to secure all confidential or private information, you need to think about whether or not this type of data is part of your printed output. If it is, you'll need to assess the security settings on the output queues that contain the spooled files (printed output).

In many organizations, printers are everywhere — in public areas as well as on employees' desks — and they can produce documents and reports containing significant customer and corporate information. For some companies, what is printed could constitute a vulnerability and a compliance issue. Even in this electronic age, almost everyone in an organization can print a plethora of reports and walk right out of the building with the information. And hackers have been known to "dumpster dive" — to literally sift through the garbage in a dumpster, looking for reports that include private information (e.g., credit-card numbers, Social Security numbers, social insurance numbers).

Even in organizations that have gone "green," some reports are still printed. Therefore, to reduce the chances of printed output getting into the wrong hands, you may need to secure output queues, reorganize menus, and even move printers to more-secure locations. Then, after the information has been printed and reviewed, the printouts should be destroyed appropriately — most likely through shredding. As part of your employee awareness program and training about your organization's security policy, users need to be educated not to just toss these reports into their wastebaskets.

Output queues (outqs) are a functional necessity in IBM i, but that doesn't mean all users need to have access to data in all output queues. Yet that's exactly the way many organizations' outqs are configured. To appreciate the importance of controlling access to output queues, remember that you can use output queues not only to print spooled files but also to display them. Output queue security is one of the least obvious forms of security in IBM i. To achieve the desired results, you must carefully plan and design your output queue strategy.

Security-Related Output Queue Attributes

You create output queues using the CRTOUTQ (Create Output Queue) command. The values you specify for a few security-related CRTOUTQ command parameters determine how you control user access to output queues and spooled data. You can change these output queue attributes using the CHGOUTQ (Change Output Queue) and WRKOUTQD (Work with Output Queue Description) commands. (Before you can change the attributes for an output queue, you must first stop any writers attached to it.)

Four CRTOUTQ command parameters — DSPDTA (Display data), OPRCTL (Operator control), AUTCHK (Authority check), and AUT (Authority) — work with an output queue's existing public and private authorities to determine who can and cannot view and manipulate the output queue's spooled files. Before you start to design your output queue security strategy, you need to fully comprehend the role of each of these attributes. You'll also want to understand the authority required to start and stop the writers.

Don't feel bad if you don't grasp all the nuances of securing outqs the first time you read this chapter. The attributes interact with each other differently, depending on the value of each attribute. I often have to go back and look at the charts before I can achieve the desired results.

DSPDTA (Display Data)

The CRTOUTQ command's DSPDTA parameter specifies the access that users with at least *READ authority have to the outq. A value of *YES means that users who have *READ access can display, copy, and send the data from any spooled file on the queue — using the SNDNETSPLF (Send Network Spooled File) or SNDTCPSPLF (Send TCP/IP Spooled File) command, for example. A value of *NO specifies that users who have *READ authority to the output queue can display, copy, and send the output data only from their own spooled files, unless…

• They have *JOBCTL special authority and the output queue's OPRCTL attribute value is *YES, or
• They have *CHANGE authority to the output queue and the output queue's AUTCHK attribute value is *DTAAUT, or
• They own the output queue and the AUTCHK value is *OWNER.

If the DSPDTA value is *OWNER, only the owner of a spooled file can display, copy, send, or move the spooled file. *OWNER is the appropriate DSPDTA value for operators who manage output queue entries but shouldn't be able to view the contents of spooled files. When you specify OPRCTL(*YES) and DSPDTA(*OWNER) for an output queue, a user profile with *JOBCTL special authority can hold, change, delete, and release spooled files on that output queue but cannot display, copy, send, or move the spooled files.

OPRCTL (Operator Control)

The CRTOUTQ command's OPRCTL parameter specifies whether a user who has *JOBCTL special authority can manage or control the files on an output queue. When you specify OPRCTL(*YES), a user profile with *JOBCTL special authority can control the output queue (e.g., hold, release, start a writer to the queue) and manage the spooled file entries (e.g., hold, release, change, delete). As described above, when the output queue's DSPDTA attribute value is *NO, user profiles with *JOBCTL special authority can still display, copy, send, and move all users' spooled files.

Before assigning *JOBCTL special authority to users' profiles to give them the capability of starting their own print writer, you should consider providing them with a program that adopts authority and starts the writer for them. Programs that adopt authority also adopt the owner's special authorities, such as *JOBCTL. Assigning users *JOBCTL gives them significantly more capabilities than just starting and stopping writers. *JOBCTL lets users hold, change the priority of, or even end any job on the system. Providing a program that performs the starting and stopping of writers permits users to take these actions but doesn't give them the full capabilities associated with assigning *JOBCTL to their user profiles.

AUTCHK (Authority Check)

The CRTOUTQ command's AUTCHK parameter specifies whether the commands that check a requesting user's authority to an output queue should check whether the user owns the output queue (*OWNER) or just has data authority (*DTAAUT) to the output queue. When the AUTCHK value is *OWNER, only the user who owns the output queue can change or delete spooled files owned by other user profiles. When the value is *DTAAUT, any user with *READ, *ADD, and *DLT authority to the output queue can change or delete other users' spooled files on that output queue.

AUT (Authority)

Last, the CRTOUTQ command's AUT parameter specifies the *PUBLIC authority of the outq. You can use the EDTOBJAUT (Edit Object Authority), GRTOBJAUT (Grant Object Authority), or RVKOBJAUT (Revoke Object Authority) command to modify this authority.

*SPLCTL Special Authority

The last, and perhaps most important, point to remember regarding output queue security is that a user who has *SPLCTL special authority has complete access to all output queues and spooled files, regardless of which outq attributes and authorities are specified. Think of *SPLCTL as the "*ALLOBJ" of spooled files. This means that if any user on your system has *SPLCTL special authority, you truly can't secure any output — that person will have authority to view everything in every outq. Some organizations may not have any confidential or private data in their spooled files. However, if you have even one outq that contains confidential reports, you need to take action (i.e., alter the attributes of the outq) and remove the user's *SPLCTL authority.

Table 8.1 reproduces a chart from IBM's System i Security Reference that describes the printing functions and the parameter values required to run them. I sometimes get confused reading this table, so here's a hint: The "Printing function" column lists the commands available for working with outqs, spooled files, and writers. The other columns list the values that must be set if you are to run one of the commands. You can read the "Printing function" column to determine the commands that can be run, but to make sense of what values must be set, read the rest of the columns straight across, one line at a time — like you're reading a book. For example, to run the DSPSPLF (Display Spooled File), CPYSPLF (Copy Spooled File), SNDNETSPLF, or SNDTCPSPLF command, the DSPDTA parameter must be set to *YES and the user must have at least *READ authority to the outq (and it doesn't matter what the values of the AUTCHK and OPRCTL parameters are, nor does the user require any special authorities) or the DSPDTA parameter can be *NO, but in that case the AUTCHK parameter must be *DTAAUT and the user must have *READ, *ADD, and *DLT authority to the outq, and so forth.

Table 8.1: Authority Required to Perform Printing Functions

Output Queue Ownership

The issue of output queue security also raises the question of who should own output queues. This may seem like a simple question, but it's important for two reasons: First, the owner of the output queue can modify the outq's attributes as well as grant and revoke authorities to the outq, which means the owner controls who can view and work with spooled files on that queue. Second, the AUTCHK parameter checks the ownership of the output queue as part of the authorization test when the queue is accessed.

The system operator should be responsible for creating and controlling output queues that hold data considered public or unsecured. You can use this ownership with the authority parameters on the CRTOUTQ command to create an environment that lets users control their own print files and print on various printers in their work areas.

For secured data (e.g., payroll, human resources, financial statements), the department supervisor profile or the supervisor's role (i.e., his or her group profile) is a good candidate for owning the outq. This person (or role) is the one that determines which users should be allowed to see the reports contained in the outq.

Sample Output Queue Security Implementation

For example purposes, consider an organization that has outqs in the IT department, the financial area (e.g., accounts payable, accounts receivable, general ledger), human resources, the order/sales departments, and the warehouse. Let's assume you want to secure the financial spooled files — an output queue named FINOUTQ — but you want the operator to manage the queues. Let's also say you want to secure the human resources output queue — output queue HROUTQ — and spooled files. You want no one except HR personnel to manage this output queue and its spooled files. The remaining outqs should have minimum security and allow complete access to any spooled file and to the outq itself. How do you accomplish this?

First, create all the outqs except FINOUTQ and HROUTQ, and make the system operator profile the owner of the queues. You'd enter the following CRTOUTQ command for each output queue you create:

CRTOUTQ OUTQ(outq_lib/outq_name) +

        DSPDTA(*YES)             +

         OPRCTL(*YES)             +

         AUTCHK(*OWNER)           +

         AUT(*USE)

The combination of DSPDTA(*YES), AUTCHK(*OWNER), and AUT(*USE) for the public authority means that any user can display, copy, or send any spooled files on the output queue and that only spooled file owners can change, hold, release, or delete their own spooled files. (The owner of the output queue can change, hold, release, or delete any spooled file in the queue, regardless of who owns it.) The one exception to the limitation of AUTCHK(*OWNER) is that a user profile that has *JOBCTL special authority and OPRCTL(*YES) can change, hold, release, or delete any spooled file. This implementation lets you give system operators *JOBCTL authority to manage these outqs while limiting other users to managing their own spooled files. However, all users with at least *READ data authority can display, copy, and send any spooled file on the queue.

Next, create FINOUTQ, which will hold confidential financial reports. You want all profiles to have access only to their own reports, and you want the operator to manage the queue without being able to view the spooled files. You'd create FINOUTQ as follows, with FINUSER as the owner:

CRTOUTQ OUTQ(outq_lib/FINOUTQ) +

         DSPDTA(*OWNER)         +

         OPRCTL(*YES)           +

         AUTCHK(*OWNER)         +

         AUT(*USE)

Although everyone, including the system operator, can access this output queue, each user profile can display, copy, or send only that user's own spooled files. The system operator, by virtue of *JOBCTL special authority and the OPRCTL(*YES) attribute on the output queue, can manage the queue but can't look at any reports other than the ones the system operator places on the queue. The DSPDTA(*OWNER) attribute ensures that only the owner of a spooled file can display, copy, or send that spooled file.

The last output queue is HROUTQ, which is extremely confidential. Only those in the HRUSER group should be able to access this output queue or these spooled files. To create this output queue, you'd use the following CRTOUTQ command:

CRTOUTQ OUTQ(outq_lib/HROUTQ) +

         DSPDTA(*YES)         +

         OPRCTL(*NO)           +

         AUTCHK(*DTAAUT)       +

         AUT(*EXCLUDE)

Make the HRUSER group profile the owner, and revoke all other authorities from the queue.

Profiles with *JOBCTL authority can't access this queue because of the queue's OPRCTL(*NO) attribute. Only the owner has any object or data authority to the queue. Only the owner can start or stop a writer to the outq. All users in the HRUSER group can display, copy, or send any spooled file on the outq. As a result of the AUTCHK(*DTAAUT) attribute and the fact that the HRUSER group profile owns the output queue, all users in the group can also change, hold, move, or delete any spooled file.

Helpful Tools

The PRTQAUT (Print Queue Authority Report) security tool, available on the SECTOOLS and SECBATCH menus, prints the security settings for both output queues and job queues on your system. The full report lists all the queues that meet the selection criteria. The command also provides a report that lists any changes since the last time you ran the report and any new output or job queues that have been added in the interim.

Navigator for i

One use of Navigator for i is to manage spooled files. If you need to e-mail a job log to IBM or your vendor for debugging, it's a snap. Simply click on the name of your system in Navigator and choose Basic Operations|Printer Output. Your spooled files will be displayed in the panel on the right, as shown in Figure 8.1. From there, you can select the desired spooled file and drag it to your desktop.

Figure 8.1: Managing spooled files in Navigator for i

 

Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies: SkyView Partners and DXR Security. Her practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known worldwide as an author and award-winning speaker on security technology, specializing in IBM i security topics. She has written seven books on IBM i security, including her two current books, IBM i Security Administration and Compliance, 3^rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		Mastering IBM i Security Get the must-have guide by the industry’s #1 security authority. List Price $49.95 Now On Sale

Also Read

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility