============================================================================= 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