Tracking File Downloads
Question: We have users who regularly download files via the download function of Client Access (V3R2). I would like to know if there is an audit anywhere that captures what is being downloaded (i.e., the SELECT statements on the download request as well as which files) and by whom. If there is nothing in the operating system, what could I do (e.g., exit points, something attached to QUSER that services the requests) to capture this information to a file?
Answer: Exit points and exit programs can capture auditing information for you with an amazing level of detail. An exit program on the Client Access file transfer function can show you who downloaded the file, what file she downloaded, when exactly the download took place, and whether the request was successful. But you probably want to audit more than just the Client Access file transfer facility, as there are several other IBM services that allow one to transfer data to the desktop. Figure 1 (page 108) has a list of exit points that enable bulk data transfer from the AS/400 to a remote client. You can write exit programs for these IBM servers and cause their results to be logged for auditing purposes. A simple exit program might record the data, time, user name, and file name of the transfer request. This information will give you the ability to see what data is being downloaded from your AS/400an ability that you dont have today. There are commercial exit point packages that you can buy, or you can write your own that will monitor these download servers. If you write your own, be sure that you handle all of the different download points, as you can never tell what service a client might choose to use.
Unfortunately the specifications for writing exit programs are strewn across several IBM manuals: the OS/400 TCP/IP Configuration and Reference V4R4 manual (SC41-
5420), the Distributed Data Management manual (SC41-5307), and the Client Access Express Host Servers V4R4MO manual (SC41-5740). But with persistence, you can gather all of this information together and create exit programs that monitor these download servers.
Question: I am struggling to explain OS/400 password expiration parameters to my internal auditors. I presented them with a report using PRTUSRPRF [Print User Profile] with *PWDINFO information. The QPWDEXPITV system value (Password Expiration
Interval) is set to 30 days. There are a number of profiles listed on the report with *SYSVAL in the expiration interval who have not signed on in the past 31 (or more) days, yet the report says NO in the Password Expired field. I have scoured the report for clues but can find no pattern in the other parameters that may affect whether a password expires. Can you provide any further insight?
Answer: The Password Expired field in the PRTUSRPRF report simply indicates that the PWDEXP parameter in the user profile is set to *YES. Because it is possible for a security administrator to expire a users password manually prior to the password expiration interval (system value QPWDEXPITV, or user profile parameter PWDEXPITV), the report necessarily details which profiles have had their PWDEXP flag turned on. The report does not indicate a YES in the Password Expired column if the date of the last change for the password is older than the password expiration interval (though a reasonable person could argue that it should); the report assumes that you will do the math yourself. But rest assured that any profile that has exceeded the PWDEXPITV value has expired its password. Though the report does not directly state this, you can infer it by comparing PWDEXPITV with the date the password was changed and the current date.
Limiting *ALLOBJ Users
Question: Our system auditor wants me to set her up with *ALLOBJ special authority, but the director doesnt want her to be able to look in certain libraries such as payroll. What is the best way to go about doing this?
Answer: It is impossible to keep an *ALLOBJ user out of any library. *ALLOBJ really means all objects: A user with *ALLOBJ special authority can read, change, and delete anything on the system. Even worse, an enterprising user with just *ALLOBJ can quickly gain any other special authority (*SECADM, *AUDIT, *IOSYSCFG, etc.) that he desires. It is simply not possible to secure a system from a user who has *ALLOBJ special authority.
Moving from QSECURITY Level 20
Question: On our last audit, one of the items we got dinged on was QSECURITY level 20. The auditor recommended going to at least level 30 so that object security is installed. After we changed to level 30 and IPLed, our software vendor had us run a program that caused all of the user profiles on our system to have the *ALLOBJ authority. They said that this was the only way their software will work at QSECURITY 30. Isnt giving *ALLOBJ authority worse than being at QSECURITY level 20?
Answer: Its not worse; its the same. The only difference between QSECURITY level 20 and level 30 is simply that every user profile has *ALLOBJ special authority at security level 20 and only a very limited number of profiles have *ALLOBJ special authority at level 30 (well, normally).
Effectively, what your software vendor has done for you (or should I say to you?) is cause your system security to run at level 20 even though the value in the QSECURITY system value is 30.
But dont count on fooling your auditors with this cheap ruse. Another item that IS auditors love to write up is too many users with elevated authority. If your auditors are worth even half their cost, theyll spot this major security hole and write it up in big bold letters. And theyll have a point: A user with *ALLOBJ special authority has unfettered access to anything on your system. That means the user can read, change, or delete any object that he can see (and he can see *ALL objects). I recommend that you not fight the auditors on this point and seriously address their concern.
That means youre going to have to call the software vendors bluff. AS/400 security is too good to require that every user of an application have security officer rights. The problem here is not with the software but with the vendors lack of understanding of its own software or AS/400 security, or both. Apply some pressure on the vendor to provide you with a security plan that will work for users who do not have *ALLOBJ special authority. Many times, the vendor already has this plan; it would just prefer not to disseminate that plan because its easier to troubleshoot problems if it can immediately dismiss the entire issue of inadequate authority. If the vendor doesnt have a plan in place, then you can be the catalyst that pushes it into security compliance. Ive gone this route with a number of AS/400 vendors, and, while they werent overjoyed at first, they found that the end result was worth sharing with their other customers. So press your vendor for a viable security plan and make sure it understand that its lack of a security model is causing you to fail audits.
I must state unequivocally that, regardless of vendor assertions to the contrary, I have never seen a package that could not run with standard AS/400 security implementation. If the vendor still cannot or will not provide a security plan, you can build one for yourself by applying some basic security concepts. The first concept is that precious few users should have *ALLOBJ authority. The best way to eliminate *ALLOBJ authority is slowly. I usually start with a single user and experiment with the application. You can pick one test user profile and remove *ALLOBJ special authority from its profile, or you can create a new user profile that resembles existing profiles in every way except that it does not have *ALLOBJ special authority. Use that user profile over the course of a business cycle to determine if there are any security issues, and address those issues as they arise. This technique involves a bit more work (and a bit more pain) than a vendor- driven plan does, but it is a lot less painful than restoring deleted or corrupted files that a too-powerful user trashed.
Server Server Format Description
*SQL QIBM_QZDA_INIT SQL Initialization *SQLSRV QIBM_QZDA_SQL1, QIBM_QZDA_SQL2 SQL Server 512 Bytes, 32 KB *NDB QIBM_QZDA_NDB1 Native Database Server *DDM Network Attributes DDMACC Distributed Data Management (DDM) Server
*DRDA Network Attributes DDMACC Distributed Relational Database
Architecture (DRDA) Server *RQSRV QIBM_QRQ_SQL Original PC Support SQL Server *TFRFCL QIBM_QTF_TRANSFER Original PC Support File Transfer Server *FILESRV QIBM_QPWFS_FILE_SERV File Server, NetServer
*FTPSERVER QIBM_QTMF_SERVER_REQ FTP Server
*TFTP QIBM_QTOD_SERVER_REQ Trivial FTP Server
Figure 1: Several exit points enable bulk data transfer from the AS/400 to a remote client.