| |
 |
 |
 |
|
|
|
|
Date: 01 January 1993
Click here for printable version
Rob McMillan
Information Technology Services Australian Computer 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:auscert@auscert.org.au
Phone: +61 7 875 6557 Phone: +61 7 365 4417
Fax: +61 7 875 7877 Fax: +61 7 365 7031
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:
(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.
3.0 What Are The Characteristics Of A Site Computer Security
Policy?
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.
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:
- data and information;
- 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.
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.
(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.
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:
- parties who should be notified, and the method and
urgency of such notification;
- policy on the necessity, timing and requirements of any
backups taken and logging that must be carried out;
- computer system and network isolation authority and
guidelines;
- statement of entrapment policy (if this is not already
expressed in the CSP philosophy); and
- statement of policies and requirements should an alleged
offender be traceable and possibly confronted
(particularly where actions may be affected by
external requirements such as a Statute dictating
that Security Officers must identify themselves).
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.
|
|
|
|
 |
|
 |
|
|