Copy Link
Add to Bookmark
Report
Phuk Magazine Issue 01 Phile 08 of 10
=============================================================================
PHUK MAGAZINE - Phile 8 of 10
=============================================================================
------------------------------------------
British Telecom - Computer Security Manual
------------------------------------------
Mrs. Brady, of Doncaster
------------------------
Heads up!! This one is a goody! sent to us anonymously by someone who
wishes only to be known by the name of Mrs. Brady of Doncaster, this
is a delightful trashing find of the British Telecom Computer Security
manual!! Run in PHUK as a three part series, here is the first part,
right up to the bits about computers and networks ... which should
make you all look forward to the next issue of PHUK magazine....:)
SEC|POL|AO12
NOT TO BE SHOWN OUTSIDE BT
ISIS Directive
Computer Security Manual
Origin: Security and Investigation Directorate
Issue 7: March 1993
Contents
Foreword by the chairman. . . . . . . . . . . . . . . . . iv
Amendment record sheet. . . . . . . . . . . . . . . . . . . v
List of effective pages . . . . . . . . . . . . . . . . . vii
Introduction and scope. . . . . . . . . . . . . . . . . . 1-1
Introduction. . . . . . . . . . . . . . . . . . . . . . . 1-2
Scope and purpose . . . . . . . . . . . . . . . . . . . . 1-2
Relationship to the previous issue. . . . . . . . . . . . 1-3
Structure of the manual . . . . . . . . . . . . . . . . . 1-3
Feedback. . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Use of the CSM by suppliers and contractors . . . . . . . 1-4
Acknowledgements. . . . . . . . . . . . . . . . . . . . . 1-4
Objectives and policy . . . . . . . . . . . . . . . . . . 2-1
Introduction. . . . . . . . . . . . . . . . . . . . . . . 2-2
Corporate policy on electronic system security. . . . . . 2-2
Objective . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Relationship to other security policies . . . . . . . . . 2-2
Responsibility for security . . . . . . . . . . . . . . . 2-3
Derivation of security requirements . . . . . . . . . . . 2-4
Security policy for the life cycle. . . . . . . . . . . . 2-6
Security evaluation, certification and accreditation. . . 2-7
Security approvals. . . . . . . . . . . . . . . . . . . . 2-9
Product security. . . . . . . . . . . . . . . . . . . . .2-10
Communications and network security . . . . . . . . . . . 3-1
Introduction. . . . . . . . . . . . . . . . . . . . . . . 3-2
System interconnection . . . . . . . . . . . . . . . . . 3-4
Network management . . . . . . . . . . . . . . . . . . . 3-5
Network architecture . . . . . . . . . . . . . . . . . . 3-5
Threats to networked systems . . . . . . . . . . . . . . 3-8
Cryptographic protection . . . . . . . . . . . . . . . .3-13
Electronic Mail Systems . . . . . . . . . . . . . . . . .3-14
Electronic systems insta11ations . . . . . . . . . . . . 4-1
Introduction . . . . . . . . . . . . . . . . . . . . . . 4-2
Accommodation . . . . . . . . . . . . . . . . . . . . . . 4-2
Services . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Electronic system equipment sign posting . . . . . . . . 4-5
Physical access control strategy . . . . . . . . . . . . 4-5
Personnel access . . . . . . . . . . . . . . . . . . . . 4-7
System or master consoles . . . . . . . . . . . . . . . . 4-8
Other terminals . . . . . . . . . . . . . . . . . . . . . 4-9
Communications rooms and equipment . . . . . . . . . . . 4-9
Media libraries and disaster stores . . . . . . . . . . . 4-9
5 Personal computers . . . . . . . . . . . . . . 5-1
5.1 Introduction . . . . . . . . . . . . . . . . . 5-2
5.2 Personal security responsibility . . . . . . . 5-3
5.3 PC and data access security. . . . . . . . . . 5 4
5.4 Security of software . . . . . . . . . . . . . 5-8
5.5 Personal computer communications . . . . . . . 5-8
5.6 Contingency planning . . . . . . . . . . . . . 5-10
5.7 File Servers . . . . . . . . . . . . . . . . . 5-12
6 User access to computers . . . . . . . . . . . 6-1
6.1 Introduction . . . . . . . . . . . . . . . . . 6-3
6.2 Regulating access to computers . . . . . . . . 6-3
6.3 Identification . . . . . . . . . . . . . . . . 6-4
6.4 Passwords. . . . . . . . . . . . . . . . . . . 6-6
6.5 Limitations of password security . . . . . . . 6-10
6.6 Logging on . . . . . . . . . . . . . . . . . . 6-11
6.7 Logging off. . . . . . . . . . . . . . . . . . 6-14
6.8 User privileges. . . . . . . . . . . . . . . . 6-15
6.9 Access to user files . . . . . . . . . . . . . 6-16
6.10 Customer access to BT computers. . . . . . . . 6-17
6.11 Contractors . . . . . . . . . . . . . . . . . .6-18
7 Software and data . . . . . . . . . . . . . . .7-1
7.1 Introduction. . . . . . . . . . . . . . . . . .7-2
7.2 Software installation and maintenance . . . . .7-2
7.3 Log facilities and system data. . . . . . . . .7-4
7.4 Data sensitivity. . . . . . . . . . . . . . . .7_7
7.5 Storage . . . . . . . . . . . . . . . . . . . .7-8
7.6 Disposal of media . . . . . . . . . . . . . . .7-9
7.7 Computer viruses. . . . . . . . . . . . . . . .7-11
8 Administraion . . . . . . . . . . . . . . . . .8-1
8.1 Introduction. . . . . . . . . . . . . . . . . .8-2
8.2 Personnel . . . . . . . . . . . . . . . . . . .8-2
8.3 Disaster protection . . . . . . . . . . . . . .8-7
9 Data protection act . . . . . . . . . . . . . .9-1
9.1 Introduction. . . . . . . . . . . . . . . . . .9-2
9.2 Data protection act principles. . . . . . . . .9-2
9.3 Definitions . . . . . . . . . . . . . . . . . .9-3
9.4 Registration. . . . . . . . . . . . . . . . . .9-4
10 Further information . . . . . . . . . . . . . .10-1
10.1 Introduction. . . . . . . . . . . . . . . . . .10-2
10.2 Security contacts . . . . . . . . . . . . . . .10-2
10.3 Sources of other guidance . . . . . . . . . . .10-4
10.4 Contingency Planning for Anton Piller Orders. .10-7
10.5 GLS conhcts (1993/94) . . . . . . . . . . . . .10-9
11 Approved products . . . . . . . . . . . . . . .11-1
11.1 Introduction. . . . . . . . . . . . . . . . . .11-2
11.2 List of products. . . . . . . . . . . . . . . .11-2
G Glossary. . . . . . . . . . . . . . . . . . . .G-1
Foreward by the chairman
A vital element in our drive to achieve the highest quality of service
standards is the provision of a secure work environment. This means
that our resources - people, systems, information and physical assets
must be protected against a variety of threats which range from
the malicious to the criminal. We also have security obligations that
form part of the legal and regulatory requirements we must observe.
The Information Security Code, Computer Security Manual and Physical
Security Handbook define the ways in which we can maintain a secure
environment. They clarify our responsibilities and provide the expert
guidance which we can use to achieve and maintain the levels of
security appropriate to the various activities of BT. The rules
outlined in these publications are mandatory.
IDT Vallance
Introduction and scope
Contents
1.1 Introduction . . . . . . . . . . . . . . . . . . . 1-2
1.2 Scope and purpose. . . . . . . . . . . . . . . . . 1-2
1.3 Relationship to the previous issue . . . . . . . . 1-3
1.4 Structure of the manua1. . . . . . . . . . . . . . 1-3
1.5 Feedback . . . . . . . . . . . . . . . . . . . . . 1-4
1.6 Use of the CSM by supp1iers and contractors. . . . 1-4
1.7 Acknowledgements . . . . . . . . . . . . . . . . . 1-4
1.l Introduction
British Telecom (BT) is highly reliant on electronic systems to support its
business processes. Computers are used in many critical points in the business: in
switching systems, administration systems and management systems. Many of
these systems are either interconnected, or are planned to be interconnected,
BT's infrastructure of systems will become highly integrated.
This evolutionary process makes security even more important. It is
becoming possible to access a wide variety of information from a
single terminal. Furthermore, a security flaw or failure in one system
may allow unauthorised access or misuse of other systems.
BT possesses valuable information about its customers and their
commercial operations which it is our responsibility to safeguard.
Coupled with this should be an awareness of the possibility of
computer crime by people inside and outside BT.
While security failures are, like any other quality failure, bad
business practice, the repercussions may be more serious.
There are many motivators for good electronic security. BT is obliged
under the terms of its current licence to observe a Code of Practice
on disclosure of customer information. Disclosure of information could
also provide likely movements in the price of BT shares or those of
our suppliers. It could be used to embarrass the business by
disclosure of commercial negotiations. The business could also suffer
through corruption or loss of data. There could also be personal legal
liability under the terms of the Data Protection Act in the event of
security failure. All these possibilities make the security of BT
computer operations increasingly important.
Good security does not have to be expensive. Often simple, low-cost
measures, combined with a positive attitude to security, can achieve
considerable reduction in the vulnerability of BT systems.
1.2 Scope and purpose
Although this manual is called the Computer Secunty Manual, it
encompasses all electronic systems that are broadly computer-based. It
applies equally, for example, to digital switching systems and
building access control systems, as well as to the mainframe and
personal computers for which it has customarily been used.
BT is now operating in a global environment and its activities cover
most parts of the world. Many of its non-core activities and overseas
operations are carried out through subsidiary companies. All people
working in these wholly-owned subsidiaries are also "BT people". "BT"
refers to the parent company and all its wholly owned subsidiaries.
Adoption of the CSM in partly-owned subsidiaries will be a matter
negotiated between the Director of Security and Investigation and the
senior management of each part-owned subsidiary.
The purpose of the Computer Secunty Manual is to enable BT people to
recognise possible threats to BT s systems, and to bring together the
current guidance on electronic security principles and practices which
may be used to minimise the risk.
Examples of threats include:
o natural calamities such as fire or flood
o sophisticated tampering
o software errors
o hardware failure
o vulnerability of communication links
o unauthorised use of terminals
o hacking
o deliberate damage, and
o fraud.
The Computer Security Manual is primarily intended for those who specify
security requirements in BTs systems and those who implement them, it
is also essential reading for users of those systems so that they may
understand the rationale behind the protective measures that may be
imposed upon them. While it is recognised that the threats to BT's
systems are constantly changing, the guidance given is the best
available at the time of issue. It should be recognised however, that
guidance will need to be revised when existing threats change or new
threats appear.
1.3 Relationship to the previous issue
Although some of the policies on electronic systems security affecting
computers have changed since the last issue, the previous structure
has been retained where possible, so as to cause minimum inconvenience
to users of the manual.
1.4 Structure of the manual
This version of the Computer Security Manual contains mandatory
requirements, called CSM Policies, which should be followed in the
design, implementation and operation of systems.
The CSM Policies describe various mechanisms that can be employed to
protect the security of an electronic system, and are derived from
threats (that have been found) and countermeasures that can be used.
The main text provides guidance and background to the CSM Policy statements.
The chapters have been ordered to reflect the larger view of systems
(networked systems and the supporting network infrastructure), and
then narrowing that view to large computer systems, personal
computers, and so on.
The page number found at the bottom of each page is in the format
chapter-page in chapter and facilitates the easy replacement of entire
chapters without upsetting the numbering of pages in subsequent chapters.
1.5 Feedback
The policy and guidance contained in e Computer Security Manual is
prepared and issued after extensive discussion with experts in
electronic security throughout the business. The Electronic Security
Unit welcomes feedback from users on the adequacy of the guidance
given, so that future issues may be improved.
1.6 Use of the CSM by suppliers and contractors
The CSM is the baseline document for the protection of BT's electronic
assets on BT premises, in transit, at employees' homes or on
contractors' premises. Where a supplier or contractor has obligations
to protect BT assets, a copy of the CSM may be loaned to supply the
necessary guidance provided:
Agreement is obtained from DSecI
2 A non-disclosure agreement is in place with the supplier or
contractor based on the "Acceptance Agreement from BT"' contained
within the Information Security Code
3 Sections 10 and 11 are removed from the manual before it is lent to
anyone outside BT.
4 The manual is returned to BT upon completion or termination of the
contract.
Updates to the CSM will be sent to the manager who originally arranged
the loan, who must ensure that the update arrangements meet criteria 3
and 4 above. The CSM must be returned on completion of termination of
the contract.
1.7 Acknowledgements
We would like to thank the help received by all parts of the BT Group
in the production of this version of the Manual. In particular, Group
Security, Group Information Services, British Telecom International,
British Telecom Security Consultancy, Business Communications,
Development and Procurement, Internal Audit, and to others for their
feedback to this, and previous issues of the Manual.
Objectives and policy
Contents
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2-2
2.2 Corporate policy on electronic system security . . . . . 2-2
2.3 Objective. . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.4 Relationship to other security policies. . . . . . . . . 2-2
2.4.1 Application . . . . . . . . . . . . . . . . . . . . . . 2-3
2.5 Responsibility for security . . . . . . . . . . . . . . . 2-3
2.5.1 Business operation or process owner. . . . . . . . . . . 2-3
2.5.2 System supplier. . . . . . . . . . . . . . . . . . . . . 2-4
2.6 Derivation of security requirements. . . . . . . . . . . 2-4
2.6.1 Value and impact analysis. . . . . . . . . . . . . . . . 2-4
2.6.2 Data sensitivity . . . . . . . . . . . . . . . . . . . . 2-4
2.6.3 Countermeasures . . . . . . . . . . . . . . . . . . . . .2-5
2.6.4 Risk analysis. . . . . . . . . . . . . . . . . . . . . . 2-6
2.7 Security policy for the life cycle . . . . . . . . . . . . 2-6
2.8 Security evaluation, certification and accreditation . . . 2-7
2.8.1 Scope of accreditation . . . . . . . . . . . . . . . . . 2-7
2.8.2 Four-stage approach to security accreditation. . . . . . 2-7
2.9 Security approva1s . . . . . . . . . . . . . . . . . . . 2-9
2.10 Product security . . . . . . . . . . . . . . . . . . . . 2-9
2.1 Introduction
This chapter describes the objectives of the Computer Security Manual,
and places electronic security in the context of the security
infrastructure for BT s business operations and processes.
2.2 Corporate policy on electronic system security
The electronic systems security policy for the BT Group as affirmed by
Malcolm Argent, Group Director & Secretary, on 8th August 1990 is
reproduced below.
"The British Telecom Group attaches particular importance to the
security of its business processes and systems. The Group's policy on
electronic security is to ensure that we properly safeguard all our
switching systems, information systems and other electronic assets,
having regard to legal and regulatory requirements, our commercial
interests and sound business practices.
This policy covers all aspects of the electronic environment: systems;
administration procedures; environmental controls; hardware; software;
data and networks. It applies to all stages in the system life cycle,
from feasibility study through to in service and operations. It
applies no matter whether the system is developed or bought by BT. It
is the responsibility of managers at all levels to observe this policy
themselves and to ensure that it is fully understood and followed by
their people.
To help managers carry out their responsibilities, the Director of
Security and Investigation will issue appropriate guidelines, on a
continuing basis, supplementing the requirements of the Computer
Security Manual, The Information Security Code and the Physical
Security Handbook to take account of changing threats to BT's
electronic systems. He will also be the central point of information
for the Company's policy on electronic security and will monitor
compliance with it. "
2.3 Objective
The Computer Security Manual draws together the policies applying to
computer systems in particular, and electronic systems in general,
supplementing it with guidance and advice on implementation. Within
the BT Group there are many different computer systems supporting a
multitude of business processes. Therefore it is not possible to
produce specific recommendations for the security of every aspect of
every system. The objective of the Manual is to concentrate on the
baseline policy and guidelines generally applicable to BT systems.
2.4 Relationship to other security policies
The Computer Security Manual is an elaboration and extension of the
information security strategy contained in the Information Security
Code.
2.4.1 Application
Except where inapplicable, the Policies enumerated in the Computer
Security Manual are MANDATORY. For example: Passwords are not a
mandatory feature of all BT systems, but where an analysis suggests
that passwords are a sufficiently strong measure to regulate access to
those systems, the relevant policies on passwords contained in this
Manual become mandatory. Policies usually appear after any descriptive
text and are numbered to assist the checking of compliance in systems.
While Policies are mandatory, all supporting guidance and advice on
implementing the policies is discretionary, although strongly
recommended to achieve a harmonious and consistent approach to
electronic security throughout the BT Group. Policies appear within
boxes.
POLICY 2.1: ASSIMILATION OF REVISED MANDATORY POLICY
From the date of publication, this issue of the Computer Security
Manual applies to all new systems supporting BT's business operations
and processes. It also applies to any changes to existing systems, in
particular where an opportunity to update security occurs, so as to
achieve greater compliance with the policies given in this manual.
2.5 Responsibility for security
Every BT employee, and those contracted to work for BT have the
responsibility to ensure the security of BT assets. Where the asset is
information, the degree of protection needed is defined by the owner
of the information. Additional measures may be required beyond those
necessary to protect BT's information assets because of legal
requirements.
2.5.1 Business operation or process owner
It is the responsibility of the owner of each business operation or
process to recognise the value of their activity, and the potential
impact on the business from security failure. In the context of the
Computer Security Manual, ownership of a process is defined as the
manager responsible or accountable for the process. The
responsibility of the business operation or process owner also extends
to ensuring that, in general terms, security of the systems supporting
the process is adequate in relationship to the impact of security
failure. A service level agreement should exist between the business
process and the system owners.
POLICY2.2: RESPONSIBILITY ASSIGNED TO PROCESS OWNERS
The owner of each business process shall ensure that security is
adequate in the systems that support the process.
2.5.2 System supplier
The process owner will be responsible for evaluating the impact of
security failure and deciding on the general requirements for
security. The detailed implementation of security controls and
countermeasures to meet the owner's requirements will be the
responsibility of the system supplier whose computer systems support
the process. The process owner and the computer supplier will usually
be linked through a customer/supplier relationship. The quality of
computer security, including the adherence to the policies described
in this Manual should be the subject of a Service Level Agreement.
2.6 Derivation of security requirements
2.6.1 Value and impact analysis
The security measures needed to safeguard each business process wil be
determined from the sensitivity of the material handled and the impact
of security failure, defined in terms of confidentiality, integrity
and availability. The owner of each business operation or process will
ensure that the value of the information processed and the impact of
security failure are known since they are the core parameters in the
rationale of cost-effective security. Sometimes the value of the
information may be obvious and easily quantified as a monetary
expression. On other occasions, the value of the information or
processing capability is less apparent, protection being necessary to
safeguard only the reputation or credibility of the Business. Impact
of failure includes the concepts of asset value, importance, damage to
the business because of information disclosure, loss of accuracy or
currency of the information, and loss of the use of business-critical
resources.
2.6.2 Data sensitivity
The Informaion Security Code describes the privacy marking to be used
to identify information which requires a level of protection beyond
that provided by a clear desk policy. Currently this protection is
defined only in terms of the confidentiality requirements of security.
There is no comparable marking for integrity or availability.
Information stored using electronic media is more vulnerable wen
stored than information on paper . It can be easily modified without
trace, and its content is not immediately obvious. It is readily
deleted, and in large systems can be easily lost. Therefore the
sensitivity of electronic data should be specified in terms of the
impact of loss arising from failure of confidentiality, integrity or
availability.
To preserve compatibility with the paper-based system, data
sensitivities for electronic information use the same criteria for
assessing the impact of security failure, thus allowing common threat
models to be used.
2.6.2.1 Sensitivity level 1
Information for which the impact of inaccuracy, alteration, disclosure
or unavailability would be to cause inconvenience or reduction in
operational efficiency.
2.6.2.2 Sensitivity level 2
Information for which the impact of inaccuracy, alteration, disclosure
or unavailability would be to cause any of the following:
o Significant financial loss to BT;
o Significant gain to a competitor;
o Marked embarrassment to BT;
o Marked loss of confidence to BT and its commercial dealing;
o Marked reduction of BT's standing in the community or to relationships generally.
Information marked IN CONFIDENCE has sensitivity level 2.
2.6.2.3 Sensitivity 1evel 3
Information for which the impact of inaccuracy, alteration, disclosure
or unavailability would be to cause any of the following:
o Substantial financial loss to BT;
o Substantial gain to a competitor;
o Severe embarrassment to BT;
o Serious loss of confidence in BT;
o Serious reduction of BT's standing in the community or to
relationships generally.
Information marked IN STRICTEST CONFIDENCE has sensitivity level 3 and
are called in this manual High Impact Systems.
2.6.2.4 Sensitivity levels above 3
Impact scenarios exist for failures of security for data beyond
sensitivity level 3. Specialist advice is available from the Director
of Security and Investigation on electronic systems which process:
corporate plans; business propositions (new enterprises, flotations,
joint ventures, take-overs); personnel and industrial relations
matters; marketing strategies and plans; financial and tariff
proposals, and high-level contractual matters, or other information
which is price-sensitive within the terms of the Stock Exchange
Listing Agreement.
POLICY2.3: VALUE OF ASSETS AND IMPACT OF FAILURE
The value of the information, assets or processing capability to be
protected shall be estimated and recorded, as shall the impact of
possible disclosure, inaccuracy, incompleteness or unavailability of
that information.
2.6.3 Countermeasures
A fundamental objective is to ensure that the countermeasures deployed
to protect sensitive information or processes should be practical and
appropriate to the threats against the electronic systems, giving due
regard to the impact of security failure.
While insufficient, inappropriate, or poorly implemented
countermeasures may leave a system unduly vulnerable, excessive
countermeasures may lead to complacency, the neglect of security
operating procedures, and an unjustifiably high overhead of processing
power, or severe operational difficulties.
POLICY 2.4: COUNTERMEASURES
The cost of countermeasures should be appropriate to the threats to
security and business processes, the value of the information being
protected and the impact of any security failure.
2.6.4 Risk analysis
It is the responsibility of the owner of each business operation or
process to assess and manage effectively the degree of risk to
commercially sensitive information, and the resilience of critical
business processes supported by computer-based systems. The risk
analysis will take cognisance of the value of the information or
critical processes being protected, and the perceived threats to the
system. Furthermore, the risk analysis should not be a once-only
exercise. It should be repeated regularly and revalidated whenever
significant changes occur to the security assumptions.
POLICY2.5: RISK ANALYSIS
At all principal stages during the life cycle of each project
involving the storage or processing of commercially sensitive
information, or the provision of High Impact Systems, a risk analysis
shall be undertaken. The analysis, which must be repeated periodically
or revalidated to assess the impact of change, must be so as to
determine the vulnerability of the commercially sensitive information
or applications in its processing environment, given the prevailing
threats to security, the countermeasures deployed, and the value of
the information being processed.
2.7 Security policy for the life cycle
The preparation of a Security Policy Document (Security Statement)
should be viewed as an integral part of the life-cycle of business
processes. At the beginning of each project a security policy will be
prepared to guide the implementation of security in the systems that
will support the business operation. This vital step is necessary to
ensure that correct business planning decisions are taken. Where
security is a relevant feature of a process, its provision will be
costed and included in business cases going forward for financial
approval.
POLICY 2.6: SECURITY POLICY DOCUMENT
A Security Policy Document will be prepared by the owner of a business
process, outlining the system, the impact or loss associated with
possible security failure, the threats to the system, the proposed
countermeasures, and a risk analysis. The Security Policy Document
will guide development and implementation of security features during
the development life- cycle of the system that supports the business
process, of which electronic security is an integral part. A Security
Policy Document is also required for existing systems where the impact
of security failure is high.
Details of all BT multi-user, administration and management systems
must be registered by the Development Manager on the Applications
Inventory. This is the catalogue of the company's software assets, and
is used to inform People of what systems exist and assist management
of the portfolio. The requirement to register covers systems that are
either developed or procured by BT. Details may be found in section 10.
2.8 Security evaluation, certification and accreditation
The accreditation life cycle is a process for checking that
appropriate security is built into the specification, development and
operational procedures for systems, thereby ensuring that the security
requirements of the business are met prior to the system becoming
operational.
Security accreditation for electronic systems has three main objectives:
- to ensure that the level of security in BT's High Impact Systems is
adequate;
- to prevent systems without adequate security being deployed until
remedial action has been undertaken; and
- to provide a framework for the continued improvement of the quality
of security in BT's systems.
2.8.1 Scope of accreditation
System security accreditation is a process which is undertaken to
ensure that security mechanisms, procedures and functions have been
implemented in a way that guarantees a level of confidence in the
quality of the system security. The BT scheme, which is broadly based
upon the 'Information Technology Security Evaluation Criteria'
(lTSEC), is facilitated through agents operating on behalf of the
Director of Security and Investigation.
2.8.2 Four-stage approach to security accreditation
The object of Security Accreditation is to reduce the risk of security
failure without unduly delaying the implementation of important
systems. To assist in meeting this objective a four-stage
accreditation process has been developed.
2.8.2.1 Stage 1 - Security Policy Document (Creation and Approval)
The Security Policy Document (SPD) outlines the system, the impact or
loss associated with possible security failure, the threats to the
system and the generic countermeasures. The SPD will also contain a
risk analysis and an assurance rating to be used during subsequent
evaluation and certification. Only high impact systems progress into
the evaluation, certification and accreditation stages. Note, however,
that all new systems must have a System Security Statement, regardless
of the need to progress into stage 2. The SPD is created by the owner
of the business process and approved by DSecI.
2.8.2.2 Stage 2 - Evaluation
Those systems which are to be included in the accreditation process,
as indicated within the SPD and agreed by Director of Security and
Investigation (DSecl), will be evaluated to ascertain that the
required level of assurance has been achieved. The SPD is the baseline
document against which the system is evaluated.
DSecI will nominate an evaluator to gain and subsequently analyse
information on the following:
Requirements - a detailed description of the system requirements
relating to its security.
Architectural design - an examination of the system architecture.
Detailed design - a more detailed description on how specific security
components have been designed.
Implementation- evidence of functional and mechanism testing.
Examination of source code and hardware drawings.
Configuration control- evidence of an effective change control
procedure which is able to provide unique identification of the system
and details of an acceptance procedure.
Program languages and compilers - details about the language(s) used.
Developers' security- security procedures including physical and
personnel arrangements.
Operational documentation - examination of the user and administration
documentation provided.
Operational environment-
- delivery and configuration - configuration information, delivery and
audited system generation procedures and evidence of an approved
distribution procedure;
- startup and operation - secure startup and operation procedures,
including a description of security functions that have a relevance
during system startup. Evidence that effective hardware diagnostic
test procedures exist.
2.8.2.3 Stage 3 - Certification
Certification occurs after the system has been developed. In order for
certification to be given, the evidence as described within the
evaluation report(s) must show that security has been correctly
applied during the development phase.
2.8.2.4 Stage 4 - Accreditation
Final accreditation occurs after the system has been running for a
limited period of time as agreed between DSecI and the Process Owner.
The purpose of the trial is to allow the secure operating procedures
to be assessed in a live environment. The system is then inspected in
its operational environment to ascertain whether compliance has been
achieved. When a security audit indicates that this aspect of security
is satisfactory, final security accreditation can be given, after
which the system enters the normal periodic security audit cycle.
POLICY 2.7: SECURITY ACCREDlTATION
It is the responsibility of the owner of each business process, for
which the impact of failure is high, before making operational use of
the system to furnish the Director of Security and Investigation with
evidence that the security requirements described in its Security
Policy Document have been observed during the development life cycle.
2.9 Security approvals
Many of the policies within the Computer Security Manual require that
only products approved by the Director of Security and Investigation
may be used to protect BT commercially sensitive information and processes.
SecID maintains a list of approved products. If you require a product
to be submitted through the approvals procedure it is necessary to do
this via SecID. See the contact data in Section 10.
2.10 Product security
Developers and procurers of products for internal BT use should be
aware of the target market for the products. An assessment must be
made of the likely sensitivity of material handled by the product.
Although security demands personal responsibility from the people
carrying out a particular business process, managers should not avoid
the responsibility of providing users with a secure product
environment. It is much better to design security into products rather
than to add it on as an afterthought. Substantial economies of scale
can be achieved by building security into products.
POLICY 2.8: PRODUCTS FOR INTERNAL USE
Managers shall ensure that the security of products intended for
internal BT use meet users' needs. A clear statement shall be included
with all literature giving the sensitivity level for which the product
is suitable, and the circumstances under which it will retain its
suitability.
Communications and network security
Contents
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . 3-2
3.1.1 General policies . . . . . . . . . . . . . . . . . . . 3-2
3.2 System interconnection . . . . . . . . . . . . . . . . 3-4
3.3 Network management . . . . . . . . . . . . . . . . . . 3-5
3.4 Network architecture . . . . . . . . . . . . . . . . . 3-5
3.4.1 Private circuits . . . . . . . . . . . . . . . . . . . 3-5
3.4.2 Public Switched Telephone Network (PSTN) . . . . . . . 3-6
3.4.3 Public data networks . . . . . . . . . . . . . . . . . 3-6
3.4.4 Local area networks. . . . . . . . . . . . . . . . . . 3-7
3.5 Threats to networked systems . . . . . . . . . . . . . 3-8
3.5.1 Information disclosure . . . . . . . . . . . . . . . . 3-8
3.5.2 Unauthorised access. . . . . . . . . . . . . . . . . . 3-10
3.5.3 Modification, insertion and deletion . . . . . . . . . 3-12
3.5.4 Denial or failure of service . . . . . . . . . . . . . 3-12
3.6 Cryptographic protection . . . . . . . . . . . . . . . 3-13
3.7 E1ectronic Mail Systems. . . . . . . . . . . . . . . . 3-14
3.1 Introduction
Transmitting information between computers and other electronic based
systems can represent a substantial threat to security. Therefore
safeguards appropriate to the sensitivity of the information and the
transmission medium should be adopted during its transmission.
Most of the measures described in this section are concerned only with
the protection of communication links against attack by unauthorised
persons. Few of the techniques safeguard against illicit activities by
authorised users who misuse their privilege. This section gives
guidance on the acceptability of various communications methods and
services for the transfer of commercially sensitive information. The
methods recommended do not necessarily give complete
protection absolute security is never feasible. This section addresses
the issues of computer systems connected by networks, either to other
computers for exchange of information or to enable remote access where
the users of computer-based applications are remote from the service
or information provider.
The advice and guidance offered herein is applicable to networks of
mainframes, personal computers and terminals or any combination of
them.
3.1.1 General policies
The following general policies apply to every case of electronic
transfer of privacy marked information.
POLICY 3.1: INFORMATION CORRECTLY LABELLED
The originator shall ensure that information to be communicated is
correctly marked in accordance with the Information Security Code.
POLICY 3.2: INFORMATION APPROPRIATELY PROTECTED
It is the responsibility of the author and originator of privacy
marked or commercially sensitive information communicated via
electronic means to ensure that it is always correctly safeguarded.
\POLICY 3.3: INFORMATION CORRECTLY ADDRESSED
The originator shall ensure that IN STRICTEST CONFIDENCE information
is sent only to a specific authorised recipient.
POLICY 3.4: TRANSMISSION OF HIGH IMPACT OR IN STRICTEST
CONFIDENCE ELECTRONIC INFORMATION
HIGH IMPACT or IN STRICTEST CONFIDENCE information shall not be
transmitted without the protection of an encryption system approved by
Director of Security and Investigation except where one of the
following is used:
1. private circuits for which access to all distribution frame and
flexibility points are secured for HIGH IMPACT or IN STRICTEST
CONFIDENCE information, and which are routed via ducts, risers and
conduits having tamper detecting seals.
2. fibre optic circuits for which all connection points are secured
for HIGH IMPACT or IN STRICTEST CONFIDENCE information,
3. an Exclusive LAN in a secured area used only by BT People.
POLICY 3.5: TRANSMISSION OF IN CONFIDENCE ELECTRONIC INFORMATION
IN CONFIDENCE information shall not be transmitted without the
protection of approved encryption system unless communication is
strongly authenticated, such as by:
1. via Private Circuits between BT buildings,
2. via the Public Switched Telephone Network with approved dialback systems,
3. via the PSS using closed user groups (or equivalent), or
4. via the PSS with a challenge response system.
POLICY 3.6: USE OF ELECTRONIC MAIL SYSTEMS
Privacy marked or sensitive information shall not be transmitted
between systems using Electronic Mail Systems that have not been
approved as suitable for that use by the Director of Security and
Investigation.
POLICY 3.7: SPECIAL DISPENSATION IN AN EMERGENCY
Where special justification exists, for example in emergencies, IN
STRICTEST CONFIDENCE information may exceptionally be transmitted
according to the conditions for IN CONFIDENCE material. In these
circumstances, prior authority from a person in the Senior Management
Group shall be obtained on each occasion.
System interconnection
The connection of a system of computers by means of a network forms
the basis for bilateral agreements and practices between those
responsible for the security of the computers and those responsible
for the security of the network. A failure by any of those involved to
correctly secure the equipment for which they are responsible, may
result in a failure of security of the entire network.
It is the responsibility of the owners of all computer systems
connected to a network to ensure that their security is not
compromised by the network techniques used, or by any subsequent
changes to the network configuration and topology. Before allowing
connection of a computer system to a LAN or other network, the owners
of the business processes entrusted to that system must satisfy
themselves that their policy for security will not be violated.
Connection must be refused by the computer system administrator on
behalf of the business process owner if the networking arrangements
are or become inconsistent with the security policy. These
considerations apply to any network which permits access to several
computer systems via a common telecommunications facility (whether all
users need such access or not).
The connection of any computer system to a network introduces a number
of additional threats to the security of that system, to the security
of the network and to any other computer system sharing the network.
By far the greatest threat to a computer connected to a network is the
possibility of unauthorised access from other network users. Other
threats include the accidental or unintentional distribution of
privacy marked information across the network.
The vulnerability of the network increases because the authority to
grant users permission to access the network is given to the
administrator of the connected computer system. If that computer were
already connected to another network, for example, the number of
potential users might increase dramatically.
POLICY 3.8: CONNECTION OF A COMPUTER SYSTEM TO NETWORKS
The administrators of a computer system connected to networks shall
ensure that the network arrangements do not contravene the security
policy of the business processes or applications being supported by
their system.
POLICY 3.9: INTERCONNECTION OF NETWORKS
Networks shall not be joined together unless it can be shown that the
resulting network does not contravene the security policy of either
network or of the security policy of those systems connected to either
network.
POLICY 3.10: ADMINISTRATION OF A COMPUTER CONNECTED TO A
NETWORK
The administrators of a computer system connected to networks shall
ensure that the security administration of their system does not
contravene the security policy of the network to which their system is
connected.
3.3 Network management
Owners of systems connected to a network have a level of expectation
about the services that the network provides. For example, network
users may expect that the service:
o is available when it is needed,
o has sufficient capacity to carry the load,
o is able to ensure the confidentiality of information in transit,
o does not corrupt the information in transit,
o delivers the information to the intended recipient,
o restricts access to those so authorised.
The level of service offered by the network should be well documented
and will form the basis of any contract between the owner of the
network and the owners of the connected systems.
POLICY 3.11: NETWORK SECURITY POLICY
Providers of networks that claim to provide security functions shall
declare to their users and customers the protective measures, and
conditions placed on the users of the network, for security offered by
the network and shall make available a document describing these
features and their applications.
3.4 Network architecture
The following means of computer-to-computer and user-to-computer
access are commonly encountered:
o Private Circuits,
o Public Switched Telephone Network,
o Public data networks (PSS, for example),
o Local Area Networks (of various types), and
o Integrated Services Digital Network (called IDA in the UK).
3.4.1 Private circuits
Private Circuits are often perceived as being secure because of their
immunity to logical attack, that is, hacking. They are not necessarily
physically secure because their fixed routing may make them vulnerable
to direct interception. Typically, Private Circuits may be routed via
the distribution frame of the local exchange and the building serving
the user. Unless otherwise protected, the information on the Private
Circuit is vulnerable to interception at these points.
3.4.2 Public Switched Telephone Network (PSTN)
The PSTN is open to public access and is the favoured medium for
unauthorised access world-wide. Because Calling Line Identification
(CLI) is not currently provided as a basic facility, it is not easy to
identify the origin of connection attempts. For this reason, dialup
PSTN access to BT systems containing sensitive data is forbidden
unless adequate precautions are taken.
The connection of computers to the PSTN for the purposes of
outward-bound connections to information service providers is strongly
discouraged unless it can be demonstrated that the connection
equipment cannot be subverted or incorrectly configured so as to
permit inward-bound connections.
POLICY 3.12: PSTN CONNECTION TO BT SYSTEMS
BT computer systems containing or processing sensitive information
shall not be connected to the PSTN unless adequate precautions are
taken to protect the system from unauthorised access.
3.4.3 Public data networks
Worldwide, there are many different data networks available to the
public. The following comments refer specifically to BT's UK data
network known as PSS.
In general, there are two methods by which a connection to PSS can be
achieved: ]
o by direct connection (a private circuit connecting the user to the
X25 network), or
o by dial connection (via the PSTN, to an X25 PAD in the network).
Each user of PSS is identified by a Network User Address (NUA) which
is analogous to a telephone number. Where the user is directly
connected to PSS, the NUA is permanently associated with that line and
can provide a valuable check on the user's identity.
If the user gains access to the PSS by dial connection to a PAD, he
identifies himself to the network by means of a password (sometimes
called the Network User Identity, NUI). This is, in turn, checked by
the network management software to find the corresponding NUA of the
user. Because the NUA does not identify a particular line or location,
security may be compromised if a password is discovered by other people.
Use of the following facilities can decrease the vulnerability of the
PSS to attack:
o All authorised users can be included in a Closed User Group (CUG).
In effect, this creates a private network not available to
unauthorised parties. However this advantage may be compromised if the
CUG includes the NUAs of dial-up users who are authenticated only by
passwords.
o The caller's Network User Address (NUA) provided by PSS can be
checked by the host against a list of authorised callers.
3.4.4 Local area netvorks
Access to computers and computer-to-computer communications via LANs
may present a substantial risk to security. Most LANs are implemented
using a shared transmission medium which broadcasts all the signals to
most or all of the attached nodes. Some LANs support Closed User
Groups (CUGs) in a manner analogous to the PSS and so may also provide
some call origination information. The relative ease of user access to
LAN control software and hardware makes dependence on the security of
any of these facilities unwise. The situation is especially aggravated
where LANs are connected by gateways to one another, the PSS, or to
the PSTN. In each case the risk of unauthorised access is increased
enormously. See earlier CSM Policies in this section regarding the
interconnection of networks. Data on LANs are generally regarded as
being at risk because:
o Most LANs are designed around a shared communications facility which
generally broadcasts signals to all of the attached nodes, security
being dependent on access points ignoring messages not specifically
addressed to them.
O LANs are frequently used as the carriers of Office Automation
facilities in the office environment where system security was not
necessarily a prime consideration in the original choice of the
accommodation.
O LAN signalling sometimes extends into the radio frequency spectrum
and, if electromagnetic signals are emitted from the cabling, LAN
traffic can be intercepted (see also TEMPESI) .
Strong methods of user authentication must be implemented if privacy
marked information is transmitted over the LAN so special precautions
may need to be applied to LANs in order to enhance their operational
security. Three particular types of LAN are defined below:
3.4.4.1 Exclusive LANs
An Exclusive LAN is one where its security depends on:
o its use being restricted to only those users who have an operational
need to use it
o its access points being within BT secure premises
o its not being connected to another network - public or private.
If the LAN spans several buildings, the links between those premises
should be secured by encryption.
3.4.4.2 Access-controlled LANs
An Access-controlled LAN is one which incorporates special precautions
to restrict access between users and resources. All resources
accessible from equipment under a user's control, for example a dumb
terminal, PC or workstation are protected by strong authentication
mechanism. Strong authentication is an authentication mechanism that
is resilient to eavesdropping and masquerade attacks in the context of
the communications network between user and system.
Authentication of connections to LAN nodes may be implemented using
systems based on Kerberos. (Further advice may be obtained from D&P
Data Security Laboratories, see Section 11).
Where there may be a number of separate LAN segments interconnected by
bridges or gateways, each individual LAN segment must comply with the
access control policy.
3.4.4.3 Ordinary LANs
An Ordinary LAN is one which does not meet the security criteria for
an Exclusive or an Access-controlled LAN.
3.4.4.4 LAN Usage
In general the following applies:
LAN Type Usage
Exclusive In Strictest Confidence
Access Controlled In Confidence
Ordinary Non-Privacy marked
Note that use of a specific LAN architecture does not negate the use
of other mandatory features which may be required for handling
sensitive information.
The security of a LAN is a complex issue, especially when the
mechanisms for processing, storing, or transmitting sensitive
information do not all offer the same level of security. In this case
contact the Commercial Security Unit for further guidance.
POLICY 3.13: LOCAL AREA NETWORKS
A LAN shall be characterised as one of Exclusive, Access Controlled,
or Ordinary so that the owners, administrators, and users, are aware
of the security controls that must be enforced.
3.5 Threats to networked systems
Four major threats exist to networked systems:
1 Disclosure of information stored or in transit on the network.
2 Masquerading as an authorised user.
3 Accidental or unauthorised modification, insertion or deletion of
the information stored or in transit on the network, and
4 Denial of the use of the network to those entitled to use it.
3.5.1 Information disclosure
Much sensitive information (access information as well as user data)
can be gained from illicit interception of telecommunications signals
by tapping and bugging. These activities are usually committed against
local lines rather than the main network. This is because local plant
is more accessible to illicit interception and there is little or no
confusion from other multiplexed signals.
All forms of radio, microwave, infrared and other beam transmission
techniques are also vulnerable to interception.
Four classes of countermeasures may be brought to bear to reduce the
risk of information disclosure. These are:
o Data separation,
o Physical protection,
o TEMPEST protection, and
o Cryptographic protection.
3.5.1.1 Data sparation
Depending on the architecture of the chosen network, information of
varying sensitivity may be in transit simultaneously across a single
channel. Under these circumstances, there needs to be a clear
distinction between the level of sensitivity of information. This can
be achieved by either:
o commencing a new single-level communications session each time there
is a change to the level of data sensitivity, or
o Labelling each item of data with its sensitivity in such a way that
the protocol used on the multi-level channel provides clear indication
of the sensitivity, and facilitates unambiguous pairing between the
label and the associated data received or sent.
In either circumstance, the communication channel should be secured to
handle the most sensitive information that it is expected to carry.
3.5.1.2 Physical protection
Because any network may be vulnerable to eavesdropping, special care
must be taken when transmitting highly sensitive information.
Many networks are located in buildings that are considerably less
secure than purpose-built computer centres. When planning the
installation of the network, the guidelines and suggestions detailed
in the section on Electronic Systems Installations should be followed
as far as possible.
On these occasions, where it is operationally necessary to install
networks in insecure buildings, including those to which members of
the public have access, the following additional points must be
considered:
o cabling should be continuous and not be routed through areas where
public access is permitted. If this is not possible it should be
contained in heavy duty grounded metal conduit preferably requiring a
specialised tool to remove the inspection plates.
o where sensitive information is likely to be transmitted on a
network, consideration should be given to using protected cable.
o where sensitive information is transmitted, consideration should be
given to housing termination points, ie. wall mounted coaxial sockets,
in proprietary lockable metal boxes. These must be kept locked at all
times when authorised staff are not present.
o after the installation of cabling, particularly when completed by
outside contractors and in a building not dedicated to BT use, the
routing of the cable must be thoroughly inspected to ensure that it
meets the original specification and that it has not been routed to
locations which could be used by potential eavesdroppers.
o the power switches of network connected terminals should be fitted with
proprietary lockable boxes (which are kept locked!) .
POLICY 3.21: NETWORK MONlTORING
The use of network monitoring equipment must be strictly controlled.
3.5.1.3 Tempest protection
Communications lines, personal computers, Visual Display Units (VDUs)
and printers may radiate significant amounts of radio frequency energy
and it is possible for data displayed on a screen or being printed to
be intercepted. TEMPEST is the name of the technology that enables
this unintentional radio emission to be reduced to acceptable
proportions. In practice the signals can only be received over a short
distance and identifying one particular VDU/printer among several
others is difficult. Although the threat may be real in some military
situations, for the commercial world it must be considered a threat
only when the information being handled is extremely sensitive.
For specialist advice on the applicability and methods of TEMPEST
protection, refer to Section 10.
3.5.1.4 Cryptographic protection
The use of cryptographic techniques is not limited in its application
to the protection of communications networks. This topic is covered in
the Cyptographic Protection section.
3.5.2 Unauthorised access
Connection requests across a network should be verified as to their
authenticity. The chosen authentication mechanism should not place
undue or unwarranted trust on the network to carry the authentication
information accurately or in secrecy unless it has been proved able to
carry out that function. Care should be taken to ensure that the
chosen mechanisms for user authentication are sufficiently strong and
that they are managed correctly.
It is important to realise that user authentication information is
carried across the network and should be appropriately protected, that
is, with the same rigour as that afforded to the information that it
protects. If cryptographic methods are used to facilitate access
control, then the algorithm, configuration and key management must be
approved by the Director of Security and Investigation. Where
cryptographic keys are shared, a method of personal authentication
should be used in addition.
If a strong method of authentication (eg. a one time password) is
used, then this may be adequate as the sole means of authentication.
Otherwise, in addition to personal authentication, authentication of
the recipient's point of entry to the communications network is
required. To be acceptable this must reliably identify the recipient
as being at a fixed physical location. This location must be
authenticated as one at which the recipient may receive the
information. Suitable methods are dependent on the type of connection
and are as follows:
o PRIVATE CIRCUIT - The recipient should be connected via a private
circuit to a fixed location.
o PUBLIC DATA NETWORK - The recipient should be at an authorised fixed
address which is verified by the originator, or should be a member of
an authorised CUG, or authenticated by a one-time password system in
the network.
o PUBLIC SWITCHED TELEPHONE NETWORK- The recipient should be at an
authorised fixed address which is verified by the originator by
dialling-out or by a dialback device approved by the Director of
Security and Investigation.
o INTEGRATED DIGITAL ACCESS - The recipient should be at an authorised
address which is verified by the originator by dialling-out or by
checking the Calling Line Identification.
o LOCALAREA NETWORKS - The recipient should be at an authorised port
on an access-controlled LAN, or at any port on an exclusive LAN.
o OTHER DATA NETWORKS - The recipient should be at an authorised port
on a BT-only data network which does not use broadcast transmission.
POLICY 3.14: NETWORK ORIGIN AUTHENTICATION
The identity of network users shall be authenticated. Where the method
of authentication is weak, strong technical methods shall be employed
to determine the point of access of the originator into the network.
3.5.2.1 Dialback
The security of dial in access may be enhanced by providing an
'Automatic Dialback' facility whereby the caller is forced, at the
outset of a call, to declare his identity to the system. The equipment
terminates the call and dials the caller on a different outgoing-only
line using a telephone number it associates with the caller's declared
identity. This prevents access from arbitrary telephone locations and
offers an audit and accountability mechanism.
Some types of dialback device may be defeated by quite simple
techniques, and therefore do not give the intended protection. Only
the system administrator should be able to modify the list of
authorised telephone numbers stored in the dialback equipment.
Dialback systems used to protect BT's commercially sensitive
information must be approved by the Director of Security and
Investigation.
In some systems manual dialback may be appropriate, however, whether
dialback is automatic or manual, a full log of each access should be
maintained. Because Dialback units only provide authentication of the
point of entry into the Public Switched Telephone Network (PSTN),
other measures should be taken for High Impact Systems.
Dialback techniques can be rendered ineffective if the exchange offers
a Call Diversion facility.
POLICY 3.15: DIALBACK
Where the method of network user authentication is weak, the point of
access into the network shall be established using a dialback unit
that has been approved by the Director of Security and Investigation.
3.5.3 Modification, insertion and deletion
Special measures may need to be taken to ensure that information is
not lost or corrupted in transit across a network. For example,
message sequence numbers can be used to detect the accidental or
deliberate deletion or insertion of entire blocks of information in
the information stream.
Accidental modification of the information in transit can be detected
by the use ofcomparatively simple techniques, for example checksums or
Cyclic Redundancy Checks (CRCs). Where it is anticipated that
deliberate attempts will be made to modify information then
cryptographic techniques may be appropriate.
Cryptographic techniques may be used to prove:
o that data has not been modified,
o the identity of the originator of information,
o that information has been delivered to its intended destination, and
o the source of information into a network.
Note that the adoption of cryptographic techniques for one purpose may
offer the opportunity of other checks. For example, the adoption of
Digital Signatures will provide a facility to enable the detection of
accidental or deliberate modification of information. Cryptographic
techniques are technically difficult to design and implement such that
their use and management is not prone to errors and subsequent
security failures. Because of this, the use of any such equipment must
have the approval of the Director of Security and Investigation.
POLICY 3.16: DIGITAL SIGNATURES
In the design of systems where proof of origin of a message must be
ascertained, Digital Signature techniques shall be considered and
documented.
POLICY3.17: NON REPUDIATION SERVICES
In the design of systems where it is necessary to prove that the
intended recipient has received information, cryptographic techniques
to manufacture an incontrovertible receipt note shall be considered
and documented.
POLICY 3.18: DATA ORIGIN AUTHENTICATION
In the design of systems where there is a requirement to prove the
identity of the origin of data then cryptographic techniques shall be
considered and documented.
3.5.4 Denial or failure of service
In the office environment there is generally no need to provide
fallback communication systems as the standa
rd response time for fault
correction is adequate for most requirements. However, for systems
which use private circuits or the PSS as the prime means of
communication, it is worth considering using PSTN as a fallback for
nonsensitive data provided that the PSTN connection is not made
permanent.
At purpose-built computer centres the situation is somewhat different
as most systems would become useless in the event of loss of their
communications links. Some link redundancy is generally necessary to
protect against this. Communication links that are provisioned as
backup should if possible, be terminated on different hardware in the
system and routed via different cable ducts and transmission routes so
as to minimise the danger of loss of both links in the event of a
hardware failure.
POLICY 3.19: NETWORK AVAILABILITY
In the design of systems, measures shall be taken to ensure that the
availability of the network satisfies the system's requirement.
3.6 Cryptographic protection
Modern encryption techniques are regarded as offering a formidable
barrier to any adversary and probably an insurmountable barrier unless
substantial computing power is available or the key and algorithm are
compromised.
The use of cryptographic techniques can contribute significantly to
security by offering strong mechanisms to:
o authenticate the user,
o authenticate the calling location,
o assure message integrity,
o maintain the confidentiality of messages.
The use of encryption is not without operational problems some of
which are listed below:
o encryption packages inevitably involve an overhead in terms of key
management and administration although, in some public key systems,
this overhead is reduced.
o serious problems can arise if individuals forget their keys or
become indisposed etc. As a precaution, it may be prudent to keep
duplicate cryptographic keys or copies of the files in unencrypted
form. Any such duplicates must be kept securely.
o encrypted information may contain control characters which make it a
prerequisite that any protocol used to transmit a file electronically
is completely transparent to the file contents. It is likely that
encrypted data would interfere with many network operating systems. As
a result either considerable tailoring of a system or specially
developed encryption packages would be required to enable encrypted
data to be transmitted.
o some encryption systems are not suitable for every type of network
so expert advice must be sought.
Encryption systems used to protect BT's commercially sensitive
information must be approved by the Director of Security and
Investigation.
POLICY 3.20: APPROVAL OF USE OF CRYPTOGRAPHY
Any cryptographic techniques or encryption systems selected to
safeguard BT information shall have been approved by the Director of
Security and Investigation prior to their use.
3.7 Electronic Mail Systems
There are considerable risks associated with current electronic mail
systems. In particular, data may be forged, altered, redirected or
intercepted. Although techniques are being developed to solve many of
these problems, users of electronic mail systems should be aware of
their present limitations. The advice given here is for guidance and
is intended to highlight areas of concern. In the future specific
policies will be produced to cover electronic mail security.
Authentication
Currently, most systems authenticate users by means of User IDs and
passwords. This is not a strong means of authenticating users.
Electronic mail systems should not be used as a means of providing
authorisation to other individuals for carrying out tasks unless they
have been specified, designed and installed for that purpose. For
example, it should not be possible to requisition goods on the basis
of an uncorroborated electronic mail message. At present, in the UK, a
handwritten signature is a legally-binding proof of authorisation.
Electronic mail systems using weak authentication do not offer the
required level of proof and assurance of the origination of a message.
Designers of electronic mail systems should look at
currently-available technologies which offer scope for proof of
origination.
Integrity
Without appropriate coding techniques, messages may easily be
intercepted and modified or replayed. Designers of systems should
ensure that the threats are understood and that appropriate
countermeasures are adopted. Digital signatures can be used very
effectively to ensure the integrity and authenticity of a message.
Labelling
Labelling is a way of attaching a marker to a message, file or segment
of data, to indicate a specific attribute. Often the attribute is the
sensitivity of the information. Systems which make use of labels are
able to utilise sophisticated access methods for permitting access to
data An example might be a system which permitting IN CONFIDENCE
material to be redirected to a colleague for action, perhaps because
of holiday arrangements, but which did not permit STAFF IN CONFIDENCE
material to be so directed.
Mail redirection
Automatic electronic mail redirection should not be used unless it is
possible for the message originator to know that message redirection
is in operation.
Account usage
Where it is operationally necessary for another person to use an
electronic mail account for a short time, it is imperative that a hand
over is arranged in a manner which ensures:
o that any password is only known by one person
o that the time period during which the account is temporarily managed by the
other person is documented and recorded by the system manager.
The system manager is the only person authorised to make and record
such a change, and must ensure that the required written authorisation
is signed by the user.
Electronic systems installations
Contents
4.1 Introduction . . . . . . . . . . . . . . . . . . 4-2
4.2 Accommodation. . . . . . . . . . . . . . . . . . 4-2
4.2.1 Natural disasters. . . . . . . . . . . . . . . . 4-2
4.2.2 Civil unrest . . . . . . . . . . . . . . . . . . 4-2
4.2.3 Neighbouring accommodation . . . . . . . . . . . 4-3
4.2.4 Fire . . . . . . . . . . . . . . . . . . . . . . 4-3
4.3 Services . . . . . . . . . . . . . . . . . . . . 4_4
4.3.1 Electrical power . . . . . . . . . . . . . . . . 4-4
4.3.2 Maintenance of local environments. . . . . . . . 4-5
4.4 Electronic system equipment sign posting . . . . 4-5
4.5 Physical access conol strategy . . . . . . . . . 4-5
4.5.1 Access to secure areas . . . . . . . . . . . . . 4-6
4.5.2 Data cabinets and safes. . . . . . . . . . . . . 4-6
4.6 Personnel access . . . . . . . . . . . . . . . . 4-7
4.6.1 Staff, official visitors and other personnel . . 4-7
4.6.2 'General interest' visits. . . . . . . . . . . . 4-7
4.7 System or master consoles. . . . . . . . . . . . 4-8
4.8 Other terminals. . . . . . . . . . . . . . . . . 4-9
4.9 Communications rooms and equipment . . . . . . . 4-9
4.10 Media libraries and disaster stores. . . . . . . 4-9
4.1 Introduction
Security of significant computer or network installations concerns not
only the security of the computer and electronic hardware but also the
protection of systems in general, software, user data, media library
facilities, communications networks and the safety and well being of
personnel. These installations need to be protected against the
effects of events such as fire, flood, loss of power, failure of
air-conditioning and ancillary plant and damage by natural or man-made
hazards. This chapter should be read in conjunction with the Physical
Security Handbook.
4.2 Accommodation
During the planning of an electronic installation due consideration
must be given to both the location of the building that will house the
equipment and the placement of the equipment within the building as
this has a direct effect on the overall security requirements. The
following factors must be considered when selecting installation
sites:
o natural disasters,
o civil unrest,
o neighbouring accommodation,
o fire.
4.2.1 Natural disasters
Certain natural disasters could either severely damage the
installation directly, or prevent its operation by unavailability of
staff.
These include:
o Local flooding including fracture of air conditioning or water
cooling equipment.
o Local landslide, subsidence and so on,
o exceptional weather conditions.
4.2.2 Civil unrest
Electronic system installations might be popular targets for attack by
politically motivated groups and individuals as well as by mobs. It is
undesirable that an electronic system site should be in a vicinity
with:
o unusually high risk of mob violence,
o unusually high incidence of criminal and malicious damage,
o unusually high risk terrorist activity.
If such a site is unavoidable, additional levels of physical security
may be appropriate.
4.2.3 Neighbouring accommodation
Even if the areas housing the electronic system equipment are well
designed, there could be possible hazards from incompatible
neighbouring accommodation both internal and external to the equipment
such as:
o staff restaurants, fuel storage areas (risk of fire),
o washrooms, piped water facilities and tanks (risk of flood),
o electrical generator rooms, railways, radio and radar transmitting
stations (risk of vibration and electromagnetic interference).
POLICY 4.1: SlTlNG OF ELECTRONIC SYSTEMS
The physical siting and location of an electronic system shall be
planned with due regard to security considerations from the inception
of the planning process. The effects of natural disasters, civil
unrest and threats from incompatible neighbouring accommodation shall
be taken into consideration when planning purpose-built electronic
system installations.
4.2.4 Fire
Fire remains one of the most serious of all security hazards
especially in data preparation and media library areas where large
quantities of combustible material are present and electronic
equipment is often allowed to run unattended. Detailed advice on fire
precautions must be sought from local fire safety experts but the main
considerations are:
o limitation of whole-building fire risk,
o limitation of fire risk in main computer and electronic system room,
o limitation of fire risk in data preparation areas.
The necessary preventative measures include:
o partitioning of the installation into fire compartments,
o use of fire-retardant construction materials,
automatic fire detection equipment,
o automatic fire alarm systems (may be linked directly to local fire
station),
o automatic fire suppression equipment (especially Halon gas or
similar systems in the main computer and electronic system room. The
traditional view is that sprinklers are inappropriate here because of
the affect of water on the electronic hardware. Halon has
environmental and safety problems so expert advice must be sought.),
o manual fire fighting equipment, and
o enforcement of fire safety procedures (such as no smoking areas) .
For specific guidance you should refer to Chapter 10 for the BT Fire
Safety Manager in the BT Safety Unit.
POLICY 4.2: FIRE THREATS
The threat and impact of fire shall be taken into consideration when
planning dedicated electronic systems installations.
4.3 Services
The security of services and especially electric light and power
should be considered where appropriate during the siting of electronic
system installations. Provisions may need to be made to cater for a
growth in requirements.
4.3.1 Electrical power
Standby power sources should be available for all systems where
availability has been identified as important. Any emergency power
supplies should provide no-break protection otherwise data will be
corrupted during switching. It should be tested regularly and there
should be sufficient fuel available. When the power load of a unit is
extended, checks should be carried out to ensure the power of the
standby source is sufficient.
Standby power should be invoked not only in the event of total
disruption of primary power, but also at any time that primary power
falls outside (above or below) the equipment manufacturer's
specification. Standby power should also be available to ensure
continued operation of all security monitoring and access control
devices. The provision of adequate monitoring facilities should enable
switch over to occur before the equipment manufacturer's specification
is exceeded.
POLICY 4.3: EMERGENCY POWER SUPPLY
Electronic systems shall be safeguarded from the threat of disrupted
electric power by the provision of standby power facilities where
appropriate.
Power supplies used for systems containing high-sensitivity or
high-availability applications and data must be monitored periodically
to ensure sufficient quality of power for the safe and reliable
operation of these systems. Computer systems are extremely sensitive
to the quality of power delivered. Good grounding, "clean" isolated
power (no transient voltage spikes, brownouts, sags, intermittent
losses) and reliable connections and cabling are essential.
Preferably, these should be verified prior to the installation of a
system. For all applicable systems, the power conditions should be
measured at the point where power is applied to the system cabinets or
boxes. Periodic checks should be supplemented by checks done when
known power conditions change due to modifications in electrical
supply or load.
Power distribution panels, cabinets and rooms must be considered
sensitive areas and protected appropriately.
4.3.2 Maintenance of local environments
For electronic systems requiring a controlled environment (temperature
and humidity) main and standby air conditioning facilities should also
be provided. Any vents to the outside should also be physically
secured to prevent intruders.
POLICY 4.4: MAINTENANCE OF LOCAL ENVIRONMENT
The threat of electronic systems operating outside of their specified
temperature and humidity ranges shall be minimised by provision of
adequate equipment
4.4 Electronic system equipment sign posting
The location of electronic system equipment within a building, for
example connection points, communications frames, has a direct effect
on the overall security arrangements and must be considered carefully.
Ideally, computer and electronic systems should be located above
ground level, but below the top floor and away from exterior windows.
It is preferable that the installation should be windowless and with
no equipment visible from outside the building. Windows not only
represent a security hazard but also can have an adverse effect on
environmental controls. All external signposts of the facility or
obvious displays should be minimised.
POLICY 4.5: SIGN POSTING OF ELECTRONIC SYSTEMS
Buildings housing electronic systems shall not be obviously marked or
signposted.
4.5 Physical access control strategy
General site security is never a substitute for control of direct
access to the electronic system installation, which must always be a
secure area in its own right.
Physical security is enhanced by enforcing several layers of defence,
often called 'Defence in depth'. Access to the site should be
controlled through a manned station which, in turn, regulates entry to
buildings specifically those housing important electronic systems.
Further access controls can then be enforced at the entrance to the
general computing area, and again at the doors to rooms containing the
computer and electronic systems, communications plant and media
library.
In summary, access to the actual computing and electronic system
facility must not be possible except
o past a manned station, or
o through locked doors requiring speciat keys or codes to open.
To ensure compliance with a system security policy it may be a
requirement that sensitive systems are separated physically as well as
logically.
For more specific advice and guidance, refer to the Physical Securiy
Handbook.
POLICY 4.6: PHYSICAL ACCESS CONTROLS
In the design of systems, physical access controls shall be
implemented so as to prevent unauthorised access to sensitive areas.
Small installations which cannot economically justify a manned station
but use access control methods shall record the issue and receipt of
keys, and, where oractical, their use.
POLICY 4.7: SECURITY OF UNATTENDED BUILDING
Sensitive installations in unattended buildings should be physically
secure and alarmed through to an alarm monitoring station.
POLICY 4.8: PHYSICAL SECURlTY HANDBOOK
In the planning of accommodation and siting of electronic systems
attention shall be paid to the recommendations and guidance documented
in the Physical Security Handbook.
4.5.1 Access to secure areas
Subject to fire regulations, there should be a minimum number of
physical access points to the secure area housing the electronic
system installation, preferably one usual portal and one emergency
exit, the latter opening outwards only from the installation.
Even if authorised staff are present in the vicinity of computer and
electronicsystems, all routes of entry should normally be locked; the
use of self-closing and self-locking doors is recommended.
4.5.2 Data cabinets and safes
In addition to the access controls, physical protection for the data
itself must be provided. A Data Cabinet or Data Safe is used to
protect magnetic media against hazards such as Fire, Dust, Pilferage,
Accidental or Malicious damage and the effects of water from
sprinklers. Where the information recorded on the magnetic media
warrants a higher level of physical security, the Data Cabinet or Safe
should be kept in a Strongroom or a proprietary Security Safe.
IN CONFIDENCE and encrypted IN STRICTEST CONFIDENCE marked media may
be stored in Data Cabinets, provided correct procedures are in force
for the control of the data cabinet keys or combination locks.
Unencrypted IN STRICTEST CONFIDENCE marked media may also be stored
on an occasional basis. For regular storage of small quantities of IN
CONFIDENCE or unencrypted IN STRICTEST CONFIDENCE marked media, a data
insert for filing cabinets is available which may be used to store
such media in approved security furniture.
For further advice, refer to the Information Security Code.
There are standing arrangements for the purchase of Data Safes; refer
to Chapter 10 for further information.
4.6 Personnel access
4.6.1 Staff, official visitors and other personnel
Access to sensitive computer and electronic system installations
should be allowed only to those with a genuine need to perforrn their
duties. Other personnel (maintenance engineers, cleaners) must conform
with a formal logging procedure for entry. They should be accompanied
at all times. A visitor remains the responsibility of the host for the
duration of the visit.
All personnel, including visitors and non-BT staff such as cleaners
and maintenance engineers, must be issued with passcards. The style of
the passcards should be such that the bearer can be identified as
regular staff or a visitor, as such, the passcard must be displayed
clearly at all times whilst within the building.
Special consideration should be given to controlling the access of
ancillary personnel such as cleaners and service engineers (BT and
non-B. Temporary changes such as building work or accommodation moves
must not be used to justify a relaxation in procedures. Special
arrangements should be made to accommodate these.
POLICY 4.9: PERSONNEL IN SENSITIVE AREAS
Only authorised people shall have access to sensitive areas.
Procedures shall be in place and maintained to control the access of
external maintenance engineers or other personnel.
POLICY 4.10: MANAGEMENT AND USE OF PASSCARDS
Passcards shall be issued and worn at all times. Their style shall be
such as to enable a clear distinction between regular staff, BT and
non-BT visitors.
For specific advice and guidance, the Information Security Code applies.
4.6.2 'General interest' visits
Although BT wishes to maintain good relations with the community,
general visitors are not permitted into operational computer centres.
Visits to associated premises may be permitted but should not be
actively encouraged. Any request for a visit should be considered on
its merits by local management.
When a visit is arranged, the following measures must be taken to
minimise the risk:
1 Formal entry and exit procedures must be scrupulously followed.
2 Visitors must be issued with passcards.
3 Parties must be organised so that they are of manageable size so as
to ensure that all visitors are accompanied and supervised at all
times. A ratio of five visitors to each BT guide one of whom must be
at least a level 2 manager (MPG4), is suggested.
4 The route and timetable must be preplanned and strictly followed so
as to avoid all sensitive areas.
5 Areas of work which are demonstrated must be selected to avoid close
up viewing of sensitive information (such as logging on procedures,
network access numbers and customer data) .
6 Staff must be given adequate warning of impending visits so that
sensitive material and access methods can be concealed.
7 Passwords must be changed after any such visit if it is considered
that any have been compromised.
8 Any handouts must have been authorised by the local manager in
accordance with the Information Security Code.
9 The carrying by visitors of cameras and electronic devices capable
of interference with computer systems must be prohibited.
POLICY 4.11: GENERAL INTEREST VISlTS
Local rules governing visitors and visits shall be documented.
Visitors shall be guided so as to exclude them from all sensitive
areas. Refer to the Physical Security Handbook for guidance.
4.7 System or master consoles
Controls against unauthorised activity are essential on electronic
access to computer and electronic system facilities, in particular
over communications links but also to computer and electronic system
consoles. System or master consoles usually provide access to highly
privileged activities, for example system administration and software
or machine maintenance; others may provide enhanced operator
privileges necessary for efficient machine usage.
Master consoles must be located in the most physically secure
environment available within the computer and electronic system
building complex to prevent unauthorised use of the console. The
consoles must be sited so that use may not be overlooked and cabled so
that their traffic cannot be intercepted.
Access to master consoles must be restricted and all operations
recorded. The log or journal should be regularly scrutinised to
identify any signs of irregular or unauthorised usage.
POLICY 4.12: USE OF SYSTEM CONSOLES
Procedures concerning the proper use of primary system consoles or
system terminals shall be documented and the application of those
procedures enforced.
4.8 Other terminals
Terminals outside the computer and electronic system room should not
have access to operator or other special privileges. Other users which
might need access to privileged commands might include software
support groups, network management groups and remote software
engineers. If privileged access is required, and the temporary use of
a terminal other than the primary or system console cannot be avoided,
its use should be strictly controlled, supervised and, in some
circumstances, audited.
Terminals located in non-BT buildings deserve special attention to
ensure that their use cannot compromise the security of BT systems to
which they may be connected.
4.9 Communications rooms and equipment
All communications equipment must be sited in a physically secure
environment within the installation and must be subject to their own
restricted access controls. Where it is not possible to locate
communications equipment within dedicated accommodation then the
equipment itself should be physically secured in purpose built
lockable furniture.
Cable entry points, risers and runs shall be provided with adequate
protection to prevent unauthorised access, and accidental or
deliberate damage.
POLICY 4.13: COMMUNICATIONS EQUIPMENT PHYSICAL SECURITY
Communications equipment shall be located in its own secure
environment or in secure furniture and subject to restricted access
control appropriate to the sensitivity of the data being communicated.
4.10 Media libraries and disaster stores
Special care must be taken to safeguard media libraries and disaster
stores. Data held in a compact form is particularly vulnerable to
accidental or malicious damage and its security depends on physical
protective measures, access control and staff reliability.
Both the media library and the disaster store must be restricted to
specifically authorised staff.
The disaster store must be sited so that it will be unaffected by any
incident at the computer centre. It must also be sited so that the
contents are not affected by strong electromagnetic influences. See
the Physical Security Handbook for further guidance.
POLICY 4.14: DISASTER STORE
Any disaster store shall be physically protected and remote from the
computer centre. Access to the store shall be governed by local
operational instructions.
+++
EOF
