Editor's Note: Carol is leaving her role of security officer, and this is the last "Security Patrol" column she'll be writing for MC Mag Online. This article summarizes her wishes for how you'll address your company's security.

Stop Procrastinating

The security configuration of your iSeries system must be addressed. I can't state it in stronger terms. Contrary to what some people believe, OS/400 and i5/OS do not ship in a secure state. You must take action to ensure that the system and its data are secure. The good news is that OS/400 and i5/OS are among the most "secure-able"--if not the most secure-able--systems available.

But some of you continue to ignore the issue. I think I've heard all the excuses. Here are a couple of my favorites:

• "Nothing has happened to my system yet." My answer to that is, "How do you know?" These are always shops that haven't turned on auditing and haven't created regular reports to monitor the user accounts on their system. Nor do they monitor access to critical files. They may think nothing has happened to their system or their data, but they have no way to prove it!
• "We can't afford the performance overhead." My answer to that excuse is this: An easy-to-understand and easy-to-maintain security scheme will not cause performance overhead. Throughout the releases of OS/400 and i5/OS, IBM has made many performance enhancements that have eliminated the performance overhead associated with private authorities and authorization lists that plagued the early releases of OS/400. Simply put, you have to try really hard to make a security scheme be the cause of a performance issue.

Given the regulatory issues facing most companies today, you really don't have a choice but to start down that "dreaded" security road.

Don't Get Overwhelmed

I understand that the task of securing your enterprise can be overwhelming, especially when you face the list of tasks you feel need to be accomplished. But you don't have to fix everything at once. I recommend that you determine what all of your issues are, understand the risk associated with each issue, rank the issues in priority order according to risk, and lay out a plan to fix them. Start with the "low-hanging fruit"--the issues that are easy to remediate but, when fixed, significantly reduce your risk (e.g., default passwords and user accounts that are inactive). For the issues you cannot get to right away, develop project plans and prioritize them with the rest of your tasks. For the issues that you determine will never be remediated, write up a business risk acceptance statement. Written risk acceptance statements are important, especially when you're being audited. Before you can write this statement, you have to have examined the risk associated with the issue, compared it to your business requirements, and made a conscious choice to leave the issue alone. This shows the auditor that you understand your business and made conscious choices regarding your business needs.

Stop Propagating the Problem

Sometimes, the thought of fixing an issue can be so daunting that you just don't know where to start. In this case, I recommend that, for the time being, you stop focusing on the issue as it exists on the system and make a conscious choice to stop propagating the problem or making the problem any worse than it is.

For example, you may have many users on the system who have been placed in group profiles even though they don't need the access provided to the group or did at one time and no longer need the access. This is often the case when a user changes departments or job function.

I've found that most iSeries administrators copy an existing profile when creating a new profile. My suggestion is to stop copying an existing profile without first examining the group or groups into which the user is to be placed. Look at the access the group has by running the Display User Profile (DSPUSRPRF) command, naming the group profile, and specifying to see the objects the group owns (*OBJOWN). Then, run the command again, specifying to see the objects to which the group has been given a private authority (*OBJAUT). Assign users to a group only if they need the same access to the same objects that the group provides. As some point, a review all of the members of each group profile should be conducted and a determination made as to whether they should still be a member of the group. But in the meantime, you can take steps to not make the problem of unnecessarily assigning users to groups any worse than it already is.

Object Authority Has the Final Say

By now, I hope you all understand that relying on menu "security" is the equivalent of locking the front door of your house with the best lock available but leaving your back door wide open. Objects (programs, data areas, commands and, most important, database files) can be accessed via DDM, FTP, command lines, sockets applications, Web applications, remote procedure calls, and so forth. If users have sufficient authority to access files through one of these interfaces, OS/400 will let them. However, if a user who has only *USE authority to the file tries to update the file using ODBC, OS/400 prevents the action. Other techniques are advertised, but the only sure way to ensure that a file is not accessed outside of an application is to use object-level security. Object authority is always in effect, and OS/400 cannot bypass an object authority check.

Some of you get overwhelmed by the concept of object authority because you think you have to literally secure every object on the system. That's simply not the case. Here's why: Before you can access an object, you have to have authority to its library or directory. When you secure the library or directory, the objects in it are also inherently secured. For example, typically only the HR department needs access to HR applications. Give the HR_GROUP profile *USE authority to the application libraries and set *PUBLIC authority to *EXCLUDE. Now, you've significantly reduced the chance that the HR database is going to be exploited because only the users assigned to the HR_GROUP can access objects in the HR libraries. Other users will be prevented from accessing the HR database because *PUBLIC authority has been set to *EXCLUDE.

Libraries and database files do not come secure by default. You must consciously determine which libraries to restrict and which ones to allow open access to.

Don't Ignore the Integrated File System (IFS)

Most companies today are ignoring IFS security. The root ('/'') directory ships with *PUBLIC authority set to the equivalent of *ALL--that is, DTAAUT(*RWX) and OBJAUT(*ALL). Given that most directories inherit the *PUBLIC authority of their parent directory, the directories that have been created on your system are also the equivalent of *PUBLIC *ALL unless you have set them otherwise. A wide-open IFS in an invitation to store all sorts of inappropriate items in this directory structure. Imagine it, and it's probably been stored there--PC backups, pornography, music, and movies. Yes, the IFS is a wonderful storage area if not locked down. I strongly encourage you to set the root directory to DTAAUT(*RX) and OBJAUT(*NONE) and limit the use of file shares that make the directory available throughout your internal network.

Viruses are another issue associated with the IFS. Just as I've mentioned locking down the IFS, I've also mentioned the need to virus scan the IFS. Don't forget this important step!

By the way, did you know that you can and should virus scan OS/400? The little-known Check Object Integrity (CHKOBJITG) command is essentially a virus scanner for OS/400. It checks the digital signatures of objects and looks for signs that OS/400 has been tampered with since being shipped from IBM.

A Wealth of Information

Knowledge is power, as the saying goes, but, in my opinion, you don't have to know everything; you just need to know where to obtain the knowledge. You can find most of the answers to your security questions at the IBM Information Center in the iSeries Security Reference manual. (To find the Security Reference manual on the Information Center site, expand the "Security" topic in the left nav pane. The manual is available there via a downloadable PDF.)

• Chapter 2 describes moving to higher security levels from levels 20 or 30.
• Chapter 6 describes how to secure spooled files.
• Chapter 9 describes auditing functions.
• Appendix B describes the IBM-supplied profiles and their shipped settings.
• Appendix D (my favorite section of this manual!) describes the authorities required to run a particular CL command. For example, to run the Submit Job (SBMJOB) command, the table shows all of the objects (job description, user profile, etc.) that can be specified and the authority the user needs to each object for the command to run successfully.
• Appendix F provides the layout of each of the audit journal model outfiles that are shipped in QSYS.

If you're looking for practical applications of OS/400 functionality rather than "just the facts" as offered in most IBM publications, see my latest book, Experts' Guide to OS/400 and i5/OS Security, co-authored with Patrick Botz from IBM. (Pat will be taking over this column, so look for him in this space next month!) If you have specific questions for which you cannot find the answer, you can submit your security questions for possible answer by me at Search400.com.

It's Never Over

Now for the really bad news: Security is not a one-time event. You can't remediate all of the issues on your system and be done. No, unfortunately, you need to periodically, if not continually, re-evaluate your security configuration settings. Why? Because things change. A new release of OS/400 may provide new tools that help make security configuration easier, or new functionality may be added that will make you re-think your security configuration choices. Or you may install a new third-party application and need to make sure it didn't open up an area of the system you had locked down. Or your company may decide to use your iSeries as a Web server. Or you may open an e-commerce site that accepts credit cards. The list goes on.

My Hopes

My hope is that you understand the need for a strong and robust security implementation. My hope is that I've described things in understandable terms so that you can now easily apply them to your situation and your system. My hope is that you will make intelligent business choices as to what needs to be remediated and what risks your business can afford to take. My hope is that these "Security Patrol" articles have made the task of securing OS/400 a little easier.

Finally, my hope is that, on occasion, I've helped you remember what's really important in life. To quote from the opening line of Rick Warren's best-selling book, The Purpose-Driven Life, "It's not about you." Nor is it about making sure the upgrade to i5/OS goes smoothly, nor is it about making sure your new application gets into production on time, nor is it about getting promoted. Each year, I am reminded that things other than my work should be taking priority in my life--family, friends, and my faith in Jesus Christ. This Christmas, I encourage you to take time to carefully examine your priority list, checking it twice to make sure that it's truly in the right order.

Carol Woodbury is co-founder of SkyView Partners, a firm specializing in security consulting, remediation services and security assessments, including the product, SkyView Risk Assessor for OS/400 and i5/OS. Carol has over 14 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Look for Carol's second book, Experts' Guide to OS/400 and i5/OS Security.

Carol can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..