Site Security Policy Development

by Rob McMillan

Information Technology Services    Security Emergency Response Team
Griffith University                c/- Prentice Centre
Nathan  Qld  4111                  The University of Queensland  4072
AUSTRALIA                          AUSTRALIA

Email: R.McMillan@its.gu.edu.au    Email:sert@sert.edu.au
Phone: +61 7 875 6557              Phone: +61 7 365 4417
Fax: +61 7 875 7877                Fax: +61 7 365 4477

Abstract

Computer systems are powerful tools that touch upon many aspects of life in modern society. They can be used to enhance quality of life or degrade it. The impact of this effect may range from negligible to the dramatic.

In order to ensure that computer systems are used in an effective and productive way, it is important that the owners, operators and users of these systems have a clear understanding of acceptable standards of use. Such an understanding can be gained as part of a Site Computer Security Policy.

The security requirements of computer systems owned and operated by one organisation will almost certainly differ from the requirements of another organisation. It is therefore important that each organisation formulates its own Site Computer Security Policy.

This paper outlines some issues that the writer of a Site Computer Security Policy may need to consider when formulating such a document.

Disclaimer

The information contained in this paper is given freely as an account of the author's own experience, and may be used by the reader as the reader sees fit.

No responsibility or liability will be accepted by the author or the author's employer for any damages caused by direct or indirect use of the information or functionality described in this paper.

1.0 What Is A Site Computer Security Policy?

In the same way that any society needs laws and guidelines to ensure safety, organisation and parity, so any organisation requires a Site Computer Security Policy (CSP) to ensure the safe, organised and fair use of computational resources.

The use of computer systems pervades many aspects of modern life. They include academic, engineering, financial and medical applications. When one considers these roles, such a policy assumes a large degree of importance.

A CSP is a document that sets out rules and principles which affect the way an organisation approaches problems.

Furthermore, a CSP is a document that leads to the specification of the agreed conditions of use of an organisation's resources for users and other clients. It also sets out the rights that they can expect with that use.

Ultimately a CSP is a document that exists to prevent the loss of an asset or its value. A security breach can easily lead to such a loss, regardless of whether the security breach occurred as a result of an Act of God, hardware or software error, or malicious action internal or external to the organisation.

2.0 Why Does An Organisation Need A Site Computer Security Policy?

In addition to the benefits outlined above, a CSP offers an organisation the following benefits:

3.0 What Are The Characteristics Of A Site Computer Security Policy?

An effectively written CSP should have the following characteristics:

4.0 What Does A Site Computer Security Policy Contain?

A CSP can be viewed as a document of three distinct parts, all of which are necessary, but within themselves not sufficient.

The first part outlines the parameters within which the policy will operate, and may consist of many sections.

The second part of the policy is essentially a risk analysis, which discusses assets that need to be protected, the threats that may cause damage to the assets, and the mechanisms that may be used to realise these threats. The material in this part forms the logic behind the rules and guidelines that form the actual security policies that are formally defined in the third part.

The following material outlines issues that the author of a CSP may like to address in the document. This is not necessarily exhaustive, and the content of the CSP ultimately rests with its author.

4.1 Abstract

The abstract should set out what the document is and the organisation for whom it has been written.

4.2 Context

This section should outline the context within which the resources under the control of the policy operate. For instance, a private company may not be connected to any network outside of its own domain, or on the other hand, it may be connected to banks throughout the world. A CSP for a university may describe the significance of Internet and AARNet, and the relationship of these entities with the campus network.

This context is important as it effectively determines what the governing policies are of the CSP, and influences the philosophy and procedural guidelines set out in the CSP.

4.3 Philosophy and Functions

The writer of a CSP will inevitably be faced with several alternatives when deciding on a particular policy for a particular issue. The classic instance of such a dilemma occurs when one determines that a compromise of a computer system is actively in progress, and that the compromise possibly includes a breach of Commonwealth Law. Does the system manager take steps to reduce the impact of the compromise (by, for example, disconnecting the compromised network from the source of the compromise), or does the system manager allow the compromise to continue in an attempt to identify the attacker at the risk of damaging or losing resources permanently?

The basic philosophy that should be used when constructing policies that may be used for making non-deterministic decisions should be outlined in this section.

The writer should also outline the functions that the CSP is expected to serve within the organisation. Similarly to the philosophy behind the CSP, the functions that the CSP will serve will affect the content of the CSP.

4.4 Definitions

As mentioned earlier in this paper, the key to writing an effective CSP is accurate and precise definitions of terms. Any term that may have any ambiguity attached to it must be defined in a precise manner. Any loopholes left in this section or in the sections regarding the rights and responsibilities of users and resource providers may be exploited by people in order to circumvent the CSP.

For instance, consider a policy which states, in part, that "all accounts must be protected by a password". This obviously precludes the use of guest accounts with no passwords. However, what effect does this have on anonymous ftp? Is it conceivable that one could make a case that the anonymous account is not password protected since any password could be used to access the account?

What constitutes an account? The login identifier only, or the resources associated with the account? Does the account holder own the account and those resources, or does the resource provider? Should the term "account" be omitted, and replaced by the concepts "user account", "privileged account" and "public access account"?

When a policy refers to a Chief Executive Officer (CEO) of an organisation, should the term "Chief Executive Officer" be redefined to include the CEO and agents of the CEO, where an agent is any person authorised by the CEO to be such? If not, then the policy may award the CEO many rights and tasks, leaving nobody else with any rights or tasks at all, let alone the authority to act in the absence of the CEO!

Two of the most critical concepts that must be clarified are the concepts of authorisation and permission. At a technical level, is permission simply granted by access permission bits on a file, or is permission a combination of technical feasibility and authority to carry out an activity? Is authority implicit with technical feasibility, is it a property that must be explicitly granted, or is it a property associated with position?

These are but a sample of the terms that need to be defined for a CSP. This (crucial) section should be carefully and painstakingly constructed, and whenever there is any doubt as to whether a term should be defined, or what the definition should be, then one should err on the side of caution.

4.5 Governing Policies

It is important to make mention of the policies which govern the CSP.

The CSP may only make mention of policies that directly affect it, rather than get bogged down in all policies that may indirectly affect the document in varying degrees for pragmatic reasons. Examples of such direct policies include Commonwealth Law, State Law, (perhaps) the AARNet Acceptable Usage Policy and the "Terms and Conditions of AARNet Network Affiliate Membership" document (if appropriate). Other policies internal to the organisation may also be referred to in this section.

It is recognised that the content of this section is affected by external influences. However, it is these same external influences that affect the content of the CSP as a whole, and the interpretation of it. By including references to the governing policies, content of the CSP is simplified, and guidelines for action in the event of a security breach are automatically provided should such a breach influence an organisation's environment.

However, because of the external nature of these governing policies, interpretation of them in this section should be kept to a minimum (again for pragmatic reasons).

4.6 Authority

In order to be effective, the CSP must be the product of a directive from an influential and authoritative person within the organisation.

It is important to define the driving force behind the development and implementation of the policy. Furthermore, this section must outline the person who has ultimate authority in the interpretation and application of it to a particular situation, particularly in lieu of any issue that may be addressed in subsequent sections.

Another consideration when writing this section is that of allowing for flexibility. That is, decision makers may need a clause in the policy that allows for a policy statement to be temporarily waived from time to time by a person of authority under certain conditions or guidelines. Such a clause allows those in authority to act with initiative (and still within policy boundaries) should unusual situations arise.

4.7 Distribution

The organisation should formally define the standards it will adhere to ensure that the people affected by the policy are appropriately informed of its contents (as is its moral responsibility).

4.8 Review

A CSP that is prepared in a final form and never reviewed for the appropriateness of its contents during its lifetime may quickly become a document that is either cumbersome or useless. This section should formally set out the periodicy and necessity for reviews of the CSP.

4.9 Risk Analysis

The previous sections set out the parameters within which the policy will be effective. This section outlines the assets that must be protected, and from what threats. This is necessary to provide the underlying logic for the following sections which formally define the rules that apply to the use of those assets.

The preparation of this section can be laborious and can require a great deal of insight. The depth of this analysis is up to the organisation and the uses to which the CSP will be put. For instance, if the CSP is expected to be heavily used in making purchasing decisions, particularly with regard to asset defence, then a full financial and likelihood analysis of the impact of any and all realised threats may be required. However, if this is not one of the main purposes of the CSP, then this section may only need to outline the assets, threats and vulnerabilities which ultimately justify the logic behind the following sections.

It is essential that in its most minimal form, this section has at least three subsections.

In the first subsection, a list of various asset categories must be provided, since the loss of an asset represents a significant loss to the organisation. In some cases, a lost asset cannot be replaced, particularly in the case of goodwill, trust, or confidential research. Examples of asset categories include:

- documentation;
- goodwill and reputation;
- hardware;
- people and skills; and
- software.

A discussion of these assets should include some indication of the size and type of investment that the asset represents, the impact on the organisation of the loss of the asset and how easily replaceable (if at all) the asset is. When considering assets in the information category, it is important to emphasise that a loss may be suffered simply by unauthorised access to that information, even if that information is still available to the organisation.

The loss of an asset is caused by the realisation of a threat. The threat is realised via the medium of a vulnerability. Threats cannot be controlled within an organisation as a threat is essentially a product of the organisation's environment. This is not so for vulnerabilities, which usually exist within the organisation. Hence the purpose of the security policy and its associated procedures is to minimise the number and size of any vulnerabilities and thus negate any potential threat and its impact on an organisation's assets should a threat be realised.

The second subsection might therefore be devoted to threats. Examples of threats that may be examined are:

- denial of service;
- destruction (of assets);
- disclosure of information;
- theft (of information or physical assets); and
- unauthorised access.

The examination of these threats might include a discussion on both the probable and maximum possible impact of the realisation of the threat upon the organisation, as well as the consequences for the organisation should these scenarios occur. It may also be useful to explore what further threats could be realised as a consequence of the realisation of an initial threat.

The third essential subsection must tie together the assets and threats to give some indication of the likelihood of and likely extent of damage of the threat being realised on the assets. This subsection therefore discusses vulnerabilities.

Vulnerabilities may differ from organisation to organisation. However, a possible categorisation of a vulnerability set may be:

- Host based:
     - Compromise;
     - Destruction;
- Network based:
     - Destruction;
     - Eavesdropping;
     - Flooding;
- Non-discriminatory (e.g. Acts of God); and
- Procedural.

This can be a difficult subsection to write. For each vulnerability identified, the following aspects might be discussed.

4.10 Rights and Responsibilities of Users

This section (and the next two) are the heart and soul of a CSP. It can be difficult to draw distinct lines between the rights and responsibilities of users and the resource provider, since many issues may be considered to be in the domain of either (privacy being one such issue). The key to writing this section and the next is to make a firm decision on which issues belong in which section (e.g. by preparing a detailed table of contents) and thus avoid duplication and complexity.

Issues that could be addressed in this section are listed below.

4.11 Rights and Responsibilities of the Resource Provider

There is a myriad of information that could be placed in this section. The content of this section assumes a large degree of importance (indeed, probably more than the previous section) when one considers recent statistics regarding the proportion of crimes involving computers that are committed by people internal (or recently internal) to the organisation.

Some (but by no means all) issues that could be addressed here include:

- backups;
- contact information;
- dial-up access;
- host configuration guidelines, including:
     - allocation of responsibility;
     - network connection guidelines;
     - authentication guidelines;
     - authority to hold and grant account guidelines;
     - auditing and monitoring guidelines;
     - password    format,   enforcement   and    lifetime
          guidelines; and
     - login banners;
- network  construction, configuration and use guidelines,
     including:
     - allocation of responsibility;
     - supported protocols;
     - network design principles;
     - address allocation and authority guidelines; and
     - use of network management and other equipment;
- physical security guidelines; and
- privacy guidelines.

There are no doubt many other issues and principles that could be discussed in this section. The content of this section is really a product of the basic philosophy of the organisation providing the resource.

4.12 Violation

A stated function of a CSP is to form a framework for deciding what action to take in particular circumstances. In the event of a security breach, a CSP needs to offer to those who must take action, necessary guidelines as to what authority they have in order to minimise the impact of that breach. Furthermore, after the breach, the policy must provide guidelines for courses of action to take in order to prevent further or repeated breaches, and also regarding the identification and discipline of the people responsible (in whatever capacity) for the breach.

It is therefore obvious that this section is also a non-trivial section concerned only with identification and discipline.

There could be a subsection devoted entirely to security incident handling principles. This subsection would be used directly in the construction of a set of procedures to be followed in the event of an actual security breach in progress. It could broach such issues such as:

It may be desirable to also offer guidelines for liability of personnel with regard to security breaches. Such policies may tend to encourage people who are the victims of ignorance but honest intent to offer information that can be used constructively to prevent future incidents, rather than attempt to hide details of a breach that they may have (somewhat innocently) been involved in.

This section also needs to discuss, in some detail, guidelines regarding investigation of incidents and courses of action that could be taken by decision-makers based upon details of the security breach. Such guidelines may include guidelines about referral of various matters to law enforcement agencies, as well as internal investigation and disciplinary principles.

There should be some emphasis placed upon not only minimising the impact of and recovering from a security breach, should one occur, but also in learning any constructive lessons possible from an incident. The way in which this can be done is to carry out a post-mortem of incidents. Requirements for post-mortem procedures and reports could be outlined in this section. Such a post-mortem could include preparation of reports containing details like cause and effect of the incident, side-effects of the incident, costs involved in terms of losses and recovery, and possible repulsion and impact minimisation strategies should a similar incident occur in future.

5.0 Conclusion

The absence of a Site Computer Security Policy leaves a large void in any organisation's ability to operate effectively and maintain business continuity, and allows for ad-hoc decisions to be made by unauthorised personnel. Conversely, a well written and easily understandable Site Computer Security Policy provides an effective basis for decision making and planning. It gives the providers and users of a resource a clear understanding of what is expected, and what may be expected in return. Adherence to such a policy lends some evidence to an organisation's integrity and trustworthiness.


References

Caelli, W., Longley, D. and Shain, M., Information Security Handbook, Macmillan Publishers Ltd, 1991. ISBN 0-333-51172-7.

Site Security Policy Handbook Working Group, "Site Security Handbook", RFC 1244, Internet Engineering Task Force, July 1991.