Happy (Audit) Trails to You...
Question: Is there a way to log all sign-on attempts, whether successful or unsuccessful? I want to know the user, date, time, and sign-off time of each attempt.
Answer: The OS/400 audit functions provide this information, but you need to combine the information from multiple audit records to get the details you want.
To set up security auditing, perform the following steps (note that setting up auditing requires *AUDIT special authority):
1. Create a journal receiver in a library of your choice by using the Create Journal Receiver (CRTJRNRCV) command. This example uses a library called MYLIB for journal receivers: You can select any journal receiver name, but I recommend using a name that ends with a four-digit number, which allows you to use the *GEN option when you change journal receivers so the system will continue using the naming convention. This naming convention is also useful if you have the system manage changing your journal receivers. THRESHOLD (5000) is the minimum threshold size if you choose this option.
2. Create the QSYS/QAUDJRN journal by using the Create Journal (CRTJRN) command: You must use the name QSYS/QAUDJRN for the audit journal. Specify the name of the journal receiver you created in the previous step. By specifying *SYSTEM in the Manage Receiver (MNGRCV) parameter, the system automatically changes the journal receiver and attaches a new one when the attached receiver exceeds the THRESHOLD limit
CRTJRNRCV JRNRCV(MYLIB/AUDRCV0001) +
THRESHOLD(5000) AUT(*EXCLUDE) +
TEXT(‘Auditing Journal Receiver’)
CRTJRN JRN(QSYS/QAUDJRN) +
MNGRCV(*SYSTEM) DLTRCV(*NO) +
AUT(*EXCLUDE) TEXT(‘Auditing Journal’)
specified in the CRTJRNRCV command. With this option, you do not have to use the CHGJRN command to detach receivers or manually create and attach new receivers. Do not have the system delete detached receivers; instead, specify DLTRCV(*NO), the default. The QAUDJRN receivers are used to store the information for your security audit trail. Ensure that you have processed the information in the journal and that the audit journal receivers are saved before deleting the journal receivers from the system.
3. Set the audit level (QAUDLVL) system value using the Change System Value (CHGSYSVAL) command: The QAUDLVL system value determines which actions are logged to the audit journal for all users on the system. The entries that must be selected to collect the unsuccessful sign-on attempts and job start-and-stop data are as follows:
• Authorization failures (*AUTFAIL) logs unsuccessful attempts to sign on to the system and access objects and is required to monitor users trying failed sign-on attempts.
• Job tasks (*JOBDTA) logs actions that affect a job, such as starting, stopping, holding, or changing jobs.
4. Set the audit level (QAUDCTL) system value using CHGSYSVAL: Start auditing by setting the QAUDCTL system value to *AUDLVL. The value *NOQTEMP is optional but reduces the volume of data recorded because the system does not have to record information about library QTEMP.
If you want to use a simple technique to set up auditing, use the Change Security Auditing (CHGSECAUD) command. CHGSECAUD creates the journal receiver and audit journal and allows you to set the system values QAUDLVL and QAUDCTL in one operation.
Use the Display Journal (DSPJRN) command to copy data from the journal receiver to a database file for processing. You want to select two entry types: PW for failed sign-on attempts, and JS for job start-and-end information.
Security Exposures in Vendor Software
Question: Our company runs an application that has serious security exposures. The application requires that end users be members of a group profile that has powerful special authority (*ALLOBJ or *JOBCTL). Our company depends on this software for major business applications, so we cannot stop using it. What can be done to eliminate this exposure? (The vendor has said that we cannot change the group profile; if we do, the application will not work.)
Answer: At this point, there is little you can do. Before you purchase software, you have leverage with a vendor about that software’s security features. If you are dissatisfied with one vendor’s offerings, you can continue to search for an application that better suits your needs. After you have purchased an application and integrated it into your business process, it is almost impossible to change applications. I can only advise you to make sure that any new software you install meets your security requirements. See the sidebar “Software Security Checklist” for questions to ask software vendors before you make your next purchase.
Vendors need to convey to their customers the importance of tight security before customers purchase a product. However, because you have already purchased software
CHGSYSVAL SYSVAL(QAUDLVL) +
CHGSYSVAL SYSVAL(QAUDCTL) +
with security exposures, I recommend that you write a note to the vendor explaining the nature of the exposure and send a copy of your security concerns to AS/400 Security, IBM Development Laboratory, Rochester, MN 55901. IBM is willing to work with AS/400 vendors to assist them in making their software secure.
Software Security Checklist
This list of questions will help you evaluate new and existing application packages for potential problems in security or disaster recovery. Do your own research but also have the vendor answer these questions. They are designed such that a YES answer indicates a secure choice.
ﾀ YESﾀﾀﾀNO Does the application package support security levels 40 and 50? Note: Unless the application works at security level 40, consider alternative software.
ﾀ YESﾀﾀﾀNO Do you provide a system integrity statement, similar to the following example, for the application?
Example: The _________ company guarantees that ___________ does not introduce security exposures or circumvent the security controls of your AS/400. Should any security integrity problems be found, changes will be provided without cost to correct any exposures.
ﾀ YESﾀﾀﾀNO Can a profile other than the QSECOFR user profile install or upgrade the application? For instance, can a program that adopts *ALLOBJ and *SECADM special authority do the installation?
ﾀ YESﾀﾀﾀNO Will installation leave all security settings of the system, such as system values and network attributes, unchanged? If NO, the product documentation should describe all changes in detail, including any changes required to the system library list.
ﾀ YESﾀﾀﾀNO Are installation-created security objects, such as job descriptions with user names and authorization lists, described in detail in the documentation?
ﾀ YESﾀﾀﾀNO If the application creates job descriptions naming a user profile, is the authority *PUBLIC(*EXCLUDE)?
ﾀ YESﾀﾀﾀNO Does the application avoid shipping or creating user profiles with *ALLJOB authority?
ﾀ YESﾀﾀﾀNO Can the product be used without any default user profiles specified in the communication entries of subsystems? If NO, describe all communication entries that require a default user.
ﾀ YESﾀﾀﾀNO Are all user profiles, including those used as group profiles, and the owner of production objects created with a password of *NONE and *PUBLIC authority of *EXCLUDE?
ﾀ YESﾀﾀﾀNO Does the application have “all programs adopt” owned by the application profile rather than by an IBM profile such as QSECOFR or QPGMR? If NO, the list of programs that adopt and their functions should be documented.
ﾀ YESﾀﾀﾀNO Does the application avoid storing user passwords? If NO, are the passwords encrypted, or does the application use a validation list object to prevent disclosure of user passwords?
ﾀ YESﾀﾀﾀNO Does your product support the exits for the DDMACC and PCSACC attributes and the registration information facility? This question is applicable for client/server and ODBC products.
ﾀ YESﾀﾀﾀNO What are the save requirements to save the objects for this application? Are all application objects saved by a SAVLIB *NONSYS or SAVCHGOBJ? If NO, what are the save requirements?
ﾀ YESﾀﾀﾀNO Can the software be installed on any AS/400, or is installation limited to a specific system serial number? If NO, what provisions are available to install the software at a hot site in the event of a disaster?
ﾀ YESﾀﾀﾀNO Is the application structure supportable under hot site backup software?
ﾀ YESﾀﾀﾀNO Does the application provide a menu for end users to select application functions?
ﾀ YESﾀﾀﾀNO Can the application menu be customized so that selected users are allowed access to different menu options?
ﾀ YESﾀﾀﾀNO Are users whose profiles specify LMTCPB(*YES) prevented from command line access? Are all command lines available to menu users controlled by the LMTCPB option of the user profile?
ﾀ YESﾀﾀﾀNO Do any application functions give command line access? If YES, can this capability be turned off without crippling the intended function?
ﾀ YESﾀﾀﾀNO Does the application avoid adopting a powerful profile and then put up a command line, or does it provide a function key that puts up a command line, or does it provide a pop-up window with a command line? (The exposure is that the application is most likely propagating *ALLOBJ through to the command line.)
ﾀ YESﾀﾀﾀNO Can the menus of the application be integrated into the existing menu system?
ﾀ YESﾀﾀﾀNO Can maintenance personnel service the product without special authority? If NO, please detail the special authority needed. (Note: Maintenance requiring *SERVICE or *ALLOBJ special authority indicates a potential exposure that should be avoided.)
ﾀ YESﾀﾀﾀNO Can the installation select or change the name of application-related user profiles to meet installation naming conventions?