IBM i Security Basics - Policy

By Rich Loeber,

If you are a security officer for your IBM i, then securing databases on your IBM System i is your primary responsibility. Good security starts with a clearly defined policy. This tip will help focus on how you can create this policy.

Before you start creating a security policy, you will have to get your user community involved. A security policy created and implemented without end user participation is destined to always be a problem. If your end users, however, are asked to participate and buy into the policy, then the results will be a much smoother implementation. If you find resistance to participation in policy creation, get management on your side. Whatever you do, don't create the policy on your own as an IT project.

The first decision you need to make when formulating your security policy is what your overarching objectives are going to be. You have two choices at this point:

• You can decide that your policy will be very strict
• You can decide that your policy will be relaxed

With a strict policy, access to every object in your system will be determined and enforced at the operating system level. Each user's specific requirements will be analyzed and then encoded in the security implementation provided by the IBM i OS. With a more relaxed approach, you can decide that users will have broader access to objects on your system with strict access rules only for certain pre-defined data assets. In actual practice, most IBM i shops adopt the second approach, but your auditors will love you if you go for the first one.

Once you've made this decision to your general approach, then proceed to make a list of the applications on your system. For each application, you will need to define the owner of the application. This will be the person who will have to make final security decisions.

Within each application, you should then list the data assets created and used by the application with a note on each one as to it security status. Some applications will need little or no security while others will have very strict requirements. Make sure that your users are in full agreement about the nature of each data asset and its security requirements.

When deciding on the security requirements for each asset, there are three things to consider:

• Is this information that should be restricted from all employees?
• Is this information that is critical to the way you do business? Does it give your organization a competitive advantage in the marketplace?
• Is this information crucial to your day to day operations?

Obviously, payroll falls into the first category and is the classic data type for this consideration. But, you may have other data assets that also come into play. Included in this would be any data assets that record credit card information, banking information or any other personal identity information for your employees or your customers.

An example of the second data type would be a Customer Master database or a Contact database. These are compiled databases that clearly help you to do business and that you do not want falling into the hands of competitors.

Finally, an example of the last type of data asset might be your month to date sales database or your current accounts receivable. These are management tools that are needed to maintain your day to day business operation.

With each of these assets defined, you can then describe the type of security that you want in place. When you are all done with each application, have a final review and signoff by the user (or owner) for each application. Only after this legwork has been done can you consider how to best implement the security requirements. More on that step soon.

If you have any questions about anything included in this tip, you can reach me at rich at kisco.com, All email messages will be answered as quickly as possible.