This article provides an overview of the benefits, issues and steps involved in developing an organizational security policy.

Decentralization of Security
Whilst a person or group may be responsible for overall organizational and system security, it is critical that individuals manage, and be responsible for, the security of the specific resources or systems they use. The person who is ultimately in charge of a resource - the "owner" of a resource - should be responsible for keeping that resource safe and secure. For example, a sales representative who uses a company car should be responsible for doing everything in his or her power to prevent that car from being stolen or damaged. A marketing manager should be responsible for securing his or her information assets - marketing plans, budgets and other confidential information. Everyone in the organization should be responsible for keeping those resources he or she uses or manages secure within his or her powers to do so.

The resource owner may or may not be authorized to grant access to, and approve usage of, his or her resource. Someone must be given this responsibility. If it is not the resource owner, then maybe it is his or her superior, the security officer or the system administrator. In each case, access and usage rights should be clearly delineated with corresponding rights and responsibilities. "Proper" use of a particular resource needs to be distinguished from "improper" use.

It follows that there should be a set of procedures for dealing with policy violations and security breaches, such as improper use. These also need to be administered by someone - the security officer, system administrator, personnel manager or senior manager. Depending on the situation, a situation may require the involvement of one or several external parties - security consulting firm, law enforcement agency, public relations agency, media, neighbors, suppliers, customers. A clear set of procedures for dealing with external parties should be included in the security policy.

The policy will need to be interpreted and modified from time to time, so an individual or group of people should be appointed to review, interpret and revise it as needed. Finally, the policy needs to be disseminated to everyone who is subject to it - employees and relevant third parties. This may necessitate training for employees. Also, to underscore the importance of the policy and the rights and responsibilities of employees which it outlines, each employee should sign a legal document stating that he or she has read, understood and agrees to abide by the policy.

Outline of the Security Policy
Following is a suggested template for a security policy:
1. The assets/resources of the organization to be protected.
2. The security controls applying to assets/resources (including the baseline/minimum controls for the least valuable assets) - practices, procedures, methods, tools.
3. The person or persons who is responsible for the security of assets/resources.
4. An emergency response plan or contingency plan.
Contact details of relevant employees, security consultants, law enforcement agencies, and other third parties.

Implementing the Security Policy

Communication and Education
Everyone in the organization needs to "buy" into the security policy for it to be effective. Often, achieving this is easier if people - from the grassroots upward - have the opportunity to contribute ideas and participate in the development of the policy. In any case, you will need to educate users on their rights and responsibilities and also reinforce the importance of adhering to the policy on an ongoing basis. The policy needs to "worked" in order for it to work.

Educate Users

Users of organization resources need be educated about the proper and improper use of those resources. Specific procedures such as password selection, building entrance/exit procedures and others, need to be carefully explained to all relevant employees.

They should understand their own rights and responsibilities in maintaining the security of the resources they use or manage, and what they should do in case they suspect a security breach. Any particular security vulnerabilities that attach to their resources or their jobs should be explained.

It is very important to warn users of attempts to mislead or defraud them by imposters via "social engineering". In so many cases of security breaches, people have been the weakest link in allowing an intruder to attack an organization. (See the November issue of the Shake Security Journal) Hence, employees should be thoroughly educated about how to should deal with such circumstances as the following:
· Outsiders phoning them with "urgent requests" to be put through to someone or something.
· Unknown suppliers demanding payment for a mysterious invoice.
· So-called employees from some other office in the organization wanting access to the computer system.
· "Employees" walking into the office off the street.
· "Students" wanting information about the organization for an "assignment".
· "Researchers" wanting information for a "survey".
In addition, staff should be aware of the ramifications of failing to assume their own responsibilities or of committing a security breach themselves.

System Administrators (or Network Managers)
In many cases the system administrator will be charged with maintaining security on the network. It is therefore crucial that he or she understands and follows the procedures documented in the Security policy. In most cases the system administrator will be involved in designing the policy anyway. However, if there is a change of personnel it will be necessary to educate the newcomer so that he or she becomes well versed in managing the information system security controls.

Conclusion
This article has explained some of the benefits, issues and steps involved in designing a security policy. Developing a comprehensive security policy is actually very time consuming and complex, depending on the size and diversity (in terms of geography, assets, systems and personnel) of the organization.

The time taken to develop such a policy may range from one week to six months. Indeed, the time and difficulty of developing a policy will be exacerbated if there is no one whose full-time job is to develop the security policy. Unfortunately, time is a "killer". Each day that the development of the policy is prolonged is a day that the organization is without its "bible" for managing security and responding to emergencies. In fact, it may be more cost-effective for the organization to engage full-time consultants to develop the policy - as long as people at all levels of the organization are involved and are willing to "buy" into it.

References:
Frede, S. (1994) "Internet Security", On the Net
Holbrook, P. and Reynolds J. (1991), Site Security Handbook
Lichenstein, S. (1994) Security in Information Systems, Monash University Department of Information Systems