M Software management

Transcription

1 M Software anageent This docuent is part of the UCISA Inforation Security Toolkit providing guidance on the policies and processes needed to ipleent an organisational inforation security policy. To use the Toolkit effectively it should be read alongside the Toolkit Introduction and the How to use guide and then used to develop appropriate inforation security eleents for inclusion in your organisation s policies. 1. Introduction The Software Manageent Policy sets out how the software which runs on the organisation s inforation systes is anaged. The policy includes controls on the installation and use of software, the features provided and the granting of access to software packages. In addition, it covers the aintenance of software, with appropriate procedures for upgrades, to iniise the risk to inforation and inforation systes. The policy should be failiar to all staff involved in the specification, installation and aintenance of software. 2. BS 7799 definitions and nubering Software anageent issues relating to inforation security are covered by sections , 12.1 and 12.5 of the standards docuent Protection against alicious and obile code Objective: To protect the integrity of software and inforation against obile code Where the use of obile code is authorized, the configuration shall ensure that the authorized obile code operates according to a clearly defined security policy, and unauthorized obile code shall be prevented fro executing Security requireents of inforation systes Objective: To ensure that security is an integral part of inforation systes Security requireents analysis and specification Stateents of business requireents for new inforation systes, or enhanceents to existing inforation systes shall specify the requireents for security controls Security in developent and support processes Objective: To aintain the security of application syste software and inforation Change control procedures The ipleentation of changes shall be controlled by the use of foral change control procedures Technical review of applications after operating syste changes When operating systes are changed, business critical applications shall be reviewed and tested to ensure there is no adverse ipact on organisational operations or security Restrictions on changes to software packages Modifications to software packages shall be discouraged, liited to necessary changes, and all changes shall be strictly controlled Inforation leakage Opportunities for inforation leakage shall be prevented. s o f t w a r e a n a g e e n t 118

2 3. Interrelationship between policies in this docuent and related BS 7799 references In this Toolkit, each subsection addresses a nuber of software anageent controls fro the standard. All of the controls in section 12.1 of the standards docuent are covered, as are control and the controls to in section Toolkit subsection Security anageent Change control Packaged software/systes Malicious and obile code Control(s) Security requireents analysis and specification Change control procedures Technical review of applications after operating syste changes Restrictions on changes to software packages against obile code Inforation leakage 4. Guidelines for use Security requireents analysis and specification Stateents of business requireents for new systes, or enhanceents to existing systes, ust docuent the requireents for security controls. It is iportant that inforation security issues are considered fro the outset of each developent project and an analysis of security requireents ust be carried out at the requireent analysis stage. Often, specifications focus on the autoated controls to be incorporated in the application but the need for controls in the associated anual operations should also be considered. Security requireents and controls should reflect the business value of the inforation assets involved, and the potential business daage that ight result fro a failure, absence or inadequacy of security. These considerations should be applied when evaluating all software for use in business processes and appropriate security controls ust be designed into application systes. Change control For all software that can access or use sensitive inforation, foral change control procedures should be established if inforation security is to be protected. Change control procedures should ensure that security and control procedures are not coproised, that staff are given access only to those parts of the syste that are necessary for their work, and that foral interdisciplinary agreeent and approval for the change is obtained. The change control procedures for operating syste upgrades should include a need for any supported applications to be reviewed and tested to check the security ipact of any changes. Packaged software Wherever possible, vendor-supplied software packages should be used without odification. Changes should be discouraged, but where they are seen to be necessary, the changes should be strictly controlled with the risks to inforation security fully assessed. Such changes usually iply a need for changes to future versions of the package and the ongoing support iplications need to be quantified. All changes should be fully docuented and the inforation assets afforded the necessary security protection. Malicious and obile code Malicious software includes software such as viruses, Trojans, back-doors and spyware and these ight be introduced during the ipleentation of new or upgraded software. Because of the potential security threat of such software, controls are needed to inhibit its introduction. Mobile code consists of progras, often in the for of scripts or applets, that are downloaded across the network to run on a local achine and have the potential to be alicious. The purchase, downloading, use, ipleentation or odification of any software that ight run on any syste supporting business applications, or any software that ight be used in an operational process, ust be controlled and checked to ensure that the organisation s inforation is suitably protected against such software. u c i s a i n f o r a t i o n s e c u r i t y t o o l k i t e d i t i o n 3. 0

3 5. Security anageent i. Suggested Policy Stateent The organisation s business applications are to be anaged by suitably trained and qualified staff to oversee their day to day running and to preserve security and integrity in collaboration with noinated individual application owners. All business application staff shall be given relevant training in inforation security issues. All business applications require ongoing anageent and the anagers will be responsible for overseeing their day to day running. The anageent of business applications necessarily involves a significant aount of security related work. A anager who lacks the relevant knowledge, experience, and training ight ake errors that cost the organisation dearly. Inappropriate control over access to a business application threatens the confidentiality and integrity of inforation. The high degree of discretion inherent in the anager s job in itself poses a security threat. Inadequate capacity or inappropriate configuration can ake efficient operation difficult or ipossible. Slow or inadequate response tie ipedes business processing. ii. Suggested Policy Stateent The procureent or ipleentation of new, or upgraded, software ust be carefully planned and anaged and any developent for or by the organisation ust always follow a foralised developent process. Inforation security risks associated with such projects ust be itigated using a cobination of procedural and technical controls. All organisations will, fro tie to tie, consider replacing or upgrading the applications that support their business processes. The procedures required to carry out the ipleentation or upgrade need to be properly anaged if security is not to be coproised. Where a new syste is inadequately tested, it can result in substantial daage to the business processes that rely on it and to the data it processes. Considering security requireents of a syste as an afterthought ay expose the organisation to loss or fraud. Inadequate training for both technical and user staff can result in costly errors in inforation content and in business processing. This ay coproise other systes that rely on the. iii. Suggested Policy Stateent Business requireents for new software or enhanceent of existing software shall specify the requireents for inforation security controls. An analysis of security requireents ust be carried out at the requireents analysis stage of each developent project and appropriate security controls ust be designed into both the application systes and the operational procedures being supported. Security controls should reflect the value of the inforation assets involved. These considerations should also be applied when evaluating software packages for business applications. In general, the business case for a bespoke developent ust be very strong to reject the selection of a suitable packaged solution. s o f t w a r e a n a g e e n t 120

4 6. Change control iv. Suggested Policy Stateent Foral change control procedures, with coprehensive audit trails, ust be used for all changes or upgrades to business software. All changes ust be properly authorised and all software, including that which interacts with the aended software, ust be tested before changes are oved to the live environent. All software needs to be updated periodically and, whether it is a inor change or ajor upgrade, the inforation security issues need to be actively addressed with safeguards to protect the live operations of the organisation. Change control ensures that all changes are analysed, authorised, fully tested and docuented before being ade available for live or operational use. Procedures should include rules for anaging all inforation assets including progra source, operational libraries, old versions and test environents. When an operating syste is upgraded, the supported applications should be reviewed to ensure that there is no adverse ipact on security. If foral change control procedures are not ipleented, it can be very difficult to anage changes on a prioritised basis. Insufficient testing of new software can result in errors that disrupt operational systes or corrupt files. Any aendent to your systes, even seeingly harless ones, can result in inforation security weaknesses. Unless carefully anaged, what begins as a inor odification can igrate into inforal systes developent effort, but with none of the necessary controls. Where prograers work independently, without anageent supervision, poor or alicious code could be copied into the source with alicious or fraudulent intent. Software under developent can becoe confused with operational software and potentially disrupt live operations. Conversely, old versions of progras can be confused with the latest version, resulting in either the loss of recent enhanceents or a failure of other systes, which depend on recent features. 7. Package software/systes v. Suggested Policy Stateent Modifications to vendor supplied software shall be discouraged, only strictly controlled essential changes shall be peritted and the developent of interfacing software shall only be undertaken in a planned and controlled anner. Modifications to vendor supplied software can lead to unforeseen security issues and ongoing inforation security aintenance overheads when future versions are ipleented. Interfacing of such systes with other business applications, by transferring inforation between the, is usually required. Such processes can put data at significant risk. The purchase of a new syste ay have been agreed based on the apparent ease of interfacing to current syste(s). Interfacing probles can result in substantial delays and even cause entire projects to fail, especially where coplex data anipulation is required. Where an interface progra is required to reforat the data to eet the needs of the target syste, such data anipulation poses a risk of data odification (possibly aliciously) and, thereby, inaccurate processing. Teporary files, created by interface progra processing and saved in a teporary location, ight contain sensitive data which unauthorised persons ight access, thus coproising the confidentiality of inforation. u c i s a i n f o r a t i o n s e c u r i t y t o o l k i t e d i t i o n 3. 0

5 8. Malicious and obile code vi. Suggested Policy Stateent The ipleentation, use or odification of all software on the organisation s business systes shall be controlled. All software shall be checked before ipleentation to protect against alicious code. When ipleenting new or odified software there are risks of unintentionally introducing viruses, Trojans, spyware or other alicious software that will pose significant inforation security risks. It is iportant that all software is subject to appropriate checking before ipleentation and that no software is introduced in an ad hoc anner. vii. Suggested Policy Stateent The need for systes to support obile code (applets, scripts, etc.) shall be reviewed. Where the use of obile code is necessary, the environent shall be configured so as to restrict its ability to har inforation or other applications. Mobile code consists of progras, often in the for of scripts or applets, that are downloaded across the network and run on a local achine. It can provide useful functions, for exaple in web pages or as part of iddleware, however it also provides a route by which alicious or unintended functions can be dynaically installed on coputers. Most applications that support obile code allow it to be isolated to soe degree fro the surrounding coputer and network by restricting the functions it can perfor. Such configuration options should be enabled wherever possible. It ay also be possible to use firewalls to restrict the passage of obile code into and out of sensitive areas. Specien Inforation Security Eleents of a Software Manageent Policy The organisation s business applications are to be anaged by suitably trained and qualified staff to oversee their day to day running and to preserve security and integrity in collaboration with noinated individual application owners. All business application staff shall be given relevant training in inforation security issues. The procureent or ipleentation of new, or upgraded, software ust be carefully planned and anaged and any developent for or by the organisation ust always follow a foralised developent process. Inforation security risks associated with such projects ust be itigated using a cobination of procedural and technical controls. Business requireents for new software or enhanceent of existing software shall specify the requireents for inforation security controls. Foral change control procedures, with coprehensive audit trails, ust be used for all changes or upgrades to business software. All changes ust be properly authorised and all software, including that which interacts with the aended software, ust be tested before changes are oved to the live environent. Modifications to vendor supplied software shall be discouraged, only strictly controlled essential changes shall be peritted and the developent of interfacing software shall only be undertaken in a planned and controlled anner. The ipleentation, use or odification of all software on the organisation s business systes shall be controlled. All software shall be checked before ipleentation to protect against alicious code. The need for systes to support obile code (applets, scripts, etc.) shall be reviewed. Where the use of obile code is necessary, the environent shall be configured so as to restrict its ability to har inforation or other applications. These specien policy eleents are intended only as a guide and should be adapted for individual organisations. The ipleentation of a software anageent policy will also require the developent of processes and procedures. To satisfy an external party, such as an auditor, that the policy has been fully ipleented will require docuentary evidence of these. s o f t w a r e a n a g e e n t 122