Investing time in data security is part of a sound business practice. But security is often ignored and avoided. Why is that? This article poses some theories as well as some helpful tips if you are one of the ones avoiding the issue.

Security--A Topic to Be Avoided

Why is it that when I explain to people what I do, they always say, "Wow! Your company must be very busy!" After I affirm their assertion, they turn away and ask no further questions. What is it about computer security that makes people shy away?

My first belief is that people may be intimidated by the topic. Why? Perhaps it's because people in the industry have made the topic seem too difficult. If I've done that, I apologize. So I've been trying to determine how I can make the topic more easily understood. Let's try this explanation.

Security is about determining what assets you want to protect or "secure." Examples might include buildings, people, expensive jewelry, or sensitive information. Once you determine what assets you are responsible for securing, you then need to determine what types of users need access to the assets and what type of access they need. Once you determine this, you have to determine how you're going to facilitate the access. For example, if you provide security for a commercial building, you may allow entrance to people who do not work there, but you'd give them access only to certain floors and require that they wear a visitor's badge.

You can view i5/OS security the same way. Stored on your system is something--typically, data--that needs to be protected. You need to determine all of the places the data resides, and the data owner needs to determine what types of users can have what types of access. Once this is done, you, as an administrator, can design a security scheme that protects the data yet allows appropriate access.

Too often, we in the security field get caught up in talking about all of the details and implementation steps. That can be overwhelming, I know. Hopefully, taking a slightly broader view of security will give those of you who are unfamiliar with security a better understanding of the purpose and necessity of security.

Security Is Not Popular

I'm certain that another reason security is avoided is because administrators can become “unpopular” when they make security-related changes. Implementing security rules often means that people can no longer perform tasks they've become accustomed to performing. For example, maybe a programmer has gotten into the habit of using a file edit utility to modify data (rather than fixing the program that causes the error to occur in the first place), and you've removed access to that utility. Or perhaps you've removed users' *ALLOBJ special authority, which they never should have been given to begin with.

Unfortunately, most people take it personally when capabilities are removed; they don't realize that many security changes are the result of the need to comply with government or industry regulations or with business practices being set by upper management. Unless you have strong management backing, enforcing a stronger security scheme is often an uphill battle because those affected can make things so miserable and complain so much that you give up. Even with management backing, it is rarely a fun endeavor. If you are an administrator making security changes, you're doing the right thing, even if everyone around you is angry and complaining about the more restrictive environment in which they must now operate. You are being a responsible employee who is committed to protecting company assets. And that's a good thing.

You Don't Want to Know

I believe that many administrators who claim they don't have security issues on their system or don't need to do any regular analysis of the security configuration of their system are making these claims because they don't want to know the truth. I believe they suspect that there are issues but think that if they avoid the issues they will either go away or not cause them trouble. It's a bit like having a health problem and suspecting that there's something wrong but refusing to go to the doctor. As long as no examination is made or tests are run, a less-than-desirable diagnosis cannot be made. It is my belief that the longer security issues are avoided, the worse they become. They don't magically go away on their own, just like clogged arteries don't clear on their own and tumors don't remove themselves.

The Job's Too Big

Administrators also avoid implementing security because they're overwhelmed by the thought of fixing all of the security issues on their system, or they simply don't know where to start, or they know there are issues but don't really know what they are or how to address them.

I believe that many administrators know there are issues to be addressed, but they think all the issues have to be fixed at once rather than one at a time. Since they don't have the time or resources to fix everything, they fix nothing. But security is not an all-or-nothing proposition. In fact, it is usually better to approach a security project in phases. You plan the changes, get approval to make them, implement them, and monitor the system to ensure everything keeps working as designed. Once you are sure your changes have had the desired effect and are working properly, you start on the next phase of your project. Changes can take weeks or even months. We typically work with our clients for a week at a time over several months, implementing the various phases we have planned out. We need to make sure we meet business requirements for a tighter security scheme but, at the same time, make sure the business continues to function properly. This way, if something stops working, you have a much better idea whether or not it was the security change that caused the problem. Making numerous changes all at once makes it very difficult to debug problems and determine the cause.

If you don't know where to start, one obvious option is to bring in a security professional to analyze the system and provide guidance for a security remediation project. If you would prefer to tackle the issue yourself, you need to educate yourself about general security principles. Education on OS/400 and i5/OS security concepts will help you design and implement a good overall security scheme. There are numerous ways to get educated. Conferences such as COMMON and the IBM Technical Conference offer various sessions on security topics. This column, "Security Patrol," has a long history of providing security information. SearchSecurity.com provides an "Ask the Expert" forum where you can submit a question that the site security expert may select to answer. The iSeries Information Center provides information on general security principles, OS/400 and i5/OS security implementation, and specialized topics such as service tools IDs and single sign-on. Finally, the book I co-authored with IBM's Patrick Botz , Experts' Guide to OS/400 and i5/OS Security, provides up-to-date examples on implementing security principles as well as details on planning for and implementing single sign-on.

Where to Start

Once you've educated yourself, you may still not know where to start. Here are some hints:

• Get rid of default passwords. Run the Analyze Default Password (ANZDFTPWD) command and change the passwords for users who have default passwords. To avoid default passwords in the future, you may need to modify your processes for creating user profiles so they are not created with a default password.
• Get rid of user profiles for users who are no longer with the company. This is a tremendous exposure and an incident waiting to happen. Users who have not signed on recently (e.g., in the last 60 days) should have their profiles removed from the system.
• Stop propagating problems. One of the issues that I see overwhelming administrators is the need to re-work the special authorities given to users. A new profile is most often copied from an existing profile, and the special authorities are copied as well. When creating a profile, don't just assume that the existing profile's special authorities are required. From now on, create users' profiles with only the special authorities required to perform their job functions. At some point, you need to review your entire user base and set all authorities appropriately. But with this approach, the problem won't get any worse.
• Remove *ALLOBJ special authority from the users who don't require it to do their jobs. This hint is probably the most controversial because the users who have *ALLOBJ will most likely contend that they need it (especially programmers). But rarely do users outside of the role of security administrator need *ALLOBJ.
• Get your systems running at security level 40. Security can be circumvented at the lower security levels. Security level 40 is the level the system ships at, but unfortunately, I see many systems running at level 20 or 30. These systems are exposed; neither security nor system integrity can be assured at security levels below 40.

Has this article hit close to home? Are you avoiding the issue of security? I hope this article has shed some light on why you might be avoiding the issue and has provided some help so that you have the courage to meet the topic head on.

Carol Woodbury is co-founder of SkyView Partners, a firm specializing in security consulting, remediation services, and security assessments, including the risk assessment product SkyView Risk Assessor for OS/400 and i5/OS. Carol has over 13 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..