A conference speaker at a recent security forum that I attended posed a most interesting question. He asked the simple question "What is your security policy?" I wondered what he might be getting at since the audience was made up of information technology security experts. He went on to propose the idea that most security departments are more involved in security implementation than they are in enforcing security policy. The tail, in effect, wagging the dog.
A security policy is a set of statements that describes how you view information security for your installation. In each application area, the policy should describe how information created and stored in the application is going to be treated from a security perspective. It might include statements such as "Only Payroll department employees can update payroll data," or "Accounts payable vouchers can only be entered and maintained by employees in the Accounting department." As you consider your various policies, your Security Policy will roll out over time to include all aspects of information security.
The conference speaker I heard indicated that most IT security is determined and implemented by the IT staff with little input from the user departments. This kind of security implementation, like any IT initiated application implementation, is destined to fail without user department participation. Only the true owners of the data being secured can accurately create a security policy for their information.
If you don't have a security policy in place, this might be a good time to think about creating one. For your policy, you should consider all applications on your system including the operating system and system utilities. For each application area, you should identify the owner of record and then meet with them to determine the security rules that should be in place. The end user/owner of the application will probably know a lot more than you think about what applies to their information and how it needs to be secured. Often, additional legal and operational situations will be known at the end-user level that your centralized IT security group is completely unaware about.
Your security policy will end up being a series of descriptive statements about the information associated with each application area. Once you have this in place, you can then review your security implementation, which is probably already in place to some extent, and see where your practice falls short of your policy. You may identify areas on your system where your implementation falls far short of the policy objectives. When that happens, you'll need to involve your application user/owner to see what needs to be done to meet the policy. Additional security tools may be required or tighter implementation of existing tools may do the trick.
You may even find areas where your implementation is stronger than what the policy states as a requirement. For these situations, the additional security may not be necessary and could be resulting in administrative burdens that can be relieved by backing off on your implementation.
As you can see, without a stated security policy, you cannot effectively implement information security for your installation. The only people who really know the requirements are probably not in the information security department. So, get out there and get your policy down on paper -- properly defined. Then see if your implementation measures up to your requirements.
If you have specific questions about this topic, e-mail me at rich@kisco.com. All e-mail messages will be answered.
---------------------------
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.
