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:firstname.lastname@example.org Phone: +61 7 875 6557 Phone: +61 7 365 4417 Fax: +61 7 875 7877 Fax: +61 7 365 4477
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.
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.
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.
In addition to the benefits outlined above, a CSP offers an organisation the following benefits:
(a) It helps to make decisions with regard to other policies. It is not uncommon for a policy on a particular matter to refer to other policies. For instance, a CSP may refer to a policy on Copyright or a policy on dealing with the Press. Similarly, other policies may need to refer to specific sections of a CSP. This obviously is not possible if a CSP has not been formulated.
(b) It helps in making purchasing decisions. A CSP offers guidelines for standards of protection required on particular classes of computer systems. If a software or hardware component under consideration for purchase could be used to (or will actually) compromise these standards, then this may have an influence on whether the component is purchased.
(c) A CSP forms a framework for deciding what action to take in particular circumstances. In the event of a security breach, a CSP may contain guidelines of what authority particular people have to take certain actions to minimise the impact of that breach. Furthermore, after the breach, the policy will provide guidelines regarding the course 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. This removes the scope for independent reasoning at inappropriate times.
(d) A CSP should be considered as a living, long-term document that provides guidelines for the development of procedures applied to an organisation's computer systems on a regular or day-to-day basis. These procedures would be described in a Site Procedures Manual, and would be concerned with the specifics of an organisation's computer system and networking resources. Whereas the CSP describes principles (not implementation specifics) and should only ever be changed infrequently (when necessary), the Site Procedures Manual would be more volatile.
(e) Similarly to the above, a CSP will offer a framework for computer system configuration and network design and configuration.
(f) Because the development and enforcement of a CSP (and a Site Procedures Manual) is a non-trivial task, the existence and use of these documents is testament to the commitment of an organisation to professionalism.
(g) An important aspect of law is that ignorance is no excuse. Similarly, a well formulated and well advertised CSP leaves all people who have contact with an organisation's computer systems with a clear understanding of what constitutes acceptable behaviour, effectively removing ignorance of acceptable standards as an excuse for antisocial behaviour. (The reader should note that acceptable behaviour standards form only one part of a CSP, as explained in Section 4, What Does a Site Computer Security Policy Contain?.)
(h) A CSP may be required by an auditor in the course of an organisational audit.
An effectively written CSP should have the following characteristics:
(a) It should be useful, and preferably written in a form that is easy to read (implying usable and understandable English).
(b) It will be structured in a form that lends itself to finding relevant sections of the policy easily.
(c) Initial forms, and subsequent updates should be versioned and dated.
(d) In order to have any authority, it must be accepted as the official reference document by the authoritative people in the organisation.
(e) It must set out principles only. It should be written with the intention that it will be a living reference document, used over a long period of time, with infrequent (and preferably none) changes during its lifetime.
(f) It must be carefully worded. The key to preparing a policy document is to ensure that all terms are accurately and precisely defined, and that these terms are used exactly as they are intended. A careful balance must be achieved in the wording of concepts. Each concept must be worded precisely enough to effectively communicate the meaning of the concept, but not so precisely so as to be dependent upon a particular technology, or to otherwise unintentionally allow a breach of the intention (if not the wording) of the concept.
(g) A CSP should be considered as a parent document to a Site Procedures Manual, and prepared as such.
(h) Not only must a CSP set out acceptable conditions of use, but it should also set out unacceptable conditions of use.
(i) The CSP should be widely advertised to those people who are affected by it. Furthermore, there should be a section in the CSP about the advertising of the CSP.
(j) Because the CSP is intended to be a living document, it should be reviewed at regular intervals, and at any other time required. Furthermore, there should be a section in the CSP about these reviews.
(k) The CSP must not simply be an Acceptable Usage Policy (that is a policy on acceptable behaviour of users of computer systems). The CSP must also outline what rights and expectations of the resource provider users have with regard to the use of computer systems, guidance on various issues for system managers and decision makers, definitions of terms and so on.
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.
The abstract should set out what the document is and the organisation for whom it has been written.
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.
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.
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.
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).
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.
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).
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.
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.
(a) Form, in which it is explained in understandable terms what the vulnerability is, possibly through the use of (or including) realistic examples.
(b) Type (whether the vulnerability allows a threat to be realised in a deliberate or accidental manner), as this may have a bearing on policies, procedures and penalties.
(c) Extent, in which it is discussed what type of threat(s) might be realised by the vulnerability, both in the first instance and subsequently (giving some justification for the statements regarding impact).
(d) Impact on the organisation, possibly in both financial and non-financial terms. The impact may be expressed as a range, rather than a discrete value. Examples of non- financial impact are "negligible", "little" (where alternative workarounds are available with comparatively little effort and expense), and "complete" (the organisation will fold). The expression of non-financial impact is purely up to the ability, imagination and experience of the CSP author.
(e) Cause, in which a brief discussion is given of the primary reasons behind how and why the vulnerability may lead to the realisation of the threat.
(f) Solutions (possibly) to either effectively negate the cause or minimise the impact.
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.
(a) Account use, by both the account holder and the resource provider. Special conditions may apply to the use of normal user accounts, and public access accounts (like anonymous ftp), and these conditions could be expressed here.
(b) Software and data access and use, including sources of data and software.
(c) Disclosure of information which is potentially harmful, such as password information or system configuration information.
(d) Etiquette, including acceptable forms of expression (e.g. non-offensive expression expected for unsolicited electronic mail), and unacceptable practices (such as the forging of electronic mail and news articles).
(e) Password use and format.
(f) Rights to privacy, and the circumstances under which the resource provider may intrude on the files held under or activities practiced by an account.
(g) Other miscellaneous guidelines regarding reasonable practices, such as the use of CPU cycles and temporary general access storage areas. Copyright issues may also be discussed here.
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.
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.
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.
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.