|
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 96. 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 1612.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 1713. 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 18i) 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 1914. 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 20c) 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 2114.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 2215. 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 2316. 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 2417. 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 2518. 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 2619. 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 2719.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 2820. 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 2921. 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 3022. 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 3123. 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 3224. 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 3325. 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 3426. 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 3527. 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 3628. 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 3728.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 3829. 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 39f) 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.
|
|
Send mail to
webmaster@it4castudents.cjb.net with
questions or comments about this web site.
|