It is a security objective that software and data are correct complete and available to authorised users. Full use should be made of the security features provided by the operating system to achieve this objective. If software needs to be written, security and audit requirements should be considered at the system design stage. Users must ensure that the Statement of Requirements document contains a definition of security requirements and access restrictions.
All software modifications to a computer system must be authorised and fully recorded. The modification log should be held by the system administrator. Emergency patches (those that are not scheduled) must be properly documented and reviewed by the appropriate authority within one working day.
Checks should be implemented to ensure that only one change is carried out at a time. If development pressure compels the packaging of changes in order to minimise the system testing overheads, the checking must be even more vigilant.
Expert personnel should check all new and modified software for correctness and completeness with special regard to the possibility of security flaws. It should also be verified to ensure that it functions according to design, that it does not adversely affect other functions in the system and that no unauthorised changes have been made to the system. These checks should be conducted on an off-line system and not on operational machines.
Verification should be performed after all software changes and on a regular basis.
While full verification testing of the type outlined above is not always possible due to operational constraints, use of unverified software provided by a third party represents an unknown quantity from a security viewpoint, especially in cases where the source code is not available. In any case assurances must be obtained from the supplier about the integrity of the software and especially about the removal of undeclared commands incorporated for debugging purposes.
It is preferable that user software should be written in a high level language. Only compiled programs should be released. Source code should only be available to the programmer creating or amending the program or for the verification of the validity of any changes; this applies equally to operational Job Control Language text. Job Control Language which cannot be compiled should be held in a discrete library store with controlled access.
Ideally the software development cycle should involve a separation of Development, Test and Production environments. These three areas often have quite different security requirements. As far as technical restraints and costs permit, they should be isolated from each other. Technical and procedural
controls should be applied to the promotion of software from Development to Test and from Test to Production environments. Special care should be taken to protect the integrity of code accepted into Production use.
Software shall be subject to version control to ensure that only current and approved software is in use on an electronic system.
Live data shall not be used in system testing. Test data derived from, and traceable to, live data shall be afforded a similar level of protection to the original source.
Unless a trustworthy method has been used to create and distribute software then the integrity of the software shall be considered to be unknown and shall not be used on BT systems.
Software that can be used to modify existing programs on systems (such as editors and compilers) shall be restricted in their use to authorised staff. Any such software that is not needed for operational reasons shall be removed.
Emergency access to Production systems, using powerful utilities, for the purpose of data repair shall be subject to rigorous change control and every access of this nature must be recorded.
The Copyright, Designs and Patents Act 1988 expressly accords computer programs the same copyright protection as written documentation. When BT owns the copyright in a computer program because it was written in-house or under a contract assigning copyright to BT, it is BT policy to mark the program appropriately. Details on how to mark information are contained within the Information Security Code.
All software written in BT, or written for BT under a contract which provides for ownership of copyright by BT, shall be clearly marked so as to identify BT as the owner of copyright in such software.
Copyright law restrictions prohibiting the unauthorised copying, modification or unlicensed use of software and software documentation, in which the copyright is not owned by BT, shall be respected at all times.
Unless BT has been granted an appropriate licence by the copyright owner, software and software documentation in which the copyright is owned by anyone other than BT, must not be copied, modified or used in BT. Where BT has a licence, the terms of the licence, including any limitations on copying, modifying or using such software and software documentation must be complied with at all times. Copyright markings applied by the copyright owner must not be removed (unless expressly permitted under the licence).
Interruptions to normal working may be caused by such events as fires, hardware, software or environmental failures and malicious damage.
Copies of the current versions of the system software, data, and accompanying documentation shall be safely stored and available so as to enable a quick and controlled recovery in case of a processing interruption.
All abnormal program terminations should be monitored by the system to permit control to be passed to system recovery routines when necessary. Any software failure must be documented and investigated as this may be an indication of a breach in security.
There should also be controls to ensure the validity of the software itself.
The planning of systems shall take into account the need to detect failures of software and hardware and provide recovery features such that the integrity of the data shall not be compromised.
System data is the information used by the operating system and application software to control and monitor access to system resources by users. Logs kept by the system form a large component of system data.
A system log is required to identify users who have invoked transactions so as to assign accountability. The logs should reflect both system performance and user activity and each event on the system log should have an associated reference number and be time-stamped.
It is essential that log hard copy and log software, eg reporting programs for logs held on disk or tape, should be afforded maximum protection from unauthorised modification and should be unaffected by system restarts etc. Hard copy logs should be kept for critical system logs. The pages of a hard copy log should be pre-numbered so that it may readily be checked for completeness.
System activity should be recorded on the log to include matters such as:
Monitoring user activity is especially dependent on the existence of a user activity log and may be regarded as an audit trail for the detection of unauthorised activity and identification of its origination. The user activity log should record such events as the following and include for each record any relevant information such as date, time, physical access point or port, UID, and nature of the attempt:
An audit log of the system activity shall be maintained and regularly reviewed so as to identify abnormal system or user activity. Activity records shall be kept of events on all High Impact Systems, particularly of any activity which might be abnormal. Abnormal activity shall raise an alarm.
While it may be impracticable to scrutinise an entire system log by hand, a regular spot check must be made on random samples of the log and on periods of unusually high logon activity, or access at abnormal hours. Project documentation should give precise instructions regarding the checking of system logs.
The use of a software tool to separate unusual log entries from routine and non-contentious information which would enable a more careful scrutiny to be made, should be considered. Specialist audit packages, data test equipment are examples.
System logs shall be regularly checked so as to detect unauthorised system activity. The use of automated techniques shall be considered.
The automated tools used to analyse the system log files shall be protected and subject to management and control procedures.
The length of the retention period should take into account audit and legal requirements, error recovery and investigation of any unusual occurrences.
Hard copy logs of important system parameters, data modifications, and details pertaining to hardware and software conditions, must be securely maintained by the system administrator. Iis permits a comparison to the system state after events such as software updates, fix or patch insertions and system restarts to verify that no accidental or unauthorised changes have been made. Parameters to be verified include:
A log shall be kept of fault reports by users, and hardware and software maintenance on systems.
All audit and journals of system activity shall be retained or archived for a reasonable amount of time in the event that the information is required for evidential purposes.
Special precautions must be taken to preserve the usefulness of logs as evidence if they are processed onto microfiche. The people responsible for the operation of the process and the subsequent storage must provide clear evidence that there can have been no interference with the logs during the process, or with the subsequent microfiche.
Particularly sensitive files and data such as password listings should be given extra protection by being encrypted by the system. Passwords in particular should be one-way encrypted such that the original data cannot be recovered under any circumstances.
A system backup must be taken by system management personnel at regular intervals, the frequency of which will reflect the importance of the system and the impact of a system failure. The backup data should be stored securely oŁ premises. Current copies of all on-site system images should be kept in approved locked, fire-resistant cabinets.
A definitive copy of important data files must be securely maintained and used by system management to detect unauthorised changes to such things as access control mechanisms, user rights profiles, backup controls and audit mechanisms. Any file amendments must be logged.
Sensitive information shall be backed up by a cycle of copies, devised so that the system can be brought into service after any accidental or deliberate erasure of data.
Systems that perform security functions, or which safeguard commercially sensitive information whereby the failure to protect the confidentiality, integrity, availability of that information would cause:
Data ownership is an essential element in safeguarding BT's commercially sensitive information. The Data Owner is responsible for identifying the value and sensitivity of their data. This decision must be respected by all users and systems. Ownership conveys both responsibility for, and authority to:
It is essential that software and data stored on magnetic or equivalent media should be properly handled, stored and protected so as to ensure the accuracy and completeness of all records. A full set of all software and data must be retained and filed for backup and recovery purposes.
Where possible all storage media should be write-protected prior to shipping and at all times when not active in the system.
Magnetic media should be labelled with a unique identifier and the relevant privacy marking if appropriate. Methods of marking may be:
Media shall be marked to indicate the most sensitive information on the media in accordance with the Information Security Code. Where a medium is shared it should be treated as containing the highest sensitivity level that may be stored upon it.
Data shall be marked in accordance with the Information Security Code.
Systems specifications, program listings, details of test data etc. for systems containing sensitive information must be accorded a similar degree of protection as that of the computer held data. They should be marked with the appropriate privacy marking, locked away when not in use and spare copies held securely either in a fire-resistant safe or at another location.
Magnetic media may be corrupted accidentally simply by being in the wrong location. Most electronic and electrical equipment generates a magnetic field either of a permanent nature or specifically when powered up. Such magnetic fields can both corrupt and erase data stored on disks and tapes.
Floppy disks are much more prone to corruption from magnetic sources than hard disks and it is recommended that when not in use they should be stored away from office electrical equipment such as electronic typewriters, printers, computers or telephones.
Magnetic and optical media holding sensitive information requires precautions to be taken before its reuse or disposal. Media which is damaged may be read easily by sophisticated equipment. Even magnetic media which is overwritten many times using seemingly complex patterns may be read using specialist techniques. Details of the secure destruction facility may be found in chapter 10.
Where media is to leave the boundary of a system, or there is a requirement to change a disk drive, or other vise dispose of media, one of the following rules shall be applied.
Sensitivity level Damaged disks Trade in disks
+3 A A
3 A A
2 D B
1 D B/C
Removable Media
Disposal Disposal Reuse Reuse
Sensitivity level damaged good on same within
media media system BT
+3 A A c x
3 A A C B
2 A C/E C/E B
1 E C/E - -
If in the opinion of the system owner, the cost to BT of destroying media
outweighs the value of the information, the system owner may seek approvel from
DSecI to take alternative action. Also. see chapter 13 of the ISC.
Computer systems which are withdrawn from service pose a serious threat to BT if they are not processed properly before disposal. All systems to be disposed of by BT must have the disk formatted or destroyed according to policy 7.19. No software must reside on the hard disk of any machines which are disposed of, apart from the operating system. Entitlement to these must be documented at the time of the transfer. All master copies of software should be either retained or returned to the local computer administration unit for re-allocation. Managers should note the possible conflict of interest associated with the local scrapping and subsequent sale to BT people. If equipment is to be locally scrapped, the procedure for doing this must be documented and all records must be made available for audit and scrutiny.
No computer equipment containing non-volatile data storage capabilities that has been used for processing IN STRICTEST CONFIDENCE information shall be disposed of as surplus equipment until it has been examined by a person approved by the Director of Security and Investigation to ensure that all sensitive inforrnation has been removed.
IN STRICTEST CONFIDENCE waste must be disposed of under direct BT supervision by burning, shredding using a Director of Security and Investigation approved shredder, or by using a disintegrator.
IN CONFIDENCE waste including personal and other sensitive data must be destroyed by burning, shredding, or disintegration. For large quantities of IN CONFIDENCE material, use can be made of the approved sensitive waste paper collection services.
Sensitive media shall be destroyed in accordance with the Information Security Code.
A computer virus is an element of executable software that can be transferred between programs, or between computers, with or without the knowledge of the users. When triggered by an event determined by the perpetrator of the virus, it can carry out any of a wide range of unauthorised activities. Examples include infecting other programs or the operating system, sending infected messages to other systems, deleting files. Furthermore, these unauthorised events may occur while giving the impression that the computer is functioning normally.
These actions can be malicious or benign, but in any event they breach the integrity of the system. Given BT's dependency on computerised systems for business-critical activities, it is essential that the integrity of such systems is maintained.
Computer systems can be designed with built in capabilities to resist viruses. This may be achieved by erecting logical compartments enforcing strict segregation of the operating system, and the program areas and data areas of each user. Another measure is to prohibit terminals that have media entry capability or can be connected to untrusted networks.
While these restrictions may pary solve the problems for defence systems, they are onerous, impractical and too expensive for most commercial of fice systems, IT systems and network management systems. Because most commercial computer systems are vulnerable to viruses, the primary protection depends mainly on management policy and the active co-operation of the users to ensure that viruses are not introduced into systems. However, many of the working practices that have evolved with the Personal Computers encourage virus propagation. Borrowing or lending disks containing programs or utilities is typical example.
Downloading of software from the public databases and bulletin boards is particularly risky.
A virus does two things. Firstly it has a mechanism to propagate itself For instance the perpetrator of the computer virus may attach it to a commonly run program or routine. Having carried out the legitimate function of the program, the virus takes control and attaches a copy of itself onto other programs that are resident, either directly or by altering the operating system. Thus once a computer has been infected it may infect the programs on any other floppy disk placed in its environment. These in turn may infect any other computer in which the infected disk is placed.
Unless strict precautions are taken, advanced viruses are capable of causing infection to remote computers via networking facilities.
The second feature of the virus is its function. The function can consist of any activity that can be performed by the computer. The virus function can be triggered by any detectable event, eg: a time, a date, execution of a particular routine, receipt of a message, deletion of a file or cancellation of a UID.
In short, a computer virus is self-replicating software used to propagate a Trojan Horse or Logic Bomb.
In the event of discovering a virus the Local Computing Help Desk should be contacted immediately for advice. For most parts of the business, this will be the GCS Help Desk. The suspect machine and disks which have been used on the machine should not be used further until the Help Desk has been contacted. Programs are now becoming available for most popular machines that claim to be able to prevent, detect or eradicate virus infections. These tools may certainly help to detect the presence of viruses. Unfortunately the indeterminate nature of computer viruses makes an absolute guarantee of detection virtually impossible. Nevertheless, virus detection tools should be regarded as a contributory factor in maintaining computer system integrity.
The prevention of virus attack demands a fundamental shift of behavioural pattern on the part of users of micro- and mini-systems. Many of the procedures that have evolved to help and assist colleagues now need to be reconsidered in the context of possible attack by computer viruses. For instance, operating system, program or utility disks must not be borrowed or lent. Manufacturers source disks must be securely protected, not left inside the instruction manual in the open. Transit disks, that is those containing data files, should not be bootable or contain any executable files. Except when being written to at the beginning of the transfer process, the disks should be write- protected.
BT attaches considerable importance to the integrity of its computer systems, particularly those systems that provide applications that are critical to the smooth functioning of the Business. The recent emergence of computer viruses presents a serious threat to BT s computer systems.
It is the personal responsibility of each individual to ensure that viruses are not introduced into any BT system, or customers' system, that they come into contact with.
Detailed procedures on combating virus attacks shall be prepared for the security of systems for which the impact of security failure is high. These policies are to be submitted to Director of Security and Investigations for concurrence.
All disks inserted into customers' PCs must be virus checked before hand, using approved virus detection software, or be certified as being virus free by the manufacturer.
Utilities are available for many popular machines that claim to be able to prevent, detect or eradicate computer viruses. While their rigour and scope is unproven, they may certainly help detect the presence of viruses. Nevertheless, the primary objective is to avoid infection in the first place by means of careful operating procedures.
The following steps should be followed by users to reduce the possibility of any system being infected by computer viruses: