Personal computers Contents 5.1 Introduction . . . . . . . . . . . . . . . . . 5-2 5.1.1 Use outside BT premises . . . . . . . . . . . . 5-2 5.2 Personal security responsibility. . . . . . . . 5-3 5.3 PC and data access security . . . . . . . . . . 5-4 5.3.1 Keylocks . . . . . . . . . . . . . . . . . . . 5-4 5.3.2 Password protection . . . . . . . . . . . . . . 5-5 5.3.3 Removable disks and cassettes . . . . . . . . . 5-6 5.3.4 Protection of data in memory. . . . . . . . . . 5-6 5.3.5 Hard copy (printouts) . . . . . . . . . . . . . 5-7 5.4 Security of software. . . . . . . . . . . . . . 5-8 5.5 Personal computer communications. . . . . . . . 5-8 5.5.1 Public network access . . . . . . . . . . . . . 5-8 5.5.2 Use of PC as a computer terminal. . . . . . . . 5-9 5.6 Contingeny planning . . . . . . . . . . . . . . 5-10 5.6.1 Archiving and backup. . . . . . . . . . . . . . 5-10 5.7 Flle Servers. . . . . . . . . . . . . . . . . . 5-12 5.1 Introduction Personal Computers (PCs) are often sited in open plan offices and, as such, are accessible by many people. In general, PCs and their peripherals can be removed more easily than other types of computer. Due to these two facts, PCs are more vulnerable than equipment housed in purpose built accommodation, for example dedicated computer centres, and so require additional provisions for their protection. The following threats are more likely: o the theft of PC or peripherals, o the theft or damage to the information stored on the PC, o accidental or malicious physical damage, and o the possibility of screens displaying sensitive information being overlooked. Some deterrent against theft can be offered by clearly marking equipment with the name and office address of the person responsible for the equipment. The serial numbers of the equipments should also be recorded. PC users should pay careful attention to the environment of the machine: o ensure vents on the PC are not blocked by printout, manuals etc. o eating, drinking and smoking while using a PC can cause damage to the machine and should therefore be avoided. When choosing a site for the machine in an open plan office, ensure that consideration has been given to the confidentiality required for data on the machine. In particular ensure that visitors or people outside a building cannot overlook the screen if sensitive information is displayed. 5.1.1 Use outside BT premises There are dangers in using PCs outside BT premises, for example, on trains or at home. These threats include the increased possibility of theft, the likelihood of onlookers and potential damage by extending access to inexperienced users. An unprotected communications link may also present a security risk. Managers must consider carefully whether the risks involved are justified. POLICY 5.1: USE OF BT COMPUTING EQUIPMENT OUTSIDE BT PREMISES Privacy marked or commercially sensitive information shall not be processed on portable computers anywhere other than BT premises unless the computer or the information stored therein is adequately protected. 5.2 Personal security responsibility Fundamental to good security is control. Control of access and resources can only be achieved by co-ordination. For this reason it is important to distinguish between the person responsible for a personal computer (PC) and those that use it. Although the actual assignment of responsibilities for personal computers is a local management issue, the following issues shall be addressed by the person nominated as responsible for the PC: o Physical security of the PC, o Controlling the access of individuals to the PC, o Ensuring that users are aware of their responsibilities, o Controlling external access to the PC (LANs, PSI N etc), o Backup of software (see contingency planning section), o Maintain a list of the software and hardware, o Co-ordinate maintenance engineers access, o Regular audit of PC hardware and software against licences held. The users of the PC should be made aware of their responsibilities by the person who controls the PC. Authorisation should only be granted if the proposed user accepts the responsibilities in writing. The responsibilities of the users must include: o To use only legitimate authorised and licensed socware from a proven source, o To ensure that no sensitive data is put on the hard disk (unless it is equipped with appropriate protection), o To ensure that they take backups of their data at appropriate intervals, o To read and abide by the guidance of the Computer Security Manual and the Information Security Code. Where the person responsible for the machine is also the user of the machine, the duties of audit and checking outlined above fall upon that individual's line manager or nominated representative. POLICY 5.2: CONTROL OF PERSONAL COMPUTERS Every personal computer shall have a named individual who is responsible for controlling its use. The owner must maintain a list of sensitive data in a secure place, in addition to the list of applications. The degree of compromise should local data be lost must be known. Any user who stores sensitive data on servers used by the PC must never assume that backups are being done. It is incumbent upon the user to verify the server conditions. 5.3 PC and data access security Many PCs are sited in open-plan offices and there may be no particular physical security measures to restrict access to the processor, network features or peripherals. For this reason, care needs to be exercised over the use of the PC and access to the data. The criteria for choosing suitable controls should be the sensitivity of the data processed, and the physical environment (who may have physical access to the PC). To assess the sensitivity of the data it is necessary to consider the effect of a loss of confidentiality (to competitors, to the press, to other employees etc.); the effect of inaccurate data or incomplete data, and the effect if data on the PC were unavailable. The implications of the Data Protection Act and other legislation and regulatory issues should also be considered. The security principles to be borne in mind are: o Need to know, o Need to modify, o Individual responsibility, and o Accountability. To enforce these security principles access to the PC, and more importantly to data must be controlled. It is important to segregate data into compartments so as to ensure that the security principles can be enforced. This can be achieved by use of removable disks, or by encryption of individual files on a hard disk. While it is not always practicable for PCs to be locked in a room if they operated unattended, access to their contents must be restricted. Without adequate protection, the PC, the data it is processing, and networks to which it may be connected are at risk not only from unauthorised access but also accidental or deliberate corruption. An unprotected and unattended PC is vulnerable to being used to run unauthorised software, for example games, which may carry a computer virus. Some security can be achieved by: o provision of key locks to safeguard internal pre-set hardware, o physical locks to prevent use of the floppy disk drive, o hardware-based password protection invoked during the startup procedure, o an add-in hardware assisted access control protection device, o hardware-based data encryption, o removable hard-disks. 5.3.1 Key locks A PC may have a key lock built into it. Some of these locks give a degree of security by disabling the processor power unit. Others may simply disable the screen or keyboard. There is also a (somewhat limited) range of external locks for most PCs. These locks can be fitted over the mains and auxiliary power switches to the processor thus preventing unauthorised operation of the computer and providing safeguards against theft of hard disks, plug-in cards and the system unit. Lockable devices may also be fitted over, or into, the floppy disk unit so guarding against loading of unauthorised software. 5.3.2 Password protection There are numerous proprietary packages available which control access to the PC operating system and disk storage by means of a user ID and password system. Some of these packages depend on the installation of a plug-in card within the PC, others are totally software-controlled. In some cases encryption of files on the hard disk is an option, however the following points must be considered before using this facility: o whether or not the password protection can be circumvented, o whether the method of encryption (the algorithm) is strong enough, o whether the danger exists that encrypted files could accidentally or deliberately become corrupted and irretrievable. For technical guidance, refer to Chapter 10 for contacts. 5.3.2.1 Protection of data on non-removable disks Files resident on fixed disks are particularly vulnerable. Unless an encryption system approved by the Director of Security and Investigation is used or the PC is protected by other suitable means, sensitive data must not be stored on non-removable disks. Many application programs used on personal computers use the (often larger and faster) non-removable disk to temporarily store user data automatically, even if the file being edited is being held on removable media After processing, the temporary files are deleted from the disk; the data, however, remains intact until the space it is occupying is ovenvritten by another file. Many word-processing packages and similar programs produce back-up files and these also need to be erased. PCs on which has been loaded unknown or unauthorised software are particularly vulnerable to attack by a Trojan Horse which may copy software or sensitive data in a way that is unobserved and unknown by the usual PC user. Trojan Horse software is often distributed by means of a computer virus. Files deleted from disks, for example with the DOS DELETE command can be easily recovered as only the directory entry is amended to indicate the disk space is free for reuse; the data remains intact on the disk until it is overwritten. To completely delete a file it must be erased by overwriting it with zeros or a random data pattern. For increased privacy, this may need to be performed several times in succession. There are third-party programs available to do this. Files stored on file servers, such Novell's Network Operating System (NOS), when deleted, are actually moved to a 'deleted' directory, still accessible by system administrators. These files are not fully deleted until the Deleted directory space is exhausted. Administrators should set up procedures for the automatic deletion of these files. Copies may also exist on backup tapes. Should a non-removable disk, or a PC containing a non-removable disk, require maintenance, special precautions may be necessary to render unusable any information contained on the disk. If an approved encryption system is used on a non-removable disk, the privacy marking then applies only to the encryption key protecting that information. If the information is very sensitive, it may be appropriate to destroy the disk using destruction procedures approved by the Director of Security and Investigations. See also Software And Data: Disposal Of Media for policies on this subject. POLICY 5.3: STORAGE OF DATA ON NON-REMOVABLE DISKS Any personal computer fitted with a non-removable disk and containing privacy marked information shall be handled and stored accordingly. IN CONFIDENCE data shall be protected by an approved software access control and IN STRICTEST CONFIDENCE data protected by a hardware based access control and encryption system approved by the Director of Security and Investigation. POLICY 5.4: SENSITIVE DATA PROCESSED ON A PERSONAL COMPUTER When using a personal computer with a non-removable disk to process sensitive information, even if the data is held on a removable disk, the non-removable disk shall be assumed to contain sensitive information, and be treated appropriately. 5.3.3 Removable disks and cassettes All disks and cassettes must be put away when not in use. To guard against extraneous magnetic influences they should be stored away from any electrical equipment. Any removable media which contain sensitive information should be clearly labelled with the appropriate privacy marking. If sensitive information is being held they must be locked away in a suitable cabinet or drawer appropriate to its privacy marking. Lockable plastic disk cases by themselves are not sufficient protection. CSM Policy 7.17: MARKING OF MEDIA applies. 5.3.4 Protection of data in memomy Random Access Memory (RAM) is the PC's working memory. It holds the programs currently running and the data currently being processed. Frequently-accessed data on a floppy or non-removable disk may be loaded into RAM to improve access time. When the PC is powered off, RAM is normally erased. On some PCs, however, data in RAM is saved when the power is turned off, and can be reloaded when the power is turned on again. Some multitasking Operating Systems (OSs), such as UNIX in all its variants, OS/2 and Microsoft Windows manage virtual memory areas on a per process basis. When free memory becomes low on such systems, parts of memory are written out to a special disk area managed by the OS. The data remains on disk and can be accessed by persons familiar with the OS. Some OSs also generate memory dumps when the system malfunctions, at which point some, if not all, of memory is written out to disk before the system goes down. It may, under certain circumstances, be advantageous to make this information available to vendor representatives to help debug the problem, but the security implications associated with doing this must be assessed. If sensitive data is held on a PC and the operating system uses virtual memory, or RAM, is saved when the PC is powered off, then the person responsible must protect the PC in accordance with Policies 5.3 and 5.4. POLICY 5.5: RANDOM ACCESS MEMORY Where there is a possibility that an unauthorised person may have gained access to an unattended Personal Computer, it shall be switched off to clear volatile memory. PCs containing non-volatile memory shall be protected as though they contained a non-removable disk. 5.3.5 Hard copy (printouts) Where resources such as printers are shared, or several are available, special precautions should be effected to ensure privacy marked material is not seen by, or delivered to an inappropriate person. Printout should always have the appropriate privacy marking clearly displayed at the top and bottom of each page and handled in accordance with the appropriate rules in the Information Security Code. Partial printouts, perhaps resulting from failures or aborted print runs, should be disposed of in accordance with their intended privacy marking. Note that many printers contain a memory which holds information used for printing. In the event of failure during a print this information may remain in memory until the printer is powered off. Because some personal computers (and dumb terminals) offer the facility to take a printed copy of the contents of the screen (for example, screen dumps or print screen), each screen displayed should contain the sensitivity marking for that information. It should be noted that most laser printers hold a copy of the last printed page on the laser printer drum and that it is a relatively easy task to read this page of information directly from the drum.Therefore, whenever particularly sensitive information is printed on is type of device, the user should consider printing a full page of non-sensitive text in order to overwrite the previous page. POLICY 5.6: MANAGEMENT OF PRINTERS A Procedure shall be prepared and implemented when a shared or networked printer is used for producing privacy marked material. Printing over networked printers introduces additional possibilities for the compromise of sensitive information. The network, comprising both the hardware and software, maintains buffers for information to be printed. In some cases the data remains in the buffers after printing has occurred. The buffers may be accessed by unauthorised users or by mistake and data compromised. Sensitive information should only be printed to approved print locations where an analysis has been done on the security risks. 5.4 Security of software Only legitimate (licensed) authorised copies of software from reputable sources supplied by a secure distribution mechanism should be used on PCs. Any software from colleges etc, legitimately used by BT students, for instance, should be checked for hazardous code before loading as this is a potential source of viruses or untrustworthy software. Computer games are recognised as a source of computer viruses and their use is explicitly forbidden. POLICY 5.7: PUBLIC DOMAIN AND OTHER UNTRUSTWORTHY SOFTWARE Public domain and other untrustworthy software shall not be held or used on BT's personal computers. Exemptions to this policy may only be granted by the Director of Security and Investigation if there is a proven operational need. POLICY 5.8: GAMES Games shall not be used on BT's personal computers. Games must not be loaded onto BT's personal computers except where they come as part of a legitimate business sofhvare package and there is no facility for not installing the games. Exemptions to this policy may only be granted by the Director of Security and Investigation if there is a proven business need. 5.5 Personal computer communications PCs are capable of connection by means of modem cards and interface cards to the PSTN, Local Area Networks and other computers by various means. The connection of a PC to a network introduces additional threats to both the PC and, in some instances, the network. Although the chapter on Networks and Communications covers this topic in depth, this section considers the subject in the context of personal computers. 5.5.1 Public netvork access In general communication sessions controlled externally to the PC from the public network should be avoided. Where network access is unavoidable, strict controls should be applied. 5.5.2 Use of PC as a computer terminal Most PCs are capable of emulating various types of terminal, either by the use of sohware packages or the installation of an extension board. When used in this mode the PC appears to the mainframe processor as if it were the appropriate terminal type but it also retains the capabilities of a PC. As a consequence of the above, three major threats to security arise as follows: 1 programmable interrogation, 2 storage playback capability, 3 bridging of communication capability to other systems. 5.5.2.1 Interroga1ion and storage Fixed mode (dumb) terminals can only interrogate and search authorised transactions at a rate which is limited by the human operator. The results would normally have to be transcribed from the VDU or printed on a slave printer. A PC, on the other hand, could be programmed to carry out a range of interrogations, examine the resultant responses and store the details of any transactions which satisfy predetermined criteria. Once a procedure is established this exchange can take place at speeds which are limited only by the speed of the communications interface and a great deal of information could be sifted in a short period. When used legitimately this is considered to be a authorised use of PC power. However the security of the system may rely to some extent on the (perhaps limited) rate at which information can be extracted. 5.5.2.2 Connection to other systems Suitably equipped PCs could connect to a mainframe computer and a public access or BT-private network at the same time. Although the capability may seem attractive to the PC user, the administrator of the mainframe computer might view the potentially increased user community that may gain access to his system with some trepidation. It could be the view that, if incorrectly managed, such a PC could act as a switch or slave processor in order to connect the two. Thus an unanticipated method of communication could be established which would allow remote access from an unauthorised location and so constitute a breach of security particularly if the PC were left on all day. Similar concerns might be raised if the PC were to be simultaneously connected to two networks, for example, the PSTN and a BT internal network. It will be frequently both convenient and operationally legitimate to substitute a PC for a terminal device in order to limit the items installed on the desk-top and to streamline procedures. In recognition however of the risks to security, any proposal to substitute a PC for a terminal device must have the approval of the appropriate network or systems administration. They, in turn, must satisfy themselves with regard to the additional risks which might arise as a consequence of either enhanced interrogation or extended communication. POLICY 5.9: PCs USED AS TERMINALS FOR SYSTEMS A PC shall be used as a terminal for a BT system if, and only if, the use of a PC has been permitted in the Security Policy Document of that system. POLICY 5.10: PCs CONNECTED TO SYSTEMS A PC shall not be connected to more than one system at a time unless approval has been granted by the administrators of those systems. 5.6 Contingency planning The business is dependent for its functions on information of which a greater amount is being stored and processed on PCs. There is now, therefore, a business imperative to ensure that information on PCs is available when the business needs it. PC users should evaluate the needs of the business process supported by information on PCs, and ensure that these requirements can be met, even if there is a computer or disk failure. Mistakes are made and machines can fail, either potentially leading to corruption of data or software. Measures must be taken so that when corruption does occur, service can be restored with the minimum of inconvenience and cost to the business. The following are measures can be taken to reduce the impact of such a failure. 5.6.1 Archinng and backup Data and/or software should periodically be copied to removable media for one of several reasons: o in order to ensure that data is not lost in the event of a failure (BACKUP), o to free up the space occupied when the information is no longer required for immediate access (ARCHIVE), or o because the information must be retained for some time to meet legal obligations (ARCHIVE). The software and hardware products needed to achieve the above are usually identical; only the strategy of their use changes. Neither a backup nor archive is of any value unless it can be demonstrated that the information can be recovered reliably. Data held on non-removable disks should be backed-up regularly, perhaps daily or weekly depending on usage and criticality. The backup might be of the whole system or only of those parts that have recently changed - an 'incremental backup'. The copy should be stored either off-site or in a fire resistant cabinet, suitable for its level of sensitivity. There are four methods by which archive or backup copies of a system can be taken: Utility software Most PCs have a software facility on the system disk to back-up and restore files to and from a floppy disk. The process is time consuming but there is no other cost except that of the floppy disks used. Note there are compatibility problems between differing versions of the DOS BACKUP and RESTORE utility programs such that may it impossible to restore files written using one version of BACKUP using a version of RESTORE from a different vendor or different version of DOS. For this reason, it is advisable that a copy of the RESTORE program is kept with the backup or archive. 2 Third-party archive sofare Off the shelf software is available that enables files to be copied onto floppy disks or a tape streamer. This software is often considerably faster than using the utility software that came with the operating system, it is more flexible, and usually more reliable. There is a small charge for this software. 3 Tape streamer This is a separate item of equipment and often is supplied with the software to drive it. Though the cost of a tape streamer is not insignificant, it can usually be justified in the savings in time and floppy disks. Remember that a complete backup of an 80% full 40Mb hard disk will use well over 30 720Kb floppies or in excess of 60 360Kb floppies. The task may take over an hour and is often used as the excuse why a backup was not taken after the disk crashed! A tape streamer is essential equipment where several users share a file-server on a LAN. The capital cost can be spread amongst all of the LAN users, and all user files can be copied at once. 4 External disk drives External disk drives are available for many machines and can be used as a means of archiving. Though fast, they are sometimes neither rugged nor particularly economical. Iis situation may change with the introduction of high capacity floppy disk drives. Should any of the information copied for backup or archive purposes be in encrypted form, it is prudent to retain a copy of the cryptographic key so that the information can be recovered. The cryptographic key should be kept securely because it may be used to gain access to both the backup/archive and the original information still on the PC. 5.7 File Servers File Servers on Local Area Networks pose similar security problems to PCs, due to the fact that they are often sited in open plan offices, are small and are accessible by many people. If privacy marked information is held on a LAN server then precautions must be taken to safeguard that data. POLICY 5.11: FILE SERVER SECURlTY File servers shall be protected in accordance with the sensitivity of the information they contain, either through physical access controls, or through logical controls. Policies 4.6 and 5.3 refer. User access to computers Contents 6.1 Introduction . . . . . . . . . . . . . . . . . . . 6-3 6.2 Regulating access to computers. . . . . . . . . . . 6-3 6.2.1 Identification and authorisation principles . . . . 6-3 6.2.2 Logical access control packages . . . . . . . . . . 6-4 6.2.3 Siting of terminals . . . . . . . . . . . . . . . . 6-4 6.2.4 Intelligent terminals . . . . . . . . . . . . . . . 6-4 6.3 Identification . . . . . . . . . . . . . . . . . . 6-4 6.3.1 User identification . . . . . . . . . . . . . . . . 6-5 6.3.2 Terminal identification . . . . . . . . . . . . . . 6-5 6.4 Passwords . . . . . . . . . . . . . . . . . . . . . 6-6 6.4.1 Password management . . . . . . . . . . . . . . . . 6-6 6.4.2 Password selection. . . . . . . . . . . . . . . . . 6-6 6.4.3 System passwords. . . . . . . . . . . . . . . . . . 6-7 6.4.4 Password secrecy. . . . . . . . . . . . . . . . . . 6-7 6.4.5 Dual passwords. . . . . . . . . . . . . . . . . . . 6-7 6.4.6 Preprogramming of passwords . . . . . . . . . . . . 6-7 6.4.7 Computer storage of passwords . . . . . . . . . . . 6-8 6.4.8 Password change . . . . . . . . . . . . . . . . . . 6-8 6.4.9 Administrator control of passwords. . . . . . . . . 6-8 6.4.10 Manufacturer's installed UIDs and passwords . . . . 6-9 6.4.11 Software maintenance by third parties . . . . . . . 6-9 6.4.12 Password transmission . . . . . . . . . . . . . . . 6-9 6.5 Limitations of password security. . . . . . . . . . 6-10 6.5.1 Weaknesses . . . . . . . . . . . . . . . . . . . . 6-10 6.5.2 Random one-time passwords . . . . . . . . . . . . . 6-10 6.5.3 Challenge systems . . . . . . . . . . . . . . . . . 6-10 6.6 Logging on. . . . . . . . . . . . . . . . . . . . . 6-11 6.6.1 Welcome screens . . . . . . . . . . . . . . . . . . 6-11 6.6.2 Silent logon . . . . . . . . . . . . . . . . . . . 6-11 6.6.3 Log on security . . . . . . . . . . . . . . . . . . 6-12 6.6.4 Prescribed warning screen . . . . . . . . . . . . . 6-12 6.6.5 Log on failure conditions . . . . . . . . . . . . . 6-12 6.6.6 Repeated log on attempts. . . . . . . . . . . . . . 6-12 6.6.7 Recording access attempts . . . . . . . . . . . . . 6-13 6.6.8 Last access . . . . . . . . . . . . . . . . . . . . 6-13 6.6.9 Unauthorised access . . . . . . . . . . . . . . . . 6-14 6.7 Logging off . . . . . . . . . . . . . . . . . . . . . . 6-14 6.7.1 Terminal inactivity . . . . . . . . . . . . . . . . . . . . 6-14 6.7.2 Prolonged activity . . . . . . . . . . . . . . . . . . . . 6-14 6.7.3 Link interruption . . . . . . . . . . . . . . . . . . 6-14 6.8 User privileges . . . . . . . . . . . . . . . . . . . 6-15 6.8.1 Privilege table establishment . . . . . . . . . . . . 6-15 6.8.2 Facility privileges . . . . . . . . . . . . . . . . . 6-15 6.8.3 Function privileges . . . . . . . . . . . . . . . . . 6-16 6.9 Access to user files. . . . . . . . . . . . . . . . . 6-16 6.9.1 Implementation of logical access controls . . . . . . 6-16 6.9.2 Default privileges. . . . . . . . . . . . . . . . . . 6-17 6.9.3 Password control of file access . . . . . . . . . . . 6-17 6.9.4 Encryption of files . . . . . . . . . . . . . . . . . 6-17 6.10 Customer access to BT computers . . . . . . . . . . . 6-17 6.11 Contractors . . . . . . . . . . . . . . . . . . . . . 6-18 6.11.1 Software development by third parties . . . . . . . . 6-18 6.11.2 Operational activities by third parties . . . . . 6-19 6.1 Introduction The Computer Misuse Act 1990, has been in force in the United Kingdom since August. This law makes the unauthorised access to, and misuse of computer facilities a criminal offence. No amount of legislation will actually prevent unauthorised access and misuse of facilities. This chapter offers guidance on methods that may be employed to reduce or eliminate unauthorised access. Access to computers by users, in contrast to system operators and maintainers will normally be via a terminal device. It can vary from a simple Visual Display Unit (VDU), a sophisticated Personal Computer (PC), or a workstation. In order to regulate access, it is essential that controls are exercised which are capable of identifying both the source and origin of each session. POLICY 6.1: COMPUTER MISUSE ACT 1990 It is a criminal offence for an unauthorised person to attempt to access systems or information within systems, or to attempt to exceed the computer facilities and privileges granted to them. Wherever possible, BTwill prosecute using the Computer Misuse Act 1990. 6.2 Regulating access to computers Logical access control and associated audit trails and logs provide essential deterrents against abuse of privilege by authorised system users. The unauthorised testing of the security controls of an operational system is expressly forbidden. POLICY 6.2: OPERATIONAL SYSTEM PENETRATION TESTING The testing of the security controls of an operational system shall only be done under strictly controlled conditions. All testing shall be carried out in accordance with a written schedule. Prior approval of the Director of Security and Investigation shall be obtained. 6.2.1 Identification and authorisation principles To prevent unauthorised individuals attempting to access computer systems, identification and authentication controls of users are necessary. The most common practice is to use identifiers and passwords when logging onto the computer system. Other methods such as keys, badges, and smart cards can also be used effectively. Other techniques are possible (for example, challenge-response systems) using some form of personal token. Specialist advice should be sought on the security characteristics of proposed systems prior to their adoption. 6.2.2 Logical access control packages For some major operating systems, special purpose access control packages are available. These provide degrees of protection by ensuring that all users are positively identified and only granted access to the system resources and files for which they have previously been authorised. The packages frequently complement the standard operating system by exploiting hooks or by the replacement of standard routines and log details of all accesses for later analysis. They may or may not identify that the data has been seen or changed. Before implementing any security enhancement package it should be thoroughly evaluated to ensure it meets the operational requirement. 6.2.3 Siting of terminals Terminal devices must be sited so that they cannot be easily overlooked by unauthorised individuals. This is especially important when it is necessary to site terminals in reception areas, telephone shops or other public places. Customer information displayed on a screen which can be overlooked by the public or even unauthorised employees potentially constitutes a breach of Data Protection Legislation, Section 45 of the Telecommunications Act 1984, and the Code of Practice on Disclosure of Customer Information. The inadvertent disclosure of logon details may also result. When it is operationally necessary to site a terminal in a public area, it must be screened so that it can only be viewed by authorised employees. If this is not practical then serious consideration must be given to the benefits derived weighed against the possible risk of irregular divulgence of information displayed on the screen. The communication links for terminals in public places should be adequately protected from the threat of tampering and rerouting. POLICY 63: SITING OF REMOTE TERMINAL Terminals in public view but not for public access shall be sited carefully, and particular attention shall be given to their physical security and communications links. 6.2.4 Intelligent terminals Special care must be taken if ever a 'dumb' terminal is replaced by one with local processing power, for example, a personal computer. Iis subject is covered in detail in the chapter on Personal Computers. 6.3 Identification Identifiers are used to keep track of, and control the use of system resources. Users and terminals may both have identifiers which can be used for the purposes of auditing. 6.3.1 User identification Each user of a computer system should have an exclusive user identification (UID). o UIDs are used to uniquely identify users and their associated characteristics (access rights, capabilities, time based access and control privileges) to permit the correct allocation of resources, o UIDs provide a means of recording system usage o UIDs should be allocated to individual users to permit unambiguous identification in the interests of accountability. They should not be shared among groups of individuals and may be constant as long as the user is authorised on the system o UIDs are not usually confidential (indeed in some systems users can obtain lists of UIDs) and security must never depend solely on the user's ability to provide a valid UID. POLICY 6.4: UNIQUE USER IDENTIFIER Each user of a multi-user system shall be uniquely identifiable to that system. A network of computers that allows remote processes access to information on any of the networked computers must also maintain unique user identification for users, unless other means of security are implemented, for example by disabling the facility for cross-machine recognition of UIDs. Separate UID naming strategies for each machine can greatly assist in ensuring uniqueness. 6.3.2 Terminal identification Each terminal authorised to access the system may also have a Terminal Identification (TID) built into it which is automatically communicated to the host during log on. The system may then check that an attempted access comes from a bona fide source at the correct physical location, and by comparing the signalled TID with the UID of the user, may confirm an appropriate match. TIDs should not be implemented alone since this does not assist accountability. Moreover as a security measure they are rather limited. It is difficult to engineer an unmodifiable TID into a terminal and TIDs may also become known in which case they can be simulated. Terminal identification can also be by means of physical access controls such as locks or removable badges and keys. In this case a code may be transmitted automatically by the terminal over the communications link at the beginning of every message. Any badges or keys must be removed when the terminal is not in use and securely stored. POLICY 6.5: TERMINAL IDENTIFERS IN A NETWORK In the design of systems, the use of terminal identities shall be considered where technically feasible. On some systems, source identification uniquely identifying the device and user, for example, based on Kerberos, can be implemented. These systems provide a very secure mechanism for forming a closed network of systems and users. 6.4 Passwords The knowledge of a password is sometimes used as corroborating evidence that the accessor is entitled to the facilities associated with a particular UID. Passwords must be allocated on an individual basis and not be shared. 6.4.1 Password management To afford reasonable protection against unauthorised access, passwords should be a minimum of six characters long, with at least one non-alphabetic. Passwords used for system privileges should contain at least eight characters. It is desirable that the system software should check for too simple a combination such as all the same characters. There is an advantage in allowing a range of password lengths (down to the prescribed minimum) since this makes searching by adversaries harder. POLICY 6.6: PASSWORD MANAGEMENT Passwords to systems shall be properly managed so that: o They are not easily guessable, o They are changed at least every 90 days, o They are at least 6 characters long for user access and at least 8 for system privilege access, o Preferably they consist of all the possible character set, o They contain at least one non-alphabetical character, o They cannot be easily changed back to previously used passwords, o They cannot be easily exhaustively searched (unless denial of service is a threat), o They are not echoed to screens or paper, o They are not written down, except if treated with appropriate security levels to protect their confidentiality, integrity and accountability, and where there is a valid business reason o Not related to the UID, o They are not related to the identity of the user. 6.4.2 Password selection Users should be permitted to select their own passwords since these are more easily remembered but users must be warned against guessable or predictable values. The system should check that all passwords are not one of the 'standard' or guessable words that an adversary would try, for example, password the same as the UID. Meaningful terms such as SYS or SYSTEM, initials, Christian names, car registration numbers and the names of spouses are all popular choices for password and are worthless from a security viewpoint, as are certain popular words such as FRED. The more common or computer-relevant meaningful words of the English language are also to be avoided. There are surprisingly few of them - perhaps only 4000, and many cases exist of hackers breaking a system by simply trying a few hundred of the most likely words one after another. Password strength is greatly enhanced by the selection of non-meaningful character combinations. An adversary is far less likely to guess a password such as XAC/9 than ANDREW although initial memorisation may be more difficult. 6.4.3 System passwords An extra level of security is obtained if users are required to enter a system password prior to and as well as their own selected application password. System passwords provide the additional facility of rapid lock-out of groups of users if need be. System passwords must never be used as a substitute for personal passwords. They must be chosen in line with the password generation guidelines and be controlled by the systems administrator. 6.4.4 Password secrecy Users must be properly briefed on the importance of the correct use of passwords and that they have a responsibility to safeguard them. All passwords should be assumed to be as valuable as the system or information to which it can be used to gain access. If the password is written down, the text should be protected accordingly. A password should not be disclosed to others nor should it ever be entered at a terminal when others are in a position to watch so closely as to deduce the password. When a password is used to gain access to a system or entered for the purposes of password change, the password text must be obscured either by overprinting, in the case of hardcopy local echo terminals, or the echo suppressed where full-duplex communications are used between the terminal and the host. 6.4.5 Dual passwords Under some circumstances, business transactions might be so important that no one individual may be permitted to initiate the transaction by themselves. If these transactions are actually carried out by computer then a way must be found to ensure that two people are present to 'authorise' the transaction and be responsible for it. One approach is to ensure that system accounts that have the privilege to initiate such transactions need two passwords to access them. An alternative approach might be to have one long password formed by the concatenation of two shorter passwords. Other schemes could be devised. 6.4.6 Preprogramming of passwords Storage of preprogrammed passwords or entire logon sequences on intelligent terminals or function keys or stored files is extremely dangerous practice and is forbidden unless the circumstances have been agreed by the Director of Security and Investigation. Any brief unauthorised access to the terminal or stored data will then permit the password to be compromised. POLICY 6.8: PREPROGRAMMING OF PASSWORDS The automation of entire logon sequences is expressly forbidden except with the permission of the Director of Security and Investigation. 6.4.7 Computer storage of passwords Users' passwords should be under their own control and should not be available from the system to anybody else including operational or maintenance staff. To this end it is highly desirable that the computer logon procedures use one-way encrypted password files. This means that passwords are stored in irreversibly encrypted form within the computer. Passwords entered by users at logon are encrypted using the same algorithm, and the two encrypted forms are checked for a match to prove authentication. The encryption algorithm must however be strong and guidance must be sought from The Director of Security and Investigations, since some password encryption systems have been found to be very weak indeed. 6.4.8 Password change The system should ensure that all passwords (individual and system) are changed regularly. Passwords should be changed at least every 90 days. Password change may be enforced by: o forcing users to change their passwords after a given period, or o allowing users to change their passwords at will ess desirable since less reliable), o or preferably both. The change of existing passwords should involve a verification of the user's identity on the basis of the existing password and double entry of the proposed new password as a check against input errors. The system should not permit an old password to be used again until at least a certain number of different new passwords have been registered. Where forced password change is not implemented the system should record the date of last change to permit identification of users not complying with security requirements. If there is a possibility that a password has been compromised, it must be changed immediately. 6.4.9 Administrator control of passwords It should be possible for the system administrator to force a user's password to a value of the administrator's choosing in the event that a user genuinely forgets his or her password. However neither the administrator nor anybody else should be able to obtain the value of a current password from the computer. As an alternative, stronger security is obtained (at slightly greater administrative cost) if password forcing is simply not allowed. In this case forgetting a password compels full reauthorisation. POLICY 6.21: UID EXPIRY When a UID remains unused for greater than 60 days, it shall be disabled. 6.4.10 Manufacturer's installed UIDs and passwords Manufacturer's installed UIDs and passwords present at equipment and software delivery must be changed to user-selected values as soon as practicable since the manufacturer's choice of values may be standard and well known. It is also essential that passwords are changed after every visit by the manufacturer or computer servicing agency to remove the danger of passwords becoming known to contractors. Care must be taken when the system is reloaded and upgraded that any manufacturers passwords are not reinstated. POLICY 6.9: MANUFACTURERS PASSWORDS Manufacturer installed passwords shall be removed and replaced with new passwords in operational systems. 6.4.11 Sofware maintenance by third parties Systems requiring access for software maintenance by non-BT personnel should not permit total system software and data file eedom to the contractor. Maintenance should only be possible at agreed times and under BT supervision. Sensitive data should, if necessary, be removed from the system prior to maintenance. Some computer vendors encourage remote access to their customers computer systems via the PSTN for the purposes of fault diagnosis. If this option is taken, access must be very strictly controlled since large quantities of information could easily be made available, perhaps by means of uncontrolled software dumps. Access to the system should be controlled manually, for example using a port configured for outward dialled calls only with incoming calls barred. Special care must be taken to change passwords after maintenance sessions by contractors. POLICY 6.10: REMOTE ACCES FOR MAINTENANCE PURPOSES Remote access for diagnostic or preventative maintenance purposes shall be strictly controlled so as to protect the security of the system. 6.4.12 Password transmission Passwords used to protect information of a given sensitivity must be afforded at least the same protection and preferably a higher level of protection than the information and processes to which they give access. This is particularly important when accessing a system remotely across a public network. Distribution of passwords must be done in a way which ensures that disclosure en route would not result in a compromise of the system on which the password would be used. In particular, electronic mail systems must not be used for distribution of passwords. 6.5 Limitations of password security Most experts no longer regard traditional password practices as fully secure. This section outlines their limitations and indicates favoured methods of enhancing security 6.5.1 Weaknesses The advice concerning minimum password length, secrecy and frequency of change should be viewed as the minimum requirements. Unless users are strongly encouraged (or forced) to employ highly random passwords they will tend only to select passwords from a total of about 4000 English words. Even if passwords are highly random the fact that they are used more than once represents a security weakness since any person obtaining a password value (by line tapping, by watching the operator key in the value, by finding a written copy...) can then penetrate the system freely until that password is changed. These weaknesses can be overcome by both using truly random passwords, and changing passwords every access. 6.5.2 Random one-time passwords This can be achieved by adopting one-time password procedures whereby each user is given a list of random password values which must be used once only each and in the given order. However, this would involve writing down passwords which is contrary to good practice. In certain systems, the distribution of such lists may be acceptable, but generally the challenge system of the next paragraph is to be preferred. 6.5.3 Challenge systems In a challenge system, random one-time passwords are obtained by providing each user with a Personal Identification Unit (PIU) usually resembling a pocket calculator. On attempted access with a valid UID, the host generates a random number or challenge value which it sends to the user. The user must then enter the value manually on their PIU. The PIU then performs a complex mathematical operation on this number and displays the result on its display. The user then transcribes this number to the terminal which, in turn, is sent to the host for checking. If the check is successful, the host can be reasonable certain that the user has the correct PIU in his possession and access can be granted. Each PIU should use a different cryptographic key to permit identification of an individual user. The PIU will work correctly only in conjunction with its associated UID. Attempts to use the PIU with an alternative or incorrect UID will result in an incorrect response being generated. To prevent unauthorised system access should a PIU fall into the wrong hands the user may also be required to enter a secret Personal Identification Number (PIN) into the PIU prior to keying in the challenge value. The access thus depends on something: o possessed by the user (the PIU), and o known by the user (the PIN). The algorithm should be cryptographically strong so as to prevent analysis of the method by an adversary. Alternative types of PIU, which generate a new one-time password every minute or so, obviate the need for a challenge-response sequence, are also available. Biometric devices are becoming more commercially available and are worthy of consideration for sensitive systems, they are however rather costly for widespread use. POLICY 6.11: USER AUTHENTICATION DEVICES In the design of systems, the use of user authentication devices should be considered and documented. 6.6 Logging on No user should be able to log onto a system containing high integrity, commercially sensitive, or privacy marked information without first executing a security dialogue, such as a correct entry of a valid UID and matching password (or equivalent). This ensures full identification and authentication and permits logging for subsequent accountability. 6.6.1 Welcome screens The initial screen (traditionally called the "Welcome" screen) displayed before successful completion of the security dialogue should be designed to reveal the minimum amount of information about the system. POLICY 6.12: WELCOME SCREENS Text displayed before logon shall provide only the minimum amount of information for access authorisation. 6.6.2 Silent log on No system facilities, not even the 'HELP' command, should be available to the user prior to successful completion of these steps. Security is appreciably enhanced by adopting log on procedures which give no help to potential adversaries. POLICY 6.13: SILENT LOGON Other than a minimal prompt for user ID and password, no additional help shall be given when logging on to BT multi-user, administration or management systems. Failure of a logon sequence shall not identify which part of the logon process failed. 6.6.3 Log on security The logon procedure should be fully secure. No trap-door method shall be possible by, for example, through use of zero-length, excessive length UIDs or passwords, or by control, escape or break signals. 6.6.4 Prescribed warning screen As soon as access has been successfully achieved, the following screen should be displayed by all BT multi-user, administration and management systems processing high integrity, commercially sensitive, or privacy-marked material. British Telecommunications plc COMPUTER NAME WARNING: You have accessed the COMPUTER NAME operated by BT. You are required to have a personal authorisation from the system administrator before you use this computer and you are strictly limited to the use set out in that written authorisation, Unauthorised access or use of this system is prohibited. Unauthorised access to or misuse of a computer constitutes an offence under the Computer Misuse Act 1990. If you understand this message and have been authorised to use this system please type YES. Otherwise type NO to terminate this access. Are you authorised to use this computer? POLlCY 6.14: PRESCRIBED WARNING SCREEN AND AUTHORISATION A prescribed warning screen shall be displayed immediately after an accessor successfully completes the logon sequence. The system administrator shall set up procedures to provide written authorisation to users stating their access privileges. 6.6.5 Log on failure conditions Logon must not be permitted if: o the UID is invalid, o the UID is barred, o the password is invalid, o the UID and password combination is invalid, o the claimed UID is already active unless it is a system requirement, o the logon would contravene local policy, for example, time of day restrictions. 6.6.6 Repeated log on attempts The rate at which an adversary can make log on attempts must be limited to prevent exhaustive searching of UID and password combinations. Such an attack can be rendered imoractical bv compelling: o a modest time delay (eg. two seconds) between each individual access attempt made on any given port, and o a substantial time delay (eg. one minute) every few attempts (eg. three). This may be accomplished by including an attempt counter in the log on procedure such that no more than three attempts may be made subject only to the modest time delay, after which attempts from that port are disabled for a substantial time delay. The preferred option is that the link is actually disconnected and the user compelled to obtain reconnection. A stronger measure would be to permanently disable the UID or port with appropriate messages being sent to system log and the system administrator. In such cases the UIDs should be taken out of service automatically after a predefined number of consecutive unsuccessful access attempts - perhaps three. Before the locked-out UID can be used again, an approach has to be made to the Systems Administrator who will decide, if necessary in consultation with the Application Manager, whether to reactivate the original UID or issue a new one. This strategy is recommended for consideration only for High Impact Systems because an adversary may abuse the feature to disable all UID and/or ports causing a 'Denial of Service' problem. The running of verification utilities against system critical commands should be considered prior to reinstatement of the UID. POLICY 6.15: TERMINAL OR UID LOCKOUT When a terminal or UID is repeatedly misused in an attempt to breach a system, the terminal or UID shall be disabled and an alarm given. The period during which the terminal or UID is disabled must be commensurate with the impact of Denial of Service. 6.6.7 Recording access attempts Where possible all access attempts (whether or not successful and whether or not exceeding the counter limit) should be recorded on the system log. Alarms to the system manager may also be raised in real-time depending on the sensitivity of the system following repeated logon failures. The record should indicate the attempted UID, the time of the event and the link involved but should not record the attempted passwords. Exceptional events (such as apparent exhaustive trialling of password on a particular UID) should be so recorded as to come rapidly to the attention of supervisory personnel. The log must be scrutinised at frequent intervals for any evidence of unauthorised access attempts. Any unusual logged events must be investigated. POLICY 6.16: SECURE ALARMS Security alarms shall be used to inform the system administrator when an attempted breach of security has been detected. 6.6.8 Last access On successful logon the user should be informed of the time and date of last access, and of any unsuccessful access attempts since then. 6.6.9 Unauthorised access Any (suspected or known) unauthorised access attempt or criminal activity should be reported immediately to the BT Investigation Department Help Desk and line management. Further investigatory action should await specialist advice from BTID. POLICY 8.8: REPORTING OF SECURITY INCIDENTS applies. 6.7 Logging off 6.7.1 Terminal inactinty The system should include an activity sensing feature to identify terminals which, although logged on, appear to have been abandoned. These are a security risk since an adversary finding such a terminal unattended could employ it with all the access rights of the previous user. If no input is detected after a certain timeout (eg. five minutes) the system should log the terminal off automatically. This may be undesirable for some very limited facilities, such as batch processing or program development, in which case longer timeouts may be associated with specific UIDs. PCs should have approved security programs installed on them such that, if no user activity has been detected for a period of time, the program will lock the PC terminal and require a password entry to be reactivated. is must be done especially for PCs logged into a server system. Such programs should also blank out the actual contents of the display (it may be replaced by some other display) until the PC has been reactivated through the password. Screen blanking options that only jumble the contents of the screen should not be used. Preferably, the blanking of data should be combined with a screen saver function, which reduces the display duty cycle significantly, to help prolong the life of the display. POLICY 6.17: TERMINAL OR UID TIMEOUT When a port or UID remains dormant for a period of time, it shall be disabled. Terminal timeout shall also occur when a terminal remains logged onto a system, but remains unused for a period of time. The screen shall be cleared of any display when the forced logoff occurs. 6.7.2 Prolonged activity The system should require users present on the system for prolonged periods (hours rather than days) to reenter their log on sequence (UID and password) . This is to ensure that the authorised user is still present and that the communication link has not been hijacked by an adversary. 6.7.3 Link interruption The system should similarly automatically log off and clear down completely and immediately the session with any terminal whose communications path is interrupted. Many terrninals have a carrier detection light to show at the communications path is open and the failure of this may indicate an interruption. POLICY 6.18: LOG OFF WHEN COMMUNICATION SESSION IS INTERRUPTED Precautions shall be taken during the design of systems to ensure that active sessions are aborted if a failure in communications occurs. 6.8 User privileges It is usually a requirement that user capabilities still be restricted after log on. This is to prevent unauthorised use of computer facilities and unauthorised access of system software and data to which the user is not entitled. It is generally accomplished by establishing a set of 'privileges' associated with each UID such that users are not permitted to perform functions or access data except as indicated in their privilege tables. Controls shall ensure this by such means as password controls, access control lists, labelling of data fields. POLICY 6.19: DATA ACCESS CONTROLS Processing capability and data shall be accessible only by authorised staff with the appropriate privileges. 6.8.1 Privilege table establishment The default condition of all privilege tables should be that corresponding to no privileges. Privilege tables must be under the ultimate control of user management who must authorise all changes. 6.8.2 Facility privileges Privileges speciing the computer facilities available to users should be controlled only by system administrator staff. Facility privileges include: o I/O device allocations, o available storage volume, o maximum job size, o financial budget and its consumption. This restriction must be applied with particular rigour to security privileges. It must not be possible under any circumstances for an ordinary user to redefine himself as a system operator or system administrator for example or obtain access to their data files or facilities or obtain access to security-related software such as: o operating systems, o password control software, o system log software, o access control software, o time restrictions. Where a job consists of several tasks run in sequence, the authority of the user should be checked at each task and not solely on the first one. Staff whose job is to run a limited set of programs should not have the facility to edit, read or write programs. Menu-driven software may be helpful to ensure this. POLICY 6.20: ADMINISTRATION OF PRIVILEGES Privileges shall be administered only by the system administrator (or equivalent role) . 6.8.3 Function privileges Privileges defining the computer functions available to users should also be controlled by system administration staff only. Procedures for the replication of user privileges should only allow the minimum to be created appropriate with the users authority. Users should only be permitted to use those commands required in the normal course of their duties. 6.9 Access to user files Privileges defining the rights of users to access each other's data files may be exclusively under system administrator control, especially on high risk systems. However, on less sensitive systems discretionary control is frequently all that is required whereby each user controls the access of others to his own data files. In general systems developers should not have access to live files. 6.9.1 Implementation of logical access controls In this context 'access' may imply any of a number of operations (eg read, write, delete, modify, execute...) and it is essential that each of these should be separately specifiable. In any case there is implied the creation of a more or less detailed set of access restrictions for each user data file and the existence of special system control software for enforcement. There may also be a need for user identification control within applications, for example to test for the maintenance of separation of duties. Software development tools, for example, compilers, program libraries, source code etc, should not be available on operational systems. If they are present, their use must be strictly controlled. It is important that as much as possible of the control procedure should be performed automatically by the system and in a 'user friendly' and efficient manner. User acceptance and co-operation cannot be obtained otherwise and the security system will be viewed as an enemy by those it is intended to serve with the result that users will tend to avoid and circumvent its protective measures where possible. Most Operating Systems implement some form of access control but the degree of real security obtained varies dramatically from one system to another. 6.9.2 Default privileges The preferable default privilege is that no user other than the file owner can access (read, write, etc.) any given file unless given explicit authority to do so by the owner. 6.9.3 Password control of file access A limited degree of control may be obtained by password protection of files such that access is only available to users who know the correct password. Separate control of the different types of access (read, write, etc.) is then not generally possible, and the overall degree of security is much poorer than the fully specifiable, fully managed systems indicated above. This is partly because of user reluctance to undertake the burden of the additional passwords especially when all the issues concerning randomness and regular change of password are taken into account. 6.9.4 Encryption of files Files may also be encrypted by users to obtain a degree of protection rather higher than password control since simple access to the file no longer yields useful information. 6.10 Customer access to BT computers As communications technology becomes more and more sophisticated, and external companies become more demanding in the flexibility and management of the BT services which they use, BT is required to offer management and administrative services to its customers. The risks associated with this are well known and understood within the security community. However, systems implementors and administrators are not always aware of these. Systems which provide customer access are vulnerable in a number of areas, specifically the risk of access to system facilities which are beyond their anticipated privilege profile. Ihis can lead to: Compromise of the BT system Compromise of connected networked systems Compromise of other customers data Where customers are given access to a BT system, the system must be designed in a way that separates the customer access facility from the system's internal BT facilities. Where access to the system is initially regulated by the standard operating system User ID/password system, access to the internal BT facilities must be via a strong authentication method, preferably based upon a token or one-time password system. Customers place a high degree of trust in the service BT provides. It is the responsibility of systems implementors to consider the impact of failure upon a customer. Depending upon the risks it may be beneficial to provide access upon strong authentication techniques. When customers are given access to BT Service Management Systems, used by other customers, or holding sensitive information about other customers, processes or contracts undertaken by BT, then the Service Management System shall be considered to be a "high impact" system and subject to accreditation by the Director of Security and Investigation. (See section 2.8) POLICY 6.21: SENSlTIVllY OF SYSTEMS WlTH CUSTOMER ACCESS Systems providing customer access are deemed to be HIGH IMPACT systems where there is a connection between that system and other BT systems. POLICY 6.22- AUIHENTFICATION ON SYSTEMS VVlTH CUSIOMER ACCESS Access to non-customer facilities on a system providing customer access shall be via strong authentication methods. 6.11 Contractors 6.11.1 Software development by third parties Development of applications for BT by external companies should adhere to the same standards of development practice that we expect of internal developments. The quality assurance of the system is a crucial issue, particularly for systems which are of an operational or mission critical nature. Assurance standards should be quoted in terms of the Information Technology Security Evaluation Criteria (ISEC) levels, which should be specified at the start of the project. There are greater risks associated with software produced by external companies, where the level of direct BT supervision is likely to be minimal. The introduction of Trojan horse code is not easy to detect without extensive analysis of the program code. On-line systems need to be afforded protection from development people, and segregation of roles is a key element of this. Development contractors need to be separated from live environments. Default access to live data is not permitted. Access to live data in support of the contract should be for specific activities and must be monitored. Access must be withdrawn immediately following completion of the activity, or between phases of it. POLICY 6.23: CONTRACTOR ACCESS TO DATA Third Party Contractors used for development of systems shall not have direct access to on-line BT systems or live data, unless such facilities are absolutely necessary for execution of the contract. In this case, the contract shall specify the security requirements to protect BT's information. Operational activies by third parties BT has used outside contractors and agents for carrying out work for many years. Examples of this are building maintenance and other non-communications related activities. Increasingly, activities are being transferred to outside specialists. However, over the last decade, almost all of our activities and functions have been computerised and have become highly integrated with other systems. Therefore, outsourcing of an activity has to be viewed against the threats to BT as a whole from such a scheme. POLlcY 6.24: OUTSOURCING Proposals to outsource a process, to be carried out without direct BT supervision off BT premises, and which requires electronic access to BT information, must be supported by a Security Policy Document. If the process involves on-line access to a BT system processing information at Sensitivity level 2 or higher, the system must be accredited in accordance with Policy 2.7 Software and data Contents 7.1 Introduction. . . . . . . . . . . . . . . . 7-2 7.2 Software installation and maintenance . . . 7-2 7.2.1 Software changes. . . . . . . . . . . . . . 7-2 7.2.2 Protection of production systems. . . . . . 7-2 7.2.3 Software copyright. . . . . . . . . . . . . 7-3 7.2.4 System backup . . . . . . . . . . . . . . . 7-4 7.2.5 Failures and recovery . . . . . . . . . . . 7-4 7.3 Log faciliffes and system data. . . . . . . 7-4 7.3.1 Log facilities. . . . . . . . . . . . . . . 7-4 7.3.2 Logging system activity . . . . . . . . . . 7-5 7.3.3 Logging user activity . . . . . . . . . . . 7-5 7.3.4 Checking logs . . . . . . . . . . . . . . . 7-5 7.3.5 Retention of logs and journals. . . . . . . 7-6 7.3.6 Condition records . . . . . . . . . . . . . 7-6 7.3.7 Storage of logs in microfiche form. . . . . 7-6 7.3.8 Encryption of system data . . . . . . . . . 7-7 7.3.9 Back-up copies. . . . . . . . . . . . . . . 7-7 7.4 Data sensiffvity 7.4.1 Data ownership. . . . . . . . . . . . . . . 7-7 7.5 Storage . . . . . . . . . . . . . . . . . . 7-8 7.5.1 Write protection. . . . . . . . . . . . . . 7-8 7.5.2 Labelling . . . . . . . . . . . . . . . . . 7-8 7.5.3 Documentation . . . . . . . . . . . . . . . 7-9 7.5.4 Extraneous magnetic influences. . . . . . . 7-9 7.6 Disposal of media . . . . . . . . . . . . . 7-9 7.6.1 Magnetic media. . . . . . . . . . . . . . . 7-9 7.6.2 Disposal of computer equipment. . . . . . . 7-11 7.6.3 Documents, printout and consumables . . . . 7-11 7.7 Computer viruses. . . . . . . . . . . . . . 7-11 7.7.1 Vulnerability of systems. . . . . . . . . . 7-12 7.7.2 What a computer virus does. . . . . . . . . 7-12 7.7.3 Detection of computer viruses . . . . . . . 7-13 7.7.4 Group policy on computer viruses. . . . . . 7-13 7.7.5 Guidance. . . . . . . . . . . . . . . . . . 7-14 7.1 Introduction 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. 7.2 Software installation and maintenance 7.2.1 Software changes 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. 7.2.2 Protection of production systems 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. POLICY 7.1: VERSION CONTROL OF SOFTWARE Software shall be subject to version control to ensure that only current and approved software is in use on an electronic system. POLICY 7.2: PROTECTION OF DATA IN SYSTEM TESTING 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. POLICY 7.3: SOFTWARE OF UNKNOWN INTEGRlTY 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. POLICY 7.4: LIMITED USE OF DEVELOPMENTAND MAINTENANCE SOFTVVARE 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. POLICY 7.5: EMERGENCY ACCESS TO PRODUCTION SYSTEMS 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. 7.2.3 Softvare copyright 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. POLICY 7.6: COPYRIGHT OF BT SOFTWARE 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. POLICY 7.7: COPYRIGHT IN NON-BT 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). 7.2.4 System backup Interruptions to normal working may be caused by such events as fires, hardware, software or environmental failures and malicious damage. POLICY 7.8: SYSTEM BACKUP 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. 7.2.5 Failures and recovery 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. POLICY 7.9: RECOVERY FROM PROCESSING FAILURES 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. 7.3 Log facilities and system data 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. 7.3.1 Log facilities 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. 7.3.2 Logging system activity System activity should be recorded on the log to include matters such as: - processing software errors, - program aborts, - crashes, - machine failures, - restarts together with information about causes. 7.3.3 Logging user actinty 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: o all system log on attempts (successful or unsuccessful), o all log off events, o all attempts by users to access system facilities outside their range of privilege, o all attempts by users to access data files belonging to other users in contravention of system access controls, o all attempts by users to employ commands outside their range of privilege o all use of high level privilege. The log should particularly include all security-relevant events, that is, interaction and attempted interaction with the security system such as: o password changes (although without logging password values) o access to restricted or critical system tables o modification of privilege lists POLICY 7.10: ELECTRONIC SYSTEM ACTIVlTY RECORDS 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. 7.3.4 Checking logs 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. POLICY 7.11: CHECKING OF LOGS System logs shall be regularly checked so as to detect unauthorised system activity. The use of automated techniques shall be considered. POLICY 7.12: CONTROL OF AUDIT TOOLS The automated tools used to analyse the system log files shall be protected and subject to management and control procedures. 7.3.5 Retention of logs and journals The length of the retention period should take into account audit and legal requirements, error recovery and investigation of any unusual occurrences. 7.3.6 Condition records 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: o billing options, o access control features, o user privilege profiles, o audit trails, o configuration management. This inforrnation can be used to provide legally submissable evidence concerning the correctness of the system in the pursuance of Section 69 of the Police And Criminal Evidence Act (1984). POLICY 7.13: LOGGING OF FAULT REPORTS A log shall be kept of fault reports by users, and hardware and software maintenance on systems. POLICY 7.14: AUDlTS AND JOURNALS 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. 7.3.7 Storage of logs in microfiche form 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. 7.3.8 Encryption of system data 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. 7.3.9 Back-up copies 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. POLICY 7.15: BACKUP OF SENSITIVE DATA 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. 7.4 Data sensitivity 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: o a substantial loss to BT, o a substantial gain to a competitor, o severe embarrassment to BT, o serious loss of confidence in BT, or o a serious reduction of BT's standing in the community, or relationships generally, are called HIGH IMPACT SYSTEMS. 7.4.1 Data ownership 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: o judge the value and importance of the information, o assign a sensitivity level, o specify operational controls and permitted uses, o communicate control and protection requirements to users and custodians. POLICY 7.16: DATA OWNERSHIP All data shall have an owner who is responsible for deciding its sensitivity. 7.5 storage 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. 7.5.1 Write protection Where possible all storage media should be write-protected prior to shipping and at all times when not active in the system. 7.5.2 Ibelling Magnetic media should be labelled with a unique identifier and the relevant privacy marking if appropriate. Methods of marking may be: 1 Magnetic tape spools - attaching marked labels to the front flange, and/or the edge of their protective canisters, and/or the front of any suspension rings used to support the tape spools during storage. 2 The front and back faces of cassettes and spines of protective boxes should be clearly marked. 3 Removable magnetic disks and disk packs should be marked on the top of the disk or pack or labels fixed to the top and side of the storage covers. 4 Floppy disks should be labelled on one side as specified by the manufacturer. If disks are kept in boxes, the front and back of these should also be marked. 5 A log should be kept of their use with the following information included: o system name and reference number, o date and time of last use, o present privacy status, o other corresponding tapes or disks, o name or initials of the person responsible for their use. POLICY 7.17: MARKING OF MEDIA 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. POLICY 7.18- MARKING OF DATA Data shall be marked in accordance with the Information Security Code. 7.5.3 Documentation 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. 7.5.4 Extraneous magnetic influences 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. 7.6 Disposal of media 7.6.1 Magnetic media 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. POLICY 7.19: ERASURE AND DESTRUCTION OF MEDIA 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. A - Destruction of media, using facilities approved by the Director of Security and Investigation. B - Overwriting of media, using a technique approved by the Director of Security and Investigation. C - Reformatting, using a fail safe operating system low level format facility. D - Release permitted, but only to reputable companies with which BT has a non-disclosure agreement. E - Bulk erasing (degaussing), using equipment approved by the Director of Security and Investigation. X - This option is not permitted. The sensitivity level refers to the highest sensitivity of the information that has ever been stored on the media. Fixed Disks 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. 7.6.2 Disposal of computer equipment 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. POLICY 7.21: DISPOSAL OF COMPUTER EQUPMENT 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. 7.6.3 Documents, printout and consumables 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. POLICY 7.22: DESTRUCTION OF PRINTER-BASED MATERIAL Sensitive media shall be destroyed in accordance with the Information Security Code. 7.7 Computer viruses 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. 7.7.1 Vulnerability of systems 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. 7.7.2 What a computer virus does 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. 7.7.3 Detection of computer viruses 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. 7.7.4 Group policy on computer viruses 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. POLICY 7.23: VIRUSES: RESPONSIBILITY OF USERS 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. POLICY 7.24: VIRUSES: POLICY FOR HIGH IMPACT SYSTEMS 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. POLICY 7.25: VIRUS DETECTION 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. 7.7.5 Guidance 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: 1 Reduce the risk by only using software that is sourced directly from reputable manucturers and for which there is a customer/supplier contract that identifies a requirement for quality so%ware. 2 Machine-readable media containing master copies of operating systems, programs or utilities should be locked away securely at all times. 3 Computers containing executable copies of operating systems, programs and utilities should be kept within a local secure perimeter, else some means of logical access control should be deployed to prevent malicious infection. 4 Operating system and program media should never be lent, borrowed or exchanged (except where the highest levels of personal trust prevail) . 5 Machine-readable media used for data file exchange should contain only the data. Media should be inspected for executable files. 6 Machine-readable media should not be exposed to systems whose integrity is unknown, for example, systems at home or university systems. 7 Public-domain programs shall not be downloaded, and in particular, computer games should not be held or played on BT machines. Where games arrive as a part of a software package they should be erased. 8 All incoming and outgoing machine-readable media should be checked for known viruses. The preferred method of doing this is on a standalone machine, dedicated to that purpose (commonly called a sheep-dip PC). For further information on the approved high integrity product, please refer to section 11. +++ EOF ============================================================================= PHUK MAGAZINE - Phile 9 of 10 ============================================================================= --------------- Notes & Queries --------------- Note: Notes & Queries is the section where the readers send in any questions, problems etc that they might have, and other readers can send in the answers. We want YOU the reader to send your questions and answers to us, at anon93143@anon.penet.fi . Let me start off with some feedback that PHUK has got. Dear PHUK, First of all , loved the first issure of PHUK , its about time there was something decent to read in the UK , well done , look forward to reading the next one. You asked what the difference was between "Breach of confidentiallity" and "Hacking" , well , after consultation with my legal expert it appears that Breach of confidentiallity is to do with the trust that an employer gives to his employee in terms of access to data , (not necessarily computer data ). Hacking is the activity of unauthorised access to computers via any means. Usually hacking is done at a remote location rather than on site as the " BT Hacker " did . As far as I can see , he didn't hack anything , he just used the computer as part of his job and leaked dodgy data to the press. Keep up the good work. Regards HILO. Well thanks for the praise , your cheque is in the post ! ;-) Phuk-Ed. Now for some queries . Q: Does anyone know what frequencies the secrurity people use at the Troc , or does anyone know of some really interesting frequencies I could scan for ? A: Well readers , I will wait for your answers - Phuk-Ed . Q: Who do I ask to find out about the 2600 SE meeting ? A: Any one who knows about it , ok only joking the the details are as follows. LOCATION: ROEBUCK PUB IN LEWISHAM TIME : FROM 8PM ONWARDS DATE : 2Oth MAY 1995 OR ROUGHLY 3 SATURDAYS AFTER THE FIRST FRIDAY OF THE MONTH +++ EOF ============================================================================= PHUK MAGAZINE - Phile 10 of 10 ============================================================================= ----- OUTRO ----- Well this issure is finally finished and I hope you enjoyed it ! Hopefully there has been a general round up of the phreaking / hacking scene as it is happening in the UK . Although if you think a certain topic has not been covered the why not submit an article for PH-UK and it will go in the next issure . The only way this E-zine is going to survive is by people sending us snippets of news, articles, code, numbers, hints, tips and general ideas to keep the ball rolling. Send all articles, flames, Letters of Comment etc etc to PHUK magazine, anon93143@anon.penet.fi, OR speak to any of the PHUK crew at any London 2600 meeting ......... Anyhow, next month we have the following goodies for you ....we hope ! Green Boxing - DrKaos & TheGoat BT Computer Security Manual Part III Tracing people - Death's Apprentice Something on Novell Networks ... Some trash from BT wastebins .... Mecury Mailboxes .... UK News ....