Site hosted by Angelfire.com: Build your free website today!

Home Contents Search Feedback Download

Controls
PC Fundamentals Systems Controls DBMS Programming Networking SDLC E-commerce Audit in MIS Disaster Recovery Compiled by Muhammad Ahsan Shahzad

Security4one

IT audit training

IT Security

Baseline Controls

IT SECURITY: BASELINE CONTROL

Contents

1. FIRE PROTECTION................................................................................

2. WATER PROTECTION .........................................................................

3. DISASTER & DAMAGE PROTECTION ...........................................

4. CONTINUITY OF OPERATION .........................................................

5. PHYSICAL ACCESS CONTROL........................................................

6. PERSONNEL ............................................................................................

7. THEFT PROTECTION............................................................................

8. DOCUMENT PROTECTION ................................................................

9. EQUIPMENT FAILURE PROTECTION ..............................................

10. POWER PROTECTION.......................................................................

11. SOFTWARE CHANGE CONTROL...................................................

12. TECHNICAL ACCESS CONTROL ..................................................

13. INPUT / OUTPUT CONTROL............................................................

14. NETWORK PROTECTION.................................................................

15. SECURITY ADMINISTRATION ........................................................

16. SOFTWARE DISTRIBUTION............................................................

17. COMPUTER OPERATOR PROCEDURES......................................

18. NETWORK OPERATOR PROCEDURES ........................................

19. SYSTEM PROGRAMMER CONTROLS .........................................

20. APPLICATION DEVELOPMENT CONTROLS..............................

21. USER CONTROLS................................................................................

22. MAINTENANCE CONTROLS............................................................

23. SECURITY TESTING............................................................................

24. CONTINGENCY PLANNING ...........................................................

25. BACK-UP .............................................................................................

26. STORAGE MEDIA CONTROLS ....................................................

27. INFILTRATION PROTECTION........................................................

28. FINANCIAL ACCOUNTING...............................................................

29. DATABASE PROTECTION ..............................................................

IT SECURITY: BASELINE CONTROL

Baseline Controls for IT systems

1. FIRE PROTECTION

1.1 ASPECT: PHYSICAL

1.1.1 SITE/BUILDING FIRE PREVENTION

For equipment using standard 13 Amp socket outlets, a sufficient number of switched socket outlets should be provided and located in convenient positions to reduce the need for extension leads.

Each item of equipment should be protected by an appropriate fuse or circuit breaker.

1.1.2 SITE/BUILDING EVACUATION

Easily accessible fire exits with outward opening fire doors and panic bars should be provided.

1.1.3 SITE/BUILDING FIRE FIGHTING

Adequate fire fighting equipment, including appropriate types and quantities of fire extinguishers and fire blankets should be provided.

All fire fighting equipment should be located in easily accessible and strategic locations.

1.1.4 ROOM FIRE DETECTION AND ALARMS

Automatic smoke detectors and alarms should be installed in appropriate positions to provide early detection and alarm of the presence of smoke.

Where appropriate, manually operated fire alarms should be provided for staff to raise an immediate warning of fire to other areas.

1.2 ASPECT: PROCEDURAL

1.2.1 SITE/BUILDING FIRE PREVENTION & CONTROL

There should be:

a) a fire prevention programme with designated fire and safety officers with specified responsibilities;

b) staff training in the use of fire fighting and Protection techniques;

c) regular testing and maintenance of fire procedures and equipment with particular attention to building evacuation;

d) regular testing of the fire alarm, ensuring that it can be heard in all parts of the building;

e) documented fire protection instructions prominently displayed including a floor plan of fire equipment and exits, etc;

f) rules to prohibit the wedging of fire doors;

g) if required, a specific area where smoking is permitted, with sand bins or deep non-combustible ashtrays which are cleaned on a regular basis;

h) a current fire certificate for the building. If not, seek advice from the fire authorities to ensure that appropriate interim measures are taken;

i) procedures to ensure that the fire authorities are informed if building

alterations are likely to have a material impact on the fire precautions;

j) regular cleaning beneath raised flooring and other areas where inflammable waste materials may accumulate;

k) no combustible materials stored in or near critical or hazardous areas.

2. WATER PROTECTION

2.1 ASPECT: PHYSICAL

2.1.1 SITE/BUILDING PROTECTION

Where possible, the site/building should be located above the local flood level.

Easily accessible and clearly marked local shut-off valves should be installed for room/installation water supplies and sprinkler systems (see also, DISASTER & DAMAGE PROTECTION, PHYSICAL, Section 1.1). There should be adequate site/building drainage facilities.

2.2 ASPECT: PROCEDURAL

2.2.1 ROOM WATER SUPPLIES

Locally installed water supplies, facilities and protective controls eg. water supply connections/pipes, sinks, taps, stop cocks or leakage detection devices etc, should be regularly checked.

The site/building plans detailing the location and function of water supplies, facilities and protective controls should be kept up to date.

3. DISASTER & DAMAGE PROTECTION

3.1 ASPECT: PROCEDURAL

3.1.1 SITE/BUILDING PROTECTION

Criteria for the selection of sites/buildings should include minimum vulnerability to:

a) strong wind or hurricane;

b) lightning impacts;

c) general subsidence;

d) earthquake;

e) landslide;

f) flooding;

g) snow or ice damage;

h) explosion;

i) corrosive vapour;

j) traffic impact ie. vehicle or aircraft;

k) Radio/TV/RADAR transmitter interference.

Accommodation for IT systems (ie. equipment and media) should be located away from public access/view and as safe as possible from any significant threats from vandals, rioters, terrorists etc.

Accommodation with large windows should be avoided and Personal Computers, input/output display/printer terminals should be kept out of general view.

3.1.2 CONTROL OF GOODS IN

On delivery, all IT assets should be checked for damage and the relevant details entered in an asset register (see also, THEFT PROTECTION, PROCEDURAL, Section 1.4 and CONTINGENCY PLANNING, PROCEDURAL, Section 2).

NB Further information relating to Personal Computers etc, is contained in the CCTA/ITSL book "Protection of Personal Computers" ISBN 0 946683 24 7.

3.2 ASPECT: PHYSICAL

3.2.1 SITE/BUILDING FACILITIES

There should be clearly marked and accessible emergency shut off switches/controls for the site/building electrical, gas and water supplies (see also, POWER  PROTECTION, PHYSICAL, Section 2.1 and WATER PROTECTION, PHYSICAL, Section 1.2).

3.2.2 REPLACEMENT ASSETS

As far as possible all critical replacement assets should be held at a physically separate location along with a contingency plan for their use (see also, CONTINGENCY PLANNING, PROCEDURAL).

3.2.3 LIGHTNING PROTECTION

Buildings should be inspected to ensure compliance with BSI standard BS6651. In areas particularly prone to lightning care should be taken to ensure that all external data cables are protected by appropriate screening and the application of suitable lightning filters in line with the supplier's recommendations.

4. CONTINUITY OF OPERATION

4.1 ASPECT: PROCEDURAL

4.1.1 CONTINUITY PROTECTION

Dependence on specific individuals for critical functions should be avoided. All lock combinations, duplicate keys, spare tokens and details of system passwords should be held securely and centrally accessible to authorised personnel (see also, PHYSICAL ACCESS CONTROL, PROCEDURAL, Section 1.7 and CONTINGENCY PLANNING, PROCEDURAL, Section 1). All critical functions and relevant procedures should be well documented as part of a contingency plan and held securely and centrally accessible to named authorised personnel (see also, CONTINGENCY PLANNING, PROCEDURAL, Section 1). For areas to which normal access may be denied by external events (e.g. fire in an adjacent building or room rendering the installation unsafe) investigation into alternative arrangements should be made and the results included as part of the overall contingency planning exercise (see also, CONTINGENCY PLANNING, PROCEDURAL, Section 3).

4.1.2 RECOVERY PROCEDURES

Procedures should be in place to ensure that after a system failure or discontinuity in service, recovery is achieved without compromising the security of data. For multi-user systems, users should be notified when the system is operational after recovery.

5. PHYSICAL ACCESS CONTROL

5.1 ASPECT: PHYSICAL

5.1.1 SITE/BUILDING/ROOM ACCESS CONTROL

There should be adequate protection for the site/building, gates and/or doorways including approved locks. The gates/doors should be closed and locked outside working hours and/or when unattended.

Where appropriate, there should be adequate doorway protection for rooms where IT assets are accessible during working hours, including an approved lock to be used when the room is unattended.

Windows in unoccupied areas should remain closed and appropriately locked.

5.1.2 RESOURCE RESTRICTION

Where appropriate, processing equipment that is continuously powered should be contained within a lockable enclosure or cabinet that is appropriately ventilated.

5.2 ASPECT: PROCEDURAL

5.2.1 SITE/BUILDING/ROOM ACCESS CONTROL

Identification passes should be shown on each entry to, and exit from the site/building by all staff. Unrestricted access should be allowed only for authorised personnel on production/display of valid identity card.

Visitors should be issued with designated passes and where appropriate, escorted at all times by a trusted member of staff.

A date and time log of entry and departure of visitors should be maintained. The log should include details of host. All staff should be instructed to challenge or report unrecognised or unauthorised

persons. There should be checks to ensure that all visitors have been signed out by official closing time. A list of all key holders and authorised people with unrestricted access should be maintained and held centrally within the site/building (see also, CONTINUITY OF OPERATION, PROCEDURAL, Section 1.2 and CONTINGENCY PLANNING, PROCEDURAL, Section 3). Procedures for the allocation, usage and return of keys and identity cards/passes, including their recovery on termination of employment should be implemented.

Any spare Personal Computers or terminals should be secured against unauthorised

use or removal from the installation.

NB. Further information relating to Personal Computers etc, is contained in the

CCTA/ITSL book "Protection of Personal Computers" ISBN 0 946683 24 7.

IT SECURITY: BASELINE CONTROLS

Release October 1997 9

6. PERSONNEL

6.1 ASPECT: PROCEDURAL

6.1.1 SECURITY AWARENESS AND TRAINING

There should be a security awareness programme for all staff supported by specific training as appropriate (further information is contained in the CCTA/ITSL book "Awareness Programmes" ISBN 0 946683 62 X).

Contracts of employment, Job Descriptions and Terms of Reference should detail all security responsibilities and authorities. 6.1.2 PERSONNEL INVESTIGATION

Recruitment references should be asked for and checked. Gaps in employment history and claims of self-employment should be checked. Contractors, external agency staff and temporary staff should be subject to the same checks as permanent staff. Appropriate personnel practices and procedures should be implemented to ensure that staff declare any interest which may compromise the system.

6.1.3 PERSONAL ACCOUNTABILITY

Personnel should be accountable for their use of equipment, software and data. Formal warnings should be issued where their actions compromised, or were likely to compromise the security of the system. Copies of appropriate security procedures should be made available to all personnel concerned with the support and operation of the system.

6.1.4 TERMINATION AND RE-DEPLOYMENT

Where personnel are under threat of suspension or dismissal passwords should be cancelled and all system access rights should be withdrawn immediately. Where personnel are to be re-deployed to other duties passwords should be cancelled and all system access rights should be withdrawn on the day of re-deployment. Identity cards and all official keys should be retrieved from personnel on the day their employment is terminated or when they are re-deployed (See also, THEFT PROTECTION, PROCEDURAL, Section 1).

7. THEFT PROTECTION

7.1 ASPECT: PHYSICAL

7.1.1 THEFT PROTECTION

Equipment and media items should be adequately protected whilst in transit. Power locks and hard-wiring of power cables should be considered for critical/expensive assets. Equipment and media items should be secured when not in use. All critical/valuable assets should have identification markings.

7.2 ASPECT: PROCEDURAL

7.2.1 SECURITY CHECKS

Safe combinations should be changed on a regular basis and when associated personnel leave their employment or are re-deployed (see also, PERSONNEL, PROCEDURAL, Section 4). Official equipment or media should not be removed from the site/building without the requisite authority. A central register of IT system assets including hardware and software serial/licence numbers and their location should be maintained and updated by named authorised staff, as items are purchased, disposed of, or relocated. The register should include the names of persons responsible for each item (see also, DISASTER & DAMAGE PROTECTION, PROCEDURAL, Section 2.1).

8. DOCUMENT PROTECTION

8.1 ASPECT: PROCEDURAL

8.1.1 DOCUMENT CONTROL

All documents should have appropriate sensitivity markings and be stored securely. Formal procedures should be implemented for the protection of and accounting for sensitive waste output, including printer ribbons, up to and including destruction. NB. Further information relating to Personal Computers etc, is contained in the CCTA/ITSL book "Protection of Personal Computers" ISBN 0 946683 24 7. IT SECURITY: BASELINE CONTROLS

9. EQUIPMENT FAILURE PROTECTION

9.1 ASPECT: PROCEDURAL

9.1.1 EQUIPMENT USAGE

Checks should be made to ensure that manufacturers/suppliers specification for the operational environment are met and maintained. All operational areas for IT equipment should be maintained in a clean and tidy condition. Storage media should be regularly inspected for damage, wear and tear (see also, STORAGE MEDIA CONTROLS, PROCEDURAL). All media should be of the correct type for the equipment in use.

9.1.2 AIR CONDITIONING PROTECTION

The operation of any air conditioning plant, including the requirements for physical protection, standby and reporting procedures should be reviewed on a regular basis or when changes to IT equipment are planned.

10. POWER PROTECTION

10.1 ASPECT: PHYSICAL

10.1.1 POWER PROTECTION

Electrical supply equipment, fittings and plant should be installed and regularly inspected in accordance with relevant regulations and codes of good practice. Periodic checks should be made to ensure that equipment is correctly and effectively connected to a common equipotential earth. NB. Further information relating to Personal Computers etc, is contained in the CCTA/ITSL book "Protection of Personal Computers" ISBN 0 946683 24 7.

10.1.2 EMERGENCY CLOSE DOWN

To facilitate a rapid controlled shut down during an emergency power-off switches for medium to large centralised systems (with automatic power-off of any air conditioning plant) should be strategically located, by exit doors etc, and installed such that they cannot be accidentally operated.

10.2 ASPECT: PROCEDURAL

10.2.1 POWER PROTECTION

Power supplies/sockets and loading requirements should be reviewed prior to the connection of new equipment (see also, FIRE PREVENTION, PHYSICAL, Section

11. SOFTWARE CHANGE CONTROL

11.1 ASPECT: PROCEDURAL

11.1.1 CHANGE CONTROL & AUDIT

Structured programming techniques should be implemented for all software development. All newly developed software should be adequately tested prior to distribution and live operation. All changes to system software should be controlled using an appropriate Change Control Procedure. Details of changes including authorisation, nature of change and date of completion should be recorded in a change control register. All users should be formally notified in advance of the date of change and any consequent impact on user operation.Procedures to control any emergency fixes should be established to maintain adequate control over the versions in use and minimise the risk of introducing errors as a result of emergency actions.

12. TECHNICAL ACCESS CONTROL

12.1 ASPECT: HARDWARE AND SOFTWARE

12.1.1 SYSTEM ACCESS CONTROL

Any multi-user system should require users to identify themselves in a unique manner

using a combination of user identification (id) and password before they are allowed

access to any system facilities.

Denial of access and logical disconnection should occur when the allowed number of

access attempts is exceeded.

Any IT system requiring users to identify themselves should include protection of the

authentication data, to prevent it being accessed by an unauthorised user.

Passwords should never appear in clear text. Their display on screen should always be

suppressed and they should never appear in system logs or audit trails.

All password files should be encrypted.

A system generated message should appear on the terminal screen prior to use stating

that "Unauthorised access to this computer system may constitute a criminal offence".

Any multi-user system should automatically log details of:

a)user identity;

b)user events including all access attempts associated with the user identity;

c)the date(s) and time(s) of event(s);

d)the success or failure of the event;

e)details of any unauthorised activities.

Access to all system security logs and audit trails should be "read only" and restricted

to named authorised personnel.

12.1.2 RESOURCE ACCESS CONTROL

For multi-user systems or where IT resources are shared there should be:

a)controlled access between named groups of objects eg. data/files with logical

disconnection when the allowed number of access attempts is exceeded;

b)a list of users with read, write/modify, delete and execute privileges held

centrally for inspection by named authorised personnel;

c)protection of the resource authentication data, to prevent it being accessed by

unauthorised users.

IT SECURITY: BASELINE CONTROLS

Release October 1997 16

12.2 ASPECT: PROCEDURAL

12.2.1 SYSTEM ACCESS CONTROL

Use of identification and passwords should be supported by appropriate procedures

which detail:

a)length and format of passwords;

b)frequency of change;

c)change control;

d)protection of the confidentiality of identities and passwords;

e)the means of exit from the system at the end of a session or under emergency

conditions;

f)the circumstances under which alternative or back-up staff will be allowed

access and what rights they will be given.

NB. Further information is contained in the CCTA/ITSL "Password Systems for

Access Control" ISBN 0 946683 32 8)

There should be procedures to re-enforce any technical access controls for Personal

Computers/terminals. These should reflect the value and sensitivity of data handled and

include the authorisation of each user (see also, PHYSICAL ACCESS CONTROL,

PROCEDURAL).

12.2.2 RESOURCE ACCESS CONTROL

There should be procedures to ensure that access permissions to files and data storage

areas etc, are only assigned by authorised users or owners (see also, STORAGE

MEDIA CONTROLS, PROCEDURAL);

Consideration should be given to the use of naming conventions for critical files and

programs on medium to large systems.

IT SECURITY: BASELINE CONTROLS

Release October 1997 17

13. INPUT / OUTPUT CONTROL

13.1 ASPECT: HARDWARE AND SOFTWARE

13.1.1 DATA INTEGRITY

For applications where accuracy and completeness of data are priority requirements

there should be:

a)facilities to log, count and total data input, output, transfers, transmissions or

transactions occurring including reports showing which have been accepted or

rejected,

b)facilities to print control totals for subsequent reconciliation checks.

c)data validation and sequencing checks.

d)facilities to prevent inadvertent duplication of input, output, transfers,

transmissions or transactions.

(see also, FINANCIAL ACCOUNTING, HARDWARE AND SOFTWARE,

Section 3)

13.2 ASPECT: PROCEDURAL

13.2.1 DATA INTEGRITY

For applications where accuracy and completeness of data are priority requirements

there should be:

a) a manual check of signatures on input documents against the

authorised signatory list to confirm grade and authority.

b) procedures to control the correction and re-submission of input errors

and rejects.

c) use of the two person rule for critical input/output activities.

d) effective safeguards for data pending delivery, collection or

transmission.

e) use of safe delivery/transmission methods with up to date distribution

lists.

f) logging receipt of data items prior to input to the system.

g) reconciliation to input (by total and/or item) of any media output

produced by external bureaux before release is authorised.

h) investigation and reporting of any missing or out of sequence file/data

items.

IT SECURITY: BASELINE CONTROLS

Release October 1997 18

i) secure storage of pre-printed financial/sensitive stationery.

j) reconciliation of output totals (item counts/hash totals/control totals) to input

totals.

k) regular stocktaking of pre-printed financial/sensitive stationery to reconcile

balances to records of delivery and issues.

l) reconciliation of issued pre-printed financial/sensitive stationery in relation to

that used, spoiled and returned.

m) reconciliation of returned cashed cheques and payable orders against original

output and control records, all discrepancies being investigated.

n) serial numbering of pre-printed financial/sensitive stationery.

(see also, FINANCIAL ACCOUNTING, PROCEDURAL)

IT SECURITY: BASELINE CONTROLS

Release October 1997 19

14. NETWORK PROTECTION

14.1 ASPECT: COMMUNICATIONS

14.1.1 DATA PROTECTION

There should be:

a) appropriate network access control including unique user identification

and authentication;

b) denial of access and logical disconnection when the allowed number of

access attempts is exceeded.

c) a message/transaction authentication facility for financial and sensitive

data transmissions;

d) a system generated message which should appear on the terminal

screen prior to access stating that "Unauthorised access to this network

may constitute a criminal offence";

e) a facility at input and output stages to automatically check the

completeness and accuracy of all data transmissions;

f) a mechanism to ensure that user access to information in transit on the

network is prohibited.

14.1.2 NETWORK MANAGEMENT

There should be a network management system/facility for the monitoring and control

of the network with:

a] controlled access to network configuration and administrative data.

b] back-up for administrative data (eg. routing tables) and software.

Access to user information in transit or temporary storage on the network should be

prohibited under normal operating conditions.

14.1.3 AVAILABILITY PROTECTION

There should be sufficient network capacity to handle peak traffic loadings.

Network equipment and cabling should be protected against inadvertent physical

damage or interference.

14.1.4 DIAL-UP PROTECTION

Where dial-up lines are in use:

a) the identity of remote users should be authenticated.

b) an appropriate Port Protection Device (PPD) should be used.

IT SECURITY: BASELINE CONTROLS

Release October 1997 20

c) the number of unsuccessful access attempts should be limited.

d) connections should only be made after a successful dial-back.

e) communications lines should be automatically disconnected when a

session ends.

NB. Further information is contained in the CCTA/ITSL document "Protection of

Dial-up Communication Ports" ISBN 0 946683 26 3 and "Protection of

Remote Service Links" ISBN 0 946683 23 9.

14.2 ASPECT: PROCEDURAL

14.2.1 NETWORK ACCESS CONTROL

User identification and passwords should be supported by appropriate procedures

which detail:

a) length and format of passwords;

b) frequency of change;

c) change control;

d) protection of the confidentiality of identities and passwords;

e) the means of exit from the system at the end of a session or under

emergency conditions;

f) the circumstances under which alternative or back-up staff will be

allowed access and what rights they will be given.

NB. Further information is contained in the CCTA/ITSL "Password Systems for

Access Control" ISBN 0 946683 32 8)

14.2.2 NETWORK MANAGEMENT

There should be a network management function to monitor and control the network

configuration.

There should be procedures to govern:

a] access to the network management system/facility;

b] the network configuration and administration;

c] the back-up of administrative data (eg. routing tables) and software.

For WANs, there should be regular checks on the integrity (completeness and

accuracy) of communications software and routing tables in network management

centres and nodes.

Periodic checks of traffic volumes should be made to protect against over utilisation.

Frequent, persistent or unusual network errors should be reported and investigated.

IT SECURITY: BASELINE CONTROLS

Release October 1997 21

14.2.3 DATA CONFIDENTIALITY

Specialised, test and monitoring equipment such as circuit testers, data analysers,

patching equipment and data scopes should be stored securely and their usage strictly

controlled.

Any unauthorised attempts to access network facilities or user data should be reported

and investigated.

14.2.4 DIAL UP PROTECTION

Procedures should be established to govern the use of dial-up lines, including:

a) staff responsibilities;

b) the controlled distribution of telephone numbers;

c) telephone numbers not displayed on modems;

d) the use of PABX;

e) the controlled start up and close down of connections.

NB. Further information is contained in the CCTA/ITSL document "Protection of

Dial-up Communication Ports" ISBN 0 946683 26 3 and "Protection of

Remote Service Links" ISBN 0 946683 23 9.

IT SECURITY: BASELINE CONTROLS

Release October 1997 22

15. SECURITY ADMINISTRATION

15.1 ASPECT: PROCEDURAL

15.1.1 SECURITY ADMINISTRATION

A Security Administrator should be appointed with clearly identified, defined and

allocated duties which should include responsibility for ensuring that the procedural

controls identified in the following sections are implemented and effectively

maintained.

All functions performed by a Security Administrator should be logged and subject to

audit.

Security administration duties should not conflict or be compromised by other duties.

15.1.2 MISUSE PROTECTION

The use of unauthorised software should be prohibited.

Authorised software should be checked to ensure there are no irregularities prior to

installation and installed in accordance with the licensing agreement (see also,

SOFTWARE DISTRIBUTION, PROCEDURAL, Section 1.1).

Where possible, all Personal Computers and related equipment should be switched off

at the end of each day's use.

15.1.3 MONITORING MISUSE OF RESOURCES

Procedures should be in place for:

a) the regular inspection of system security logs;

b) the investigation and reporting of any incidents or exceptions to senior

management responsible for the areas in which the security breaches

occur.

c) the review, maintenance and secure storage of documented audit

trails and files.

Monitoring procedures should be reviewed on a regular basis to ensure their

effectiveness.

15.1.4 DATA REGISTRATION

All data files and programs should be owned by a nominated user and registered.

IT SECURITY: BASELINE CONTROLS

Release October 1997 23

16. SOFTWARE DISTRIBUTION

16.1 ASPECT: PROCEDURAL

16.1.1 SOFTWARE DISTRIBUTION

Procedures should be in place to check all in coming software for irregularities and

compatibility with existing hardware and software. Where possible, this should be

conducted on an isolated system. Software to be delivered or distributed to other

locations or outside organisations should be integrity checked in a similar manner.

Wherever appropriate, all media containing master software should be write protected.

For medium to large systems, the establishment and maintenance of a Master Software

Library (MSL) should be considered.

NB. Further information is contained in the CCTA/ITSL "Virus and Other

Malicious Software" ISBN 0 946683 30 1

IT SECURITY: BASELINE CONTROLS

Release October 1997 24

17. COMPUTER OPERATOR PROCEDURES

17.1 ASPECT: PROCEDURAL

17.1.1 OPERATOR PROCEDURES

There should be standard procedures for all system operator functions, including

separation of duties as appropriate.

Where shift work exists handover procedures including separate passwords and formal

sign-offs for each operator should be implemented.

The duties of operators, application programmers and system support staff should be

separated.

17.1.2 ACCESS CONTROLS

Operator access to system utilities should be strictly controlled.

IT SECURITY: BASELINE CONTROLS

Release October 1997 25

18. NETWORK OPERATOR PROCEDURES

18.1 ASPECT: PROCEDURAL

18.1.1 OPERATOR PROCEDURES

Procedures should be implemented for:

a) Start up and close down of circuits and connections;

b) monitoring and re-configuring of circuits;

c) patching to circuits;

d) patching to equipment;

e) the use of test equipment;

f) the reporting of errors/incidents to the network supervisor/manager;

g) the supervision of temporary contractors, maintenance and support

staff by permanent staff see also, MAINTENANCE CONTROLS,

PROCEDURAL);

h) the appointment of trusted, authorised and responsible staff for the

control of Batch or Electronic Funds Transfers (EFT) using the 2

person rule for critical/sensitive transfers (see also, INPUT/OUTPUT

CONTROLS, PROCEDURAL and FINANCIAL ACCOUNTING,

PROCEDURAL).

IT SECURITY: BASELINE CONTROLS

Release October 1997 26

19. SYSTEM PROGRAMMER CONTROLS

19.1 ASPECT: PROCEDURAL

19.1.1 CHANGE CONTROLS

All system testing of changes or developed software should be conducted with

simulated/non-live data.

The system security officer should sign off changes to security software.

Procedural controls should be implemented to govern the use of emergency software

patches.

Version control procedures should be implemented where multiple versions of the

same system software exist.

19.1.2 PERSONNEL PROCEDURES

No system programmers should be involved in application work or vice versa.

System programmers should be prohibited from updating live systems.

19.1.3 ACCESS CONTROL

Procedures should be in place to govern the use of utilities that could by-pass other

control measures.

Use of Assembler Language programming should be strictly controlled.

19.1.4 FAILURE RECOVERY

Procedures should be in place to revert system software to a previous version in a

controlled manner if serious problems occur.

Procedures should be in place to govern the implementation and maintenance of backup

software libraries.

19.2 ASPECT: PROCEDURAL

19.2.1 CHANGE CONTROL

All testing of changes to current or developing application software should be

conducted with simulated/non-live data.

The system security officer should sign off changes to any security software.

Procedural controls should be implemented to govern the use of emergency software

patches.

Version control procedures should be implemented where multiple versions of the

same system software exist.

IT SECURITY: BASELINE CONTROLS

Release October 1997 27

19.2.2 DEVELOPMENT STANDARDS

Formal standards for the development of application software should be invoked.

All programs should be documented to a formal standard.

Application programmers should be prevented from making amendments to

production/operational versions of application software. Any necessary amendments

should be authorised and made on a copy of the production/operational version and in

a test or development environment.

Programmers requiring access to the source code of operational programs should be

strictly controlled.

Testing standards should be developed and implemented including:

a) user acceptance testing;

b) parallel and/or pilot running covering both system and clerical

functions/facilities.

Software and documentation should be formally reviewed and accepted by users.

19.2.3 PERSONNEL PROCEDURES

Application programmers should not be involved in the maintenance or correction of

system software.

Application programmers should be prohibited from updating live systems.

Programmers should be prevented from initiating accounting transactions or amending

data (see also, FINANCIAL ACCOUNTING, PROCEDURAL, Section 2).

19.2.4 ACCESS CONTROL

Procedures should be in place to govern the use of utilities that could by-pass other

control measures.

Use of Assembler Language programming should be strictly controlled.

19.2.5 FAILURE RECOVERY

Procedures should be in place to revert application software to a previous version in a

controlled manner if serious problems occur with the current version.

Procedures should be in place to govern the implementation and maintenance of backup

software libraries.

IT SECURITY: BASELINE CONTROLS

Release October 1997 28

20. APPLICATION DEVELOPMENT

CONTROLS

20.1 ASPECT: PROCEDURAL

20.1.1 DEVELOPMENT STANDARDS

Development standards should include:

a) use of formal methods/techniques for development of application

systems;

b) use of formal project management method/technique to control the

development of application systems;

c) involvement of users at appropriate stages of the development process;

d) formal documentation of all application systems including detailed

configuration and functionality;

e) user involvement in planning and acceptance testing;

f) parallel and/or pilot running covering both system and clerical

functions/facilities;

g) independent quality assurance and change control.

20.1.2 AUTHORISATION

The completion of all major phases of a development project should involve a review

by senior management and a formal, documented agreement that the next stage can

commence.

Users and project/operational management representatives should formally review and

accept any system before it becomes operational.

IT SECURITY: BASELINE CONTROLS

Release October 1997 29

21. USER CONTROLS

21.1 ASPECT: PROCEDURAL

21.1.1 TRAINING & OPERATING PROCEDURES

All users should be trained in system operation and security.

All users should be provided with documentation covering system and security

operating procedures.

User management should ensure that system and security operating procedures are

being adhered to.

21.1.2 USER ACCESS CONTROL

User access should be limited to predefined functions and facilities with no access to

any programming facilities.

IT SECURITY: BASELINE CONTROLS

Release October 1997 30

22. MAINTENANCE CONTROLS

22.1 ASPECT: PROCEDURAL

22.1.1 MAINTENANCE ACCESS CONTROLS

Maintenance of systems should be carried out by vetted or supervised engineers.

Access of maintenance personnel should be controlled using identity checks, and where

necessary escorting and supervision by permanent staff (see also, CONTINUITY OF

OPERATION, PROCEDURAL, Section 2 and CONTINGENCY PLANNING,

PROCEDURAL, Section 3).

22.1.2 MAINTENANCE PROCEDURES

There should be:

a) clearly defined services contract for maintenance, including specific

responsibilities and authority of nominated maintenance personnel;

b) clearly defined escalation procedures for resolving persistent problems;

c) procedures to ensure all engineering media used for maintenance

purposes is integrity checked and write protected;

e) documented records of all maintenance work;

f) procedural controls for the removal of any items of equipment,

particularly any with storage facilities.

IT SECURITY: BASELINE CONTROLS

Release October 1997 31

23. SECURITY TESTING

23.1 ASPECT: PROCEDURAL

23.1.1 SECURITY TESTING

Security mechanisms should be independently tested and proved to work as claimed in

the system documentation.

Test objectives should include the finding of obvious flaws that would allow a breach

in the isolation of resources, or would permit unauthorised access to audit or

authentication data.

IT SECURITY: BASELINE CONTROLS

Release October 1997 32

24. CONTINGENCY PLANNING

24.1 ASPECT: PROCEDURAL

24.1.1 CONTINUATION OF OPERATION

A contingency plan should be in place to allow for recovery and where appropriate the

use of alternative IT facilities to re-establish and maintain the required level of service.

Procedures should be in place to test, review and update the contingency plans and to

maintain security under contingency conditions.

Contingency plans and vital system documentation should be stored securely and

copies held remotely.

24.1.2 INVENTORIES

As part of a contingency plan a system inventory should be produced and updated on a

regular basis. The inventory should contain details of all items of hardware, software,

media and system documentation together with details of the person responsible for

each item, the accommodation requirements and suppliers/support organisations (see

also, DISASTER & DAMAGE PROTECTION, PROCEDURAL, Section 2 and

THEFT PROTECTION, PROCEDURAL, Section 1.4).

24.1.3 POST DISASTER ACCESS CONTROL

Where individuals have unrestricted access for the purpose of recovery from a disaster,

all critical data, programs and documentation should be secured.

Checks should be conducted on the authorisation and authenticity of individuals

entering sensitive areas for the purpose of recovery after a disaster (see also,

CONTINUITY OF OPERATION, PROCEDURAL, Section 1.4).

IT SECURITY: BASELINE CONTROLS

Release October 1997 33

25. BACK-UP

25.1 ASPECT: PROCEDURAL

25.1.1 BACK-UP

Arrangements should be made for the back-up of data on suitable media, at

appropriate intervals. The number of back-up copies to be retained should reflect the

value and sensitivity of the data and how frequently it changes.

The most recent back-up copy should be stored securely as part of a contingency plan.

At least one back-up copy should be stored remotely with the same level of protection

(see also, CONTINGENCY PLANNING, PROCEDURAL).

Back-up media should be copied before it is used to restore data.

Back-up procedures should be reviewed on a regular basis.

Regular tests to restore data from back-up media should be carried out and should

include media compatibility checks when equipment changes.

Infrequently used data files should be archived.

The period of retention of backed-up or archived data should be determined by

business, legal, or audit availability requirements.

Regular checks should be conducted on a sampling basis to ensure the integrity and

availability of archived data files.

All essential documentation should be copied and stored securely.

IT SECURITY: BASELINE CONTROLS

Release October 1997 34

26. STORAGE MEDIA CONTROLS

26.1 ASPECT: PROCEDURAL

26.1.1 DISPOSAL, REPAIR OR REUSE

Procedures should be in place for the clearance of storage media containing

financial/sensitive information on disposal, re-use or maintenance.

NB. Further information is contained in the CCTA/ITSL book "Storage Media: Its

Disposal, Repair or Reuse" ISBN 0 946683 25 5.

IT SECURITY: BASELINE CONTROLS

Release October 1997 35

27. INFILTRATION PROTECTION

27.1 ASPECT: PROCEDURAL

27.1.1 INVESTIGATION PROCEDURES

Procedures should be in place to investigate suspected system infiltration.

All evidence including audit trails of suspected system infiltration should be filed

securely.

Access mechanisms/facilities used for infiltration should be removed immediately.

NB. Further information is contained in the CCTA/ITSL book "Hacking" ISBN 0

946683 31 X

IT SECURITY: BASELINE CONTROLS

Release October 1997 36

28. FINANCIAL ACCOUNTING

28.1 ASPECT: HARDWARE AND SOFTWARE

28.1.1 SYSTEM RECONCILIATION

Accounting and budgetary control systems should be balanced and reconciled monthly.

Where appropriate, software should be in place to restructure a financial database at

the beginning of each financial year.

28.1.2 USAGE MONITORING

Accounts which are no longer required should be marked as inactive.

28.1.3 DATA INTEGRITY

All input batches causing debit or credit postings should be subject to batch control

totalling, with programmed controls to prohibit the input of an unreconciled batch (see

also, INPUT/OUTPUT CONTROLS, HARDWARE AND SOFTWARE, Section 1).

In non-batch systems programmed controls should be in place to identify and prohibit

unauthorised input.

All debit and credit postings should result in an acknowledgement being produced for

issue to the originator.

28.2 ASPECT: PROCEDURAL

28.2.1 SYSTEM RECONCILIATION

The balancing and reconciliation of accounting and budgetary control systems should

be checked on a monthly basis.

At the end of each financial year all suspense accounts should be cleared.

Procedural and software controls to ensure all transactions should be posted to the

correct financial year.

Clerical and computer records relating to incorrect or unidentified remittances should

be investigated by appointed staff.

Detailed procedures should be in place for the definition and administration of

adjustments and write offs.

28.2.2 USAGE MONITORING

Procedural and software controls should be in place to prohibit the erasure of accounts

to which transactions have been posted. Any attempts should be logged.

Procedures should be in place to ensure that all conditions for erasure are satisfied

when an account is no longer required.

IT SECURITY: BASELINE CONTROLS

Release October 1997 37

28.2.3 DOCUMENT RECONCILIATION

In cases where a payable order has gone astray and a replacement is requested an

indemnity should be issued, signed by the requester, and checked using the 2 person

rule, before a replacement is issued.

Valid computer printed payable orders should be revoked before a re-issue or renewal

is issued.

28.2.4 SECURE DESTRUCTION

Reconciled paid orders should be cancelled and mutilated prior to destruction.

The two person rule should be invoked for the certification and destruction of paid

orders.

(see also, INPUT/OUTPUT CONTROLS, PROCEDURAL and STORAGE MEDIA

CONTROLS, PROCEDURAL)

IT SECURITY: BASELINE CONTROLS

Release October 1997 38

29. DATABASE PROTECTION

29.1 ASPECT: HARDWARE AND SOFTWARE

29.1.1 DATA INTEGRITY

Procedures should be in place:

a) to periodically check the completeness and accuracy of data/files,

Input/Output functions and the temporary or permanent storage of data;

b) for the controlled reorganisation and logical restructuring of the

database to cope with the deletion or modification of records;

c) to protect against errors or inconsistencies that may be caused by

concurrent data access attempts.

File balancing and consistency checks should be implemented:

a) at the start and end of the day on a real-time system;

b) immediately prior to a checkpoint or back-up;

c) at the end of batch processing;

d) after each database 'housekeeping' run.

29.1.2 AUTOMATIC RECOVERY

Facilities should be implemented to enable automatic recovery of the Database

Management System (DBMS) and all data/files such that normal operating conditions

can be resumed to the point just prior to the failure of the system.

29.2 ASPECT: PROCEDURAL

29.2.1 DATABASE ADMINISTRATION

A Database Administrator should be appointed having responsibility for:

a) the day to day integrity and consistency of the database;

b) developing, maintaining and controlling the data dictionary, data

schema, and data element inter-relationship;

c) monitoring day-to-day file or database activity to avoid processing

overloads etc;

d) supervising any database housekeeping and any recovery activities,

verifying results and operational status;

e) the review of system/transaction logs to detect unauthorised

activities and any irregular activities;

IT SECURITY: BASELINE CONTROLS

Release October 1997 39

f) establishing and maintaining a test file or database environment

for testing system amendments;

g) liaison with the project or installation/system IT Security Officer on

the overall security of the database/files;

h) authorising the use and monitoring the results of any utilities or tools

which could change the database system.

29.2.2 DATABASE RECOVERY

Corresponding transaction and control files should be held on a generation basis for

recovery purposes.

Notice: These notes are intended to be a supplement, not a substitute, to attending class.

 

 

Home ] Security4one ]

Send mail to webmaster@it4castudents.cjb.net with questions or comments about this web site.
Copyright © 2003 Muhammad Ahsan Shahzad
Last modified: 05/17/03