Security Patrol: Security Questions & Answers

IBM i (OS/400, i5/OS)
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Q:My question deals with the IBM-supplied library QGPL which ships with public

authority of *CHANGE. Since we put certain production programs in the library,

and it is controlled by our change control software, I would like to change the

public access for library QGPL to *USE. Will I have problems (e.g., system

functions having an authority problem) if I make this change?

A:You can change the authority for the library QGPL from *CHANGE to *USE. IBM

shipped library QGPL with public authority of *CHANGE because it is the default

library for creating objects. If you do change the authority, users who attempt

to insert objects will receive an error message. To prevent objects from being

created into library QGPL, be sure the user's current library (CURLIB) is not

*CRTDFT and does not explicitly name QGPL.

Q: I suspect that one of the programmers in our installation has a program that

adopts access as a security officer. I have changed the QSECOFR password to

prevent the use of the profile.

I used the Display Program Adopt (DSPPGMADP) command to list the programs that

adopt the user profile QSECOFR and the other profiles that have *ALLOBJ and

*SECADM authority. It is difficult, however, to isolate which program the

programmer may be using because the program list is large.

Is there some wayùother than asking the programmerùto determine if the

programmer is calling a program that adopts access as a security officer?

A:An alternative to using the DSPPGMADP command to find programs that adopt

authority is to use the auditing features of OS/400. You can audit events for

individual users or system wide. If you turn on auditing for the individual

programmer, you will be able to see which programs he uses that adopt

authority. Use these steps to record when programs that adopt authority are

used.

1. If you are not already auditing, create the objects needed to start auditing

with these commands.

CRTJRNRCV JRNRCV(jrnlib/AUDJRN0000) +

AUT(*EXCLUDE)

CRTJRN JRN(QSYS/QAUDJRN) +

JRNRCV(jrnlib/AUDJRN0000) +

AUT(*EXCLUDE)

2. Then set the audit control system value to record object and user-level

auditing events, such as authority obtained through authority adoption.

CHGSYSVAL SYSVAL(QAUDCTL) +

VALUE(*AUDLVL)

3. Change the programmer's user profile to record the use of programs that

adopt authority.

CHGUSRAUD USRPRF(programmer) +

AUDLVL(*PGMADP)

I recommend specifying the *PGMADP option only for the individual programmer.

Specifying the *PGMADP option in the Security Auditing Level (QAUDLVL) system

value would record the use of programs that adopt for all users.

When the programmer signs on and uses programs that adopt authority, the system

records the names of these programs. From this list of programs, you should be

able to find the one that is being used to adopt the security officer

authority.

Follow these steps to retrieve the information from the audit journal.

1. Extract the program adopt entries from the audit journal.

DSPJRN JRN(QAUDJRN) +

ENTTYP(AP) OUTPUT(*OUTFILE) +

OUTFILFMT(*TYPE2) +

OUTFILE(yourlib/QASYAPJE)

2. Use Query or another report tool to view the data. In the sample report in

1, the program name is listed twice: once when the program that adopts

Figure 1, the program name is listed twice: once when the program that adopts

authority starts and again when the program ends (as indicated by the S and E

entry types).

Q: I have been reprimanded for accessing a file on the system with *PUBLIC

authority. I work for a company that does not have a security policy. It is my

understanding from the AS/400 Security - Basic manual that IBM strongly

recommends a security policy be communicated verbally, but preferably in

writing.

The system has been installed for several years and has no security. If a

company has public files and has never communicated any policy as to the

responsibility of authorized users of the system, would it be fair to say that

the authorized users of the system have the authority to access any file on the

system?

A: This is not the normal technical issue that I discuss in this column. This

is a business conduct and professional ethics issue. Here are my personal

feelings about the responsibilities of individuals and companies regarding

access to information.

The security policy should be written and communicated to all system users. The

written security policy can clarify the responsibility of users relative to

data access and can strongly deter users from performing questionable

activities.

I agree with you that the security policy should be a written document. I feel

that the individual employee, however, must act responsibly even when there is

no formal security policy. I consider the information stored in a computer to

be like the information stored in the desks of your fellow employees. Even if

they leave their desks unlocked, it is not proper for another person to rummage

through the unlocked desks. The lack of a security policy does not give

individuals the right to access files outside the scope of their job

responsibility.

I have seen many installations that do not have a security policy and do not

use the available security controls. In some systems, the public has the

authority not only to view the files but also to delete the data. I am sure

that you would agree that system users do not have the right to delete the

files. Having the authority to perform an operation does not give an individual

the right to perform the operation.

In the business environment, the employee is expected to protect the

information of the company, including the confidentiality of the information.

The information in the computer files is the property of the company even if it

has been lax in protecting the information.

For those readers who do not have a security policy, this would be an excellent

time to produce one.


Security Patrol: Security Questions & Answers

Figure 1Sample Audit Journal Report

 ENTRY OBJECT LIBRARY OBJECT OBJECT TYPE NAME NAME TYPE OWNER S SECOFR WOE *PGM QSECOFR E SECOFR WOE *PGM QSECOFR 
BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  •  

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: