Security policy

6
Computers & Security, 9 (1990) 605-610 Security Policy Simon Banks The Royal London Mutual InsuranceSociety, Middlesborou& Colchester, Essex, U.K. WC frequently hear a lot about the need for security, indeed there are now security products on the market to more than protect mosr sysrcms whether they be on mainframe, mini or microcom- puter systems. While each of these products is usually designed to carry out a specific task, the way in which these controls are introduced is of prime importance as they are only a means to an end. All too often it is thought that all that is required is co inrroduce some piece of software or hardware and cvery- thing will be a bed of roses. In order to ensure that security is implc- mented in a controlled manner it is essential that there is a formal policy. What follows is my rcprcsenrations of what this policy should contain. Introduction s WC arc all aware it is a WC11 A acccptcd fact that it is important to protect the infor- mation critical to an organiza- Editor’s note: A computer sccuriry policy should form part of an overall corporate security policy. ~vcn that is not enough. It should be understandable, preferably with input from people charged with rcsponsibilitics contained in it. It should not be a substitute for monitoring or planning changes relevant to computer security. This guide to a policy is an appetizer to taking the task of providing policy more seriously. Commcnrs and views are invircd on how to improve methods. tion, in the same way that it is important to drive on the left in Britain. Unlike the driving scenario which has regulations to support it, the security of data is all too often left up to individual judgment. AS with the driving problem, WC all know what the solutions arc to secure the data (that is why some of us drive on the left and the rest of the world drive on the right). Identifying these rcquire- ments is therefore not good enough on its own. In order to enforce controls it is ncccssary to have a formal policy which is the base for all the con- trols (in the same way the con- trols over the traffic that dctcrminc which side of the road WC drive on also rcgulatc the rules relating to our conduct on the hi hway). Thcrcforc the riced for a fBorma1 policy and the intro- duction of controls must bc rccognizcd and cndorscd at the highest lcvcl of managcmcnt, indeed the policy statcmcnt should bc issued by the board of directors as a Company policy. Only then will it be possible to enforce the controls ncccssary to protect the data. 0167-4048/90/$3.50 0 1990, Elsevier Science Publishers Ltd. The following document should not be seen as a definitive statc- mcnt of what a security policy should look like for your Com- pany, althou h I do believe that it contains al the points that Fi should be covered and provides a sound base to work from. It is also important to’rcmember that once a security policy has been introduced it must be dis- tributed to ALL members of staff. Special attention should bc paid to ensuring that all staff that join the Company after the ?nitial issuing of the document are made fully aware of its prcscnce and their role in ensur- ing that the data arc kept safe. 1. Policy Statement (Scope) The Company and its subsid- iarics hereafter known as the Group arc heavily reliant on computer processing systems to meet their operational, financial, and information needs, in fact the computer systems arc crucial to the day-to-day operations of the Group. This reliance is such that the Group will begin to incur extra costs and/or reduced revenues 605

Transcript of Security policy

Page 1: Security policy

Computers & Security, 9 (1990) 605-610

Security Policy Simon Banks The Royal London Mutual InsuranceSociety, Middlesborou& Colchester, Essex, U.K.

WC frequently hear a lot about the need for security, indeed there are now

security products on the market to more

than protect mosr sysrcms whether they be on mainframe, mini or microcom-

puter systems. While each of these products is usually designed to carry out

a specific task, the way in which these

controls are introduced is of prime

importance as they are only a means to

an end. All too often it is thought that all

that is required is co inrroduce some

piece of software or hardware and cvery-

thing will be a bed of roses.

In order to ensure that security is implc-

mented in a controlled manner it is essential that there is a formal policy.

What follows is my rcprcsenrations of

what this policy should contain.

Introduction

s WC arc all aware it is a WC11 A acccptcd fact that it is important to protect the infor- mation critical to an organiza-

Editor’s note: A computer sccuriry policy should form part of an overall corporate

security policy. ~vcn that is not enough.

It should be understandable, preferably

with input from people charged with

rcsponsibilitics contained in it. It should

not be a substitute for monitoring or

planning changes relevant to computer

security. This guide to a policy is an appetizer to taking the task of providing

policy more seriously. Commcnrs and views are invircd on how to improve

methods.

tion, in the same way that it is important to drive on the left in Britain. Unlike the driving scenario which has regulations to support it, the security of data is all too often left up to individual

judgment.

AS with the driving problem, WC all know what the solutions arc to secure the data (that is why some of us drive on the left and the rest of the world drive on the right). Identifying these rcquire- ments is therefore not good enough on its own.

In order to enforce controls it is ncccssary to have a formal policy which is the base for all the con- trols (in the same way the con- trols over the traffic that dctcrminc which side of the road WC drive on also rcgulatc the rules relating to our conduct on the hi hway). Thcrcforc the riced for a fBorma1 policy and the intro- duction of controls must bc rccognizcd and cndorscd at the highest lcvcl of managcmcnt, indeed the policy statcmcnt

should bc issued by the board of directors as a Company policy. Only then will it be possible to enforce the controls ncccssary to protect the data.

0167-4048/90/$3.50 0 1990, Elsevier Science Publishers Ltd.

The following document should not be seen as a definitive statc- mcnt of what a security policy should look like for your Com- pany, althou h I do believe that it contains al the points that Fi

should be covered and provides a sound base to work from.

It is also important to’rcmember that once a security policy has been introduced it must be dis- tributed to ALL members of staff. Special attention should bc paid to ensuring that all staff that join the Company after the ?nitial issuing of the document are made fully aware of its prcscnce and their role in ensur- ing that the data arc kept safe.

1. Policy Statement (Scope)

The Company and its subsid- iarics hereafter known as the Group arc heavily reliant on computer processing systems to meet their operational, financial, and information needs, in fact the computer systems arc crucial to the day-to-day operations of the Group.

This reliance is such that the Group will begin to incur extra costs and/or reduced revenues

605

Page 2: Security policy

S. H. BankslSecurity Policy

when the information is not pro- duccd on schedule, or is incor- rcctly processed, or contains inaccurate data. It is thcreforc essential that the cquipmcnt, sys- tcms and data must be main- taincd in a controlled

cnvironmcnt. The cost associated with partial or complete loss of key resources, software, data and proccdurcs in extreme cases

could be catastrophic.

The policies defined in this document aim to ensure that the rcquisitc level of security is

applied in order to provide for the integrity and continuity of processing. This policy will apply to all computers within the Group. This includes mainframe, mini and personal computers, word processors and any other device which holds data elec- tronically.

2. Management

2.1 No arca of cxpcrtisc should be the sole responsibility of one person and thcrc will bc separa- tion of‘rcsponsibility for sensitive functions.

2.2 The Director rcsponsiblc for

E.D.P. will bc responsible for ensuring all aspects of the security policy arc adhcrcd to.

2.3 Managcmcnt will cnsurc

that there is compliance with the legislation that pertains to the processing of data or the opcra- tion of computer cquipmcnt, such as the Data Protection Act, the eighth principle of which

states:

Appropriate security mcasurcs will be taken against unauthorized access to. or alteration, disclosure or destruction of, personal data and against accidental loss or destruction of personal data.

2.4 Data will be made available on a regular basis as to the cffcct faults and errors have on the provision of services to users. A formal problem management system will be in place to rcducc error incidence and avoid rccur- rcncc of problems.

2.5 Effective managcmcnt and control systems will bc in place to cnsurc applications arc developed in accordance with user departments plans, and that losses to the business do not

accrue.

2.6 Effcctivc managcmcnt and control systems will bc in place to monitor performance accord- ing to standards, proccdurcs and scrvicc levels.

2.7 The Data Security Dcpart- mcnt will bc rcsponsiblc for ensuring the Group’s business is protected against fraud and misuse of information in con- ncction with a computer-based system. It will thcrcforc:

(i) Assist lint management in the design of control proccdurcs, (ii) Control, monitor and test the operation of security proccdurcs and systems,

(iii) Invcstigatc to dctcrminc the cxtcnt of any actual or potential case of computer abuse, misuse or fraud.

2.8 The Internal Audit Dcpart- mcnt in accordance with its charter is rcsponsiblc for undcr- taking an indcpcndcnt appraisal of operating pcrformancc. It may thcrcfore conduct sclcctivc evaluations of the cffcctivcness and cff&ncy of controls in operation.

2.9 Adequate insurance cover will be taken out for failure of computer hardware and resultant emergency costs.

2.10 A list of all systems will bc maintained along with users responsible for the integrity of the data (hcrcafter called the data owners).

2.11 A risk evaluation will bc carried out on all data and sys- tcms.

2.12 Line Managers (SW Appcn- dix A) arc responsible for dcfin- ing and enforcing proper control and security proccdurcs within their arcas and enforcing the proccdurcs cmbodicd in this policy statcmcnt.

2.13 Brcachcs of the policies dcfmcd in this statcmcnt will bc considered a disciplinary offcncc.

2.14 Effcctivc measures will bc in place to ensure the continua- tion of processing in the event of a disaster.

606

Page 3: Security policy

Computers and Security, Vol. 9, No. 7

2.15 Any enquiries on this policy should be directed towards the Data Security Department.

ensure all documents submitted for processing are properly authorized and that all sensitive

documents remain confidential.

safe working will have access to restricted areas.

5.3 Staff will ncvcr be allowed to

3. Software and Data Consideration should be given as to whether or not it is necessary to provide extra screening on terminals.

work alone in restricted arcas.

3.1 Intellectual property rights on all software and data will be vested with the Group.

5.4 Non-company staff will always be supervised when in a restricted area.

3.2 Auditors and computer staff will not be permitted to update live data. Knowledge about sys- tems and data will bc restricted only to those who have a genuine need to know.

3.3 There will be a formal change control procedure for acceptance of ALL software and processing procedures on opera- tional libraries.

3.4 Unauthorized copying of programs or data is forbidden.

3.5 Contracts, agreements, leases and licences with suppliers of computer software should include a provision (approved by

the Company Secretary) advising vendors of the Group’s retained property rights.

3.6 Software requirements will be completely documented prior to being developed and an effec- tive method of software con- figuration control will be applied to the requirements both during development and the life cycle of the software.

4. Integrity

4.1 A method will be in place to

4.2 Sensitive computer output will be identified and procedures

will be in place to ensure its con- fidentiality and security until it is under the user’s control.

4.3 Suitable methods of dispos- ing with computer output will

be provided.

4.4 Controls and audit trails will be designed into software appli- cations to ensure the integriry of the data and processing in them.

5.6 No person may attempt to enter an area for which hc has

not received the requisite specific authority.

5.7 Means of preventing and containing an outbreak of fire

must bc present.

4.5 All staff using computers will be instructed on their role in

5.8 Where relevant to the degree

confidentiality. of risk, alternative forms of light- ing and power must bc provided.

4.6 Adequate training will be provided to ensure authorized

accurate and timely processing takes place.

5. Physical Security

5.1 Buildings in which com- puters are housed should be pro- tected from unauthorized access.

5.2 Restricted arcas will bc defined wherever (key) resources are cited which would be at risk from accidental or malicious action. The minimum number of staff necessary for effective and

5.5 Appropriate means of sccur-

ing restricted areas against un- authorized access will bc installed according to the levels of risk.

5.9 Identity bad es arc to bc dis- played by all sta f Special badges B

to bc worn by staff authorized to enter restricted areas. All visitors should wear a visitors’ badge.

5.10 Access cards, identity or visitors’ badges which arc lost, stolen or damaged arc to bc reported IMMEDIATELY to the

person or department from which they were issued.

5.11 Where code numbers are used (i.e. in the case of digital locks), no person may divulge to another any security code or

607

Page 4: Security policy

S. H. Banks/Security Policy

combination number without specific authority from the security officer.

6. Terminal Access

0.1 Access to computer systems via terminals will be permitted only to staff so authorized by the data owners.

6.2 Appropriate methods of pre- venting accccss to computer sys- tcms by unauthorized staff will bc in place for all systems.

6.3 Security logs will be main- tained and examined regularly

for breaches or attempted brcachcs in security and failures

rcportcd to the security officer and data owner.

6.4 Any attempted or actual vio- lation of any security system will bc trcatcd as a misconduct and may result in disciplinary pro-

cccdings being taken.

6.3 Staff with terminal access authority will receive appropriate instructions regarding security matters.

6.6 Staff who lcavc the cmploy- mcnt of the Group will have their access rcvokcd as soon as their intention to lcavc is known unless otherwise authorized by a senior official. When staff change department or section their terminal access should bc rcvicwcd and amended as appro- priate.

7. Passwords

7.1 Passwords should be chosen by the individual user.

7.2 Passwords should bc rcgu- larly changed.

7.3 Where possible the password should bc tight characters long and be of the format of 1 num- bers followed by 4 letters.

7.4 Passwords such as 111 IAAAA should not bc used

nor should any password that may bc easily dcrivcd by others such as your tclephonc number

and name.

7.5 Passwords must not bc used by any person other than the owner.

7.6 Staff with terminal access authority will receive appropriate instructions regarding security matters and to the conscqucnccs of not conforming to the security policy.

8. Back-up

8.1 All data and softwarc will have on-site topics taken rcgu- larly enough to minimize dis- ruption when faults occur during processing. Back-up copies will be tested for viability at regular intervals.

8.2 If off-site topics arc cvcr to be used for back-up, they will bc copied or restored to disk or tape

bcforc any further use.

8.3 The frcqucncy of and lcvcls of on-site and off-site back-up

copies of data and software will be carried out to d&red stand- ards sufficient to ensure recovery is possible in any circumstances.

9. Contingency

9.1 Consideration will bc given to providing appropriate hard- wart and communications back- up when it can be cost cffcctivcly done.

9.2 Where contingency plans do not permit provision of any key resource, appropriate fall back procedures will be identified and documented. Copies should bc stored off-site.

9.3 The acccptablc lcvcls of scr- vice in contingent circumstances will be agreed and documented.

9.1 Appropriate contingency plans will be in place to maintain essential continuity of scrvicc in the cvcnt of the loss or partial loss of computing facilities, the objcctivc being to maintain all

the Group’s data, applications and system software; and appli- cations, technical systems and operations documentation intact. Also to provide appropriate pro- ccssing capability to meet con- tingcnt lcvcls within an acccptablc and agreed timcscalc.

9.5 Such contingency plans will bc integral with overall company contingency plans, and will be documented in multiple copies and held off-site.

608

Page 5: Security policy

Computers and Security, Vol. 9, No. 7

9.6 Contracts of employment for key staff will permit working at a contingency site.

9.7 As far as practicable, con- tingency plans will be tested at appropriate intervals.

9.8 To support a contingency plan, off-site security copies must be regularly taken of all softwarc and data. Procedures will be in place to sample that such copies are viable, both prior to, and after storage.

9.9 Operations procedures, user procedures, systems reference manuals and program specifica- tions and contingency plans are key documentation resources and will have off-site copies stored.

9.1 o Key personnel should be identified and their role in insti- gating and carrying out the con- tingency plan should be clearly documented.

10. General

10.1 Any violation of security procedures established pursuant to this policy statement will result in the instigation of disci- plinary procedures.

IO.2 Staff leaving the Group’s employment shall return all property and equipment used in conjunction with the computer systems and installations. Items such as keys, identification

badges, and card entry badges, portable computer and commu- nications equipment, manuals, documentation and other materials shall be returned to the individual employee’s Manager prior to the last day of active employment.

10.3 Theft, fraud, damage or misuse of the Group’s property, including programs and data may give rise to criminal and civil proceedings through the courts.

10.4 Deviations from procedures laid down in this policy docu- ment may only be made with the written permission of the Direc- tor responsible for this policy document.

I 0.5 Any unauthorized use-of computer equipment or time is not allowed.

10.6 Lint managers arc rcspon- siblc for computer equipment under their control and for its proper utilization.

Appendix A

List of line management positions

Controllers Printing and Stationery Internal Audit Unit Trust Administration Mortgage Administration Field Administration Field Personnel Field Staff Training/Develop-

ment Data Processing Production

Services Personnel Administration

Production Manager Accountant Secretary Deputy Solicitor Manager Broker Operations/

London Underwriting Room

Chief Surveyor Deputy Actuary Investment Manager Manager Systems Development Tax Advisor Underwriting and Claims Subsidiary Companics

I con&m receipt of a copy of this document.

I have read and understand it and the way in which it will affect my job in the Organization.

Signed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Date . . . . . ., . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (BLOCK CAPITALS)

Department . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

609

Page 6: Security policy

S. H. Banks/Security Policy

Security Policy: PC Problems

The power available on the PC in use today is equivalent to that which was in use on the main- frame computer ten years ago. It was seen fit then to keep this power over the data behind locked doors. It must therefore be appropriate to provide security on PC systems. Several additional topics thcrcforc need consider- ing.

(I) Physical Security What restrictions are there over access to areas where PCs exist or access to PCs? e.g. Keys. Key systems need identifying.

(2) Data Security How are back-ups controlled? What is the security of the data if the machine/hard disk is removed?

(3) Passwords What password standards are being applied and who is rcspon- siblc? If networks exist, who is respon- sible for setting up and main- taining access rights!

!ZEErriZhe data! How is its accuracy monitored?

Simon Banks IS a mcmbcr oirhe

Institute of lnrcrnal Auditors and has

obtained pracritioner level in the Quali-

fication for Computer Auditors. He is

Compurcr Auditor with The Royal

London Mutual Insurance Society

Liulircd based in Colchcsrer, U.K. He has

been a programmer working on a large varicry of sysrcms and he thus

describes himself as a poacher turned

gamekeeper.

Arc audits carried out on PC systems? What controls are in place for the transfer of data?

(5) Logging and Reporting Who receives reports? What logging of activity is avail- able?

(6) Contingency What back-ups of systems/data are necessary? What back-up and maintcnancc of equipment exists? Is UPS required?

610