[IMAGE]
[IMAGE][IMAGE]
Rich Loeber
[IMAGE]
[IMAGE]
If you are are a System i security officer, your primary responsibility is securing the databases running on your system. Good IT security starts with a clearly defined policy, and if you're wondering where to start, you are in the right place.
Before you start creating a security policy for your AS/400 system, you need to get your user community involved. A security policy created and implemented without end-user participation is destined to be a problem. However, if your end users are asked to participate and buy into the policy, smoother implementation will result. 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 consideration when formulating your security policy is what your overarching objectives are. You have two choices at this point.
Strict IT security policy: 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.
Relaxed IT security policy: 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 System i shops adopt the relaxed approach, but your auditors will love you if you go for the strict option.
Once you've made this decision on your general approach, make a list of the applications on your system. You will need to define the owner -- the person who makes final security decisions -- for each application .
Within each application, you should list the data assets created and used by the application with a note for each one regarding its security sta...
To continue reading for free, register below or login
To read more you must become a member of Search400.com
tus. Some applications will need little or no security, whereas 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 classification. But you may have other data assets that also are included. Those would be any data assets that record credit card information or any other personal identity information for your employees or your customers.
An example of the second type of data would be a Master Customer database or a Contact database. These are compiled databases that clearly help you 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 needed to maintain your day-to-day business operation.
With each of these assets defined, you can describe the type of security that you want in place. When you're done with each application, have a final review and sign-off by the user (or owner) of each application. Only after this legwork has been done can you consider how to best implement the security requirements. I'll elaborate on that in next month's tip.
If you have questions about anything in this tip, you can reach me at rich@kisco.com. All email messages will be answered as quickly as possible.
ABOUT THE AUTHOR: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.
