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/400—an ability that you don’t 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.
Expiring Passwords
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 user’s 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 doesn’t 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. Isn’t giving *ALLOBJ authority worse than being at QSECURITY level 20?
Answer: It’s not worse; it’s 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 don’t 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, they’ll spot this major security hole and write it up in big bold letters. And they’ll 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 you’re going to have to call the software vendor’s 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 vendor’s 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 it’s easier to troubleshoot problems if it can immediately dismiss the entire issue of inadequate authority. If the vendor doesn’t have a plan in place, then you can be the catalyst that pushes it into security compliance. I’ve gone this route with a number of AS/400 vendors, and, while they weren’t 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.
John Earl is chief technology officer for the PowerTech Group in Tukwila, Washington, and a security editor for Midrange Computing. He can be reached at
.
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.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
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.
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:
LATEST COMMENTS
MC Press Online