2029 lines
88 KiB
Plaintext
2029 lines
88 KiB
Plaintext
=============================================================================
|
|
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 standard 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
|