Administration


Contents

8.1 Introduction

This section considers the administrative aspects of computer security. It must be appreciated that all the technical security measures identified in earlier chapters depend on the cooperation of the people who implement and operate the system. It follows that these measures must be supported by appropriate procedural guidelines and suitably informed staff.

Some principles of wide applicability are identified, but their implementation will depend on the size of the operation in question and on local organisation.

8.2 Personnel

8.2.1 Staff instruction, training and responsibilities

All staff using computers and communications equipment should receive instruction on security in general, and staff in particularly responsible positions must be given special training. The observance of security procedures must be supervised on a routine basis.

In particular there should be close supervision of system support staff as they often have unlimited access to all aspects of the system. Training should include information on:

If temporary or casual staff (including agency stafl) are to be employed in areas where they have access to sensitive data, consideration must be given to the risks involved. Specific guidance can be found in the Information Security Code.

All staff must respect copyright in documentation or computer software when that copyright is not owned by BT. They must not copy or modify such material unless BT is permitted to do so. Staff must use such material only as permitted and must not remove any copyright marking applied by a copyright owner.

POLICY 8.1: TRAINING

Managers shall ensure that their staff have received adequate security training or instruction before allowing them to use BT systems.

POLICY 8.2: PERSONNEL CONSIDERATIONS

Employees working on high impact systems shall be trustworthy.

8.2.2 Specific areas of responsibility

Areas of specific security responsibility must be identified for each system. An individual, or where possible, individuals should be designated as responsible for the definition, implementation and review compliance of the relevant security policies and procedures specific to each area.

Particular areas include:

8.2.3 General areas of responsibility

Whether or not responsibilities are divided among a number of individuals, there should always be an individual manager responsible for overall security and with authority over all aspects of a system. In this manual the term 'systems administrator' refers to the person responsible for the day to day administrative operation of a particular system. Where a system shares resources, this term also includes the person responsible for the day to day operation of these resources.

For larger systems an individual should be appointed who should be responsible for all aspects of systems security including the reliable and timely inspection of all system and security logs and for any actions arising, also for monitoring the investigation of breaches of security and liaising with the other security bodies as necessary. The individual must have, or be trained to have, adequate knowledge of computing to be able to handle his responsibilities and should have written instructions on the procedure to be followed in the event of a security failure.

In the case of small systems the above duties may be combined in which case it is the responsibility of the managers concerned to ensure that all information under their control is safeguarded.

POLICY 8.3: SECURITY RESPONSIBILITY

Every system shall have an individual who is responsible for the security of that system.

8.2.4 Separation of duties

The 'need to know' principle must always be applied to security. As far as staffing constraints allow, individual responsibilities should be segregated so that no employee has complete control or performs all aspects of a sensitive process or operation. Individuals should only be permitted access to those resources which are essential to their allotted tasks.

Particular attention must be paid to the following areas:

POLICY 8.4: PRIVILEGE LIMITATION

Authorised users shall be given the minimum level of privileges necessary for them to fulfil their duties. Where necessary, duties shall be separated to prevent collision.

8.2.5 Definion of duties

Detailed written procedures should also be established for the guidance of those responsible for operations, and especially for personnel involved in sensitive activities such as physical access control, system controls, system management and backup and recovery plans. Every project and system should provide detailed instructions to users regarding the security procedures to be followed.

POLICY 8.5: GENERAL SECURITY RESPONSIBILITIES

BT staff shall respect the security markings on BT property and handle it accordingly.

POLICY 8.6: DEFINITION OF DUTES

All jobs having a specific security role must have written job descriptions which fully describe their security responsibilities.

All BT staff shall be personally responsible for, and accountable for, the security of their area of work.

8.2.6 Staff mobility

Where it is known that an individual is leaving BT, unless local management is satisfied that no security risk is involved, they must remove the employee from the computer environment immediately and:

Consideration must be given, especially in cases of disciplinary proceedings leading to dismissal, to deny that individual access to BT premises and information. It is not a requirement that the individual work out his notice. Where an individual is departing a computer related dub but staying on in BT, local management should take the measures detailed above where appropriate to preserve security

POLICY 8.7: STAFF LEAVING BT

Managers shall review the security implications of allowing continued access to BT systems by anyone who is known to be considering leaving the company, or is under notice.

8.2.7 Breaches of security

All breaches of security shall be reported to line management. Known or suspected criminal offences shall be reported immediately to the BT SecID Investigation and Detection Unit (I&DU) Help Desk. In this context, criminal offences will include those misdemeanours criminalised under the Computer Misuse Act 1990:

Note that, because a computer virus propagates itself by means of unauthorised program modification, the introduction of computer viruses into BT may constitute a criminal offence.

POLICY 8.8: REPORTING OF SECURITY INCIDENTS

Security incidents shall be reported to line management. Known or suspected criminal offences shall be reported immediately to the BT SecID Investigation and Detection Unit (I&DU).

8.2.8 Marking

All documentation (including soware and information stored on computer media such as discs) must be marked with the appropriate security marking. It should be subject to the rules set out in the Information Security Code as regards storage, transmission, and destruction. The security marking should be reproduced on all printed output and preserved if copied or transmitted.

8.2.9 Removal of documentation

Administrators shall ensure that no media, data, files, reports or other documentation, should be removed from sensitive computer areas without the specific authorisation of line management in accordance with normal defined practices.

8.2.10 Information provided to outsiders

All release of information to non-BT personnel must be in accordance with the Information Security Code and the Data Protection Act.

When data has to be provided to outsiders for operational rather than service reasons (eg system dumps to equipment or software providers) a written and legally binding agreement should first exist to ensure confidentiality. These agreements should ensure that any information given is only used for the purpose of clearing faults. A record should be kept of all such exchanges of information.

Numerous questionnaires are sent by outside companies to managers within BT. All such requests for information should be forwarded to the relevant Business Information Security Managers (BISMs) for consideration as to whether completion and return is desirable. As a general guide, information about BT's computing activities should not be released unless:

If information is released, care must be taken so that, for example, no advantage to a competitor might accrue. Only a very general indication should be given of hardware configuration, software in use and applications processed. Individuals should only be named if a contact point is required.

8.2.11 Disclosure of customer information

Customer information must not be disclosed unless its release has been approved in accordance with the Information Security Code, the Data Protection Act, and complies as necessary with the operating licence granted to BT.

8.3 Disaster protection

BT is wholly dependent on computing systems for the profitability, continuity, and control of its business. It is thereore vital that the availability and security of these services is not compromised by a major disruption or disaster, such as physical damage to the system hardware or large scale corruption of the system software or data. This requires that business and operational plans and practices are in place to ensure that the risk of disaster is minimised and that systems continue to deliver the agreed levels of service, taking into account risk and cost. The Disaster Protection Unit exists within D&P to set standards and give advice. (See section 10).

A disaster is defined as any circumstance in which one or more critical business computer application(s) is not available to BT for internal or external customer requirements as a result of:

serious or catastrophic loss of, or failure of access to:

non-availability greater than the number of hours determined by business impact review.

This policy provides a high-level statement applicable to all BT Group computing capability. It is compliant with government legislation and with BT's Information Security Code.

Prevention

All buildings which contribute to the delivery of computer-derived services and data must have physical security measures implemented to reduce the risk of a disaster.

BT should provide suitable standards of physical security to reduce the risk of disaster occurring. The prevention measures should be monitored through periodic reviews to determine the level of risk and adequacy of the measures to meet the risks. Where shortfalls in protection are identified, prevention measures should be implemented, taking into account risk and impact.

Recovery

All major BT systems must be assessed to determine the value of the application to the business process and operation, specifically the loss to the company as a result of their unavailability. This business impact review process should assess the costs, tangible and intangible, of an application's unavailability over a period of time to identify the requirements for fallback and the optimum point for recovery.

A recovery options analysis will produce the practical options for those applications deemed to require recovery in the event of a disaster. The recommended option will be chosen, taking into account the cost of recovery and the business requirements of recovery.

New applications must have recovery processes built in during system development, based on user-defined fatlback design requirements. Existing systems should be enhanced to the required level of fallback.

Prevention and contingency plans must be provided for all computer centres and multi-user systems. These will detail the procedures and information aimed at reducing the risk of disaster and to provide contingent procedures that will allow recovery of all applications to a fallback site.

Recovery plans must be provided for each application to detail the management requirements and responsibilities for recovering from a disaster, together with instructions for recovering the critical applications.

The effectiveness of the recovery facilities must be tested through a comprehensive rehearsals programme.

Strategy

Adherence to the policy will be affected by the development, implementation, operation and maintenance of a computing disaster protection strategy. The strategy will be maintained in line with business needs, corporate obligations and technical evolution.

Standards, working level procedures, audits and physical practices will be visible at all levels of management and will demonstrate that the policy is understood and that the strategy is implemented.

The requirements of the policy must be met before the commencement of live operations for all new applications systems.

POLICY 8.9: DISASTER PROTECTION

Owners of the operations of critical and high impact computer systems must ensure that a disaster does not prevent the delivery of the agreed levels of service, taking into account risk and cost.

POLICY 8.10: DISASTER PREVENTION

Facilities which provide BT with critical computer services, or access to those services, shall be protected at all times from exposure to serious or catastrophic loss

POLICY 8.11: DISASTER RECOVERY

Procedures, hardware and software facilities shall be in place at all times to ensure that in the event of disaster, access to critical computer-based information and services will be restored.

POLICY 8.12: DISASTER STORAGE FOR PCs

Disaster storage for personally-controlled systems and data is the responsibility of the owner.

POLICY 8.13: DISASTER RECOVERY RESPONSIBILlTY

The owner of the operation of centrally-controlled systems and data is the custodian of the data and responsible for ensuring recovery is possible if there is a disaster.

POLICY 8.14: DISASTER STORE LOCATION

Storage of critical or sensitive files must be away from the electronic system, in a separate building off-site, as access to the disaster store may be denied.

POLICY 8.15: DISASTER STORE ENVIRONMENT

The security and environmental control must match the requirements of the data being stored and a firesafe used to store data awaiting transfer to the disaster store.

POLICY 8.16: DISASTER STORAGE

Where the storage is of user data or software, it must be with prior knowledge and agreement of the user.

POLICY 8.17: DISASTER MEDIA ACCESS

Procedures must exist to ensure only authorised personnel have access to, or are able to request movement of, a user's backup data.

POLICY 8.18: DISASTER AUDIT

Facilities must exist that enable the user to audit the procedures.


©1995 Cold Fire