FSOGP 2000 MSWord

The Forums Standard of Good Practice
The Standard for Information Security
November 2000
The Forum's Standard of Good Practice Microsoft Word Format

This document presents an electronic copy of the Forum's Standard of Good Practice in Microsoft Word format. It has been created as a working document, and does not include the full introductory text provided with the complete version of the Standard. Produced as a result of strong Member demand, this version of the Standard can be manipulated and referenced easily. For example, Members can use this document to:
'cut and paste' specific parts of the Forum's Standard to complement existing standards within their organisations create an 'html' version of the Standard, which could be posted on a corporate intranet and include links to associated documents and sites produce a database of detailed standards, incorporating useful 'search' facilities facilitate the generation of checklists used for security audits.
Note: The complete version of the Standard is available as an Adobe Acrobat .pdf document.
Aspect SM Security Management

Keeping the business risks associated with information systems under control within an enterprise requires clear direction and commitment from the top, the allocation of adequate resources, and effective arrangements for promoting good information security practice across the enterprise.
Pages Area SM1 HIGH-LEVEL DIRECTION SM11 Management Commitment SM12 Security Policy SM13 Personnel Policies SM2 SECURITY ORGANISATION SM21 High-level Control SM22 Driving Force SM23 Local Co-ordination SM24 Security Awareness SM25 Security Education SM3 RISK ASSESSMENT SM31 Security Classification SM32 Ownership SM33 Risk Analysis SM4 SECURE ENVIRONMENT SM41 Standards / Procedures SM42 Security Architecture SM43 Data Privacy SM44 Physical Protection SM45 Business Continuity SM5 SPECIAL TOPICS SM51 Protection from Malicious Code SM52 Use of Cryptography SM53 Electronic Mail SM54 Remote Working SM55 Third Party Access SM56 Electronic Commerce SM6 MANAGEMENT REVIEW SM61 Security Audit / Review SM62 Security Monitoring 2 3 4 5 5 6 6 7 8 9 10 11 12 12 13 13 14 15 16 17 18 19 20 21
Area
Area
Area
Area
Area
Area
SM1
HIGH-LEVEL DIRECTION
Achieving a consistent standard of good practice for information security across the enterprise requires clear direction from the top. Accordingly, this area covers top managements direction on, and commitment to, information security. It specifies arrangements for communicating this direction and commitment to individuals who have access to the information and systems of the enterprise. Section Objective Standard of good Practice
SM11 Management Commitment

To establish top managements direction on, and commitment to, information security. Top managements direction on information security should be established, and commitment demonstrated. Top management (ie board-level directors or equivalent) should have a high level of commitment to: achieving high standards of corporate governance treating information security as a critical business issue and creating a securitypositive environment demonstrating to third parties that the organisation deals with information security in a professional manner applying fundamental principles such as assuming ultimate responsibility for information security, implementing controls that are proportionate to risk and achieving individual accountability. Top management should demonstrate their commitment to information security by: becoming directly involved in high-level information security arrangements, such as information security policy providing high-level control allocating sufficient resources to information security.
Section Objective
SM12 Security Policy

To document top managements direction on, and commitment to, information security, and communicate it to all individuals with access to the enterprises information and systems. Top managements direction on and commitment to information security should be communicated in the form of a high-level information security policy that applies across the enterprise. The policy should: include a statement of direction from top management supporting the goals and principles of information security highlight the business risks associated with a breakdown in information security define information security, responsibilities, and the high-level principles to be observed specify key activities to be undertaken, which include carrying out security classifications and risk analyses, safeguarding important records and reporting suspected security weaknesses require that information is protected in terms of its requirements for availability, integrity and confidentiality emphasise the need for compliance with software licenses and other legal, regulatory and contractual obligations prohibit unauthorised or personal use of the organisations information and systems and the use of obscene, racist or otherwise offensive statements (for example via email or over the Internet) state that disciplinary action will be taken against individuals who violate its provisions. The policy should be documented, ratified at board level and made available to all individuals who have access to the organisations information or systems. It should be reviewed periodically and revised to take account of changing circumstances.
Standard of good Practice
Section Objective Standard of good Practice
SM13 Personnel Policies

To ensure that personnel policies are consistent with, and support, the enterprises highlevel information security policy. Personnel policies should incorporate detailed measures to support the implementation of the high-level information security policy across the enterprise. Personnel policies should require: terms and conditions of employment and job descriptions to specify information security responsibilities contracts of employment (including terms and conditions of employment) to include a non-disclosure / confidentiality clause and to specify that disciplinary action will be taken if the information security policy is violated external personnel with authorised access to the organisations information or systems to sign non-disclosure / confidentiality agreements revocation of access privileges when authorised users change jobs or leave the enterprise screening of all applicants for employment. Personnel policies should be reviewed by an information security specialist, signed-off by top management (ie a board level director, or equivalent) and made available to all individuals with authorised access to the organisations information or systems.
Area
SM2
SECURITY ORGANISATION
Safeguarding information and systems requires information security activity to be organised efficiently across the enterprise. Accordingly, this area covers the organisational arrangements for managing information security across the enterprise and the security awareness, know-how and skills of individuals with authorised access to the organisations information and systems. Section Objective Standard of good Practice
SM21 High-level Control

To provide a top-down management structure and a practical mechanism for co-ordinating information security activity across the enterprise. High-level control should be exercised by top management via a high-level working group, committee or equivalent body. Membership of the group should include top management, business managers, those in charge of computer / network facilities and the person responsible for promoting good practice in information security across the enterprise. The group should meet at least three times a year to monitor the security condition of the enterprise, provide direction (such as by approving information security standards and procedures) and co-ordinate information security activity.
SM22 Driving Force

To actively promote good practice in information security and ensure that it is applied effectively across the enterprise. A unit should be established, such as a specialist information security function, which has an enterprise-wide responsibility for promoting good practice in information security. The specialist information security function (or equivalent) should: define a set of security mechanisms and supporting standards be responsible for helping business managers, users, IT staff, and others to fulfil their information security responsibilities, by providing expertise and running awareness programmes measure the effectiveness of information security enterprise-wide provide support for security classifications, risk analyses, audits, third party agreements and business continuity plans monitor general business trends, technological developments, new threats / vulnerabilities (for example via the Internet) and new solutions (such as cryptography) be run by staff who are equipped with the know-how, skills, resources and management support needed to fulfil their role. The person in charge of the specialist information security function (or equivalent) should have direct access to all levels of management throughout the enterprise and maintain contact with counterparts in the commercial world (including government or law enforcement agencies) and external security experts.
SM23 Local Co-ordination

To promote good information security practice at a local level within the enterprise, and ensure that it is applied effectively. The heads of business units / departments should be responsible for information security within their own areas. Arrangements should be made to co-ordinate information security activity within each part of the enterprise. Local information security co-ordinators should be appointed in individual business units / departments. They should be equipped with the know-how, skills, time, tools, contacts and authority needed to fulfil their role. Local information security co-ordinators should have access to in-house or external expertise in information security and be supported by standards / procedures for day-to-day security activities. The condition of information security in all parts of the enterprise should be reported to the head of the enterprise-wide driving force for information security, in a consistent manner and on a regular basis.
Section Objective
SM24 Security Awareness

To ensure business and IT managers, users and others with access to the information and systems of the enterprise understand the key elements of information security, why it is needed and their personal information security responsibilities. Awareness of information security should be maintained via effective awareness programmes covering all individuals with access to information or systems within the enterprise. Employees (including contractors) should be provided with guidance to help them understand information security, the importance of complying with policies / standards and to be aware of their own personal responsibilities. Formal awareness programmes should be: co-ordinated by a designated individual or group run using structured education / training programmes and specialised awareness material supported by top management kept up-to-date with current practices applied to all individuals with access to information or systems. The level of awareness within the enterprise should be measured and reviewed periodically.
Section Objective
SM25 Security Education

To equip personnel involved in controlling, using, running, developing and securing the information and systems of the enterprise with the knowledge and skills required to fulfil their information security responsibilities. Education / training should be provided to all personnel with control over, or access to, the organisations information and systems. This should equip all personnel with the knowhow required to assess security requirements, propose security controls and ensure controls function effectively. Education / training should also be provided to ensure that: business users use systems correctly and apply security controls IT staff develop systems in a disciplined manner and run installations or communications networks correctly information security specialists understand the business, know how to run security projects and can communicate effectively.
Area
SM3
RISK ASSESSMENT
Ensuring that the safeguards applied to information and systems are proportionate to their importance to the business is a fundamental element of good practice. Accordingly, this area covers arrangements for identifying risk and control requirements in a structured, business-oriented manner. Section Objective
SM31 Security Classification

To determine the criticality of information and systems within the enterprise in order to communicate how they should be treated and to enable attention to be focused on those that are most critical. Individuals responsible for information and systems should be required and equipped to classify them using a security classification scheme that applies across the enterprise. The information security classification scheme should: specify that information and systems should be classified according to their criticality, sensitivity, and vulnerability to particular threats take account of the business impact of a loss of confidentiality, integrity and availability apply to all information in electronic and paper form, all software and hardware, and to services provided by external parties be applied to new systems at their development stage, as well as to established systems provide guidance on how to resolve conflicting classifications. Critical information and systems should be: distinguished from other information and systems recorded in an inventory maintained at enterprise level signed-off by the business owner protected in line with their classification.
SM32 Ownership
To achieve individual accountability for all information and systems within the enterprise and to give responsible individuals a vested interest in safeguarding them. Ownership of all information, software and associated computer and network facilities of the enterprise should be assigned to the person(s) in charge of the business processes or organisational units most dependent on them. An owner should be an individual, rather than a collective body. Responsibilities of owners should be clearly defined and documented. They should be formally accepted by all owners. Responsibilities should include: determining business requirements (including information security requirements) classifying information and systems according to their criticality, sensitivity and vulnerability defining access policies establishing and maintaining service agreements authorising specifications for business requirements (including changes) being involved in information security reviews protecting information and systems in line with business risk. A process should be established for reassigning ownership and for fulfilling responsibilities when the owner is unavailable.
Section Objective
SM33 Risk Analysis

To enable individuals who are responsible for particular information and systems to identify key risks and determine the controls required in order to keep those risks within acceptable limits. Risk analyses should be required for information or systems, including those under development, which are important or critical to the enterprise. Decision-makers (including top management and individuals in charge of critical business applications, information processing environments, communications networks and systems under development) should be aware of the need to perform risk analyses. Business risks associated with the enterprises information and systems should be assessed using formal risk analysis methods. They should be consistent across the enterprise to enable true comparison of the results. Risk analysis methods should be documented, flexible, understandable, approved by top management, and periodically reviewed to ensure they meet business needs. Risk analysis methods should: require the involvement of representatives from key areas, such as business owners, key user representatives, IT professionals and, for critical business applications, an expert in risk analysis determine business risk taking into account the criticality of the application, the business impact of a loss of confidentiality, integrity or availability, key threats and vulnerabilities take into account the full range of controls needed to keep risks within acceptable limits including their costs. The results of the risk analysis should include a clear indication of key risks, an assessment of their potential business impact and recommendations for the actions required to reduce risk to an acceptable level.
10
Area
SM4 SECURE ENVIRONMENT

Achieving a consistent standard of good practice in information security across an enterprise is a complex undertaking. The difficulties can be eased by introducing a common framework of disciplines and by making some arrangements at enterprise level, rather than on an individual basis, for example by appointing a data protection coordinator for the whole enterprise. Accordingly, this area covers the arrangements required to achieve consistency across the enterprise.
SM41 Standards / Procedures

To provide a coherent framework of information security disciplines across the enterprise. Comprehensive and formal standards / procedures for information security should be developed and applied across the enterprise. Formal standards / procedures should be driven by business requirements, based on practical experience and focused on issues that cause the most harm. Formal standards / procedures should address: security management activity including organisation, security awareness and education, security audit / review, security classification, risk analysis, building security into systems during system development, security monitoring and business continuity special enterprise-wide initiatives including electronic commerce, electronic mail, data privacy, security architecture and the use of cryptography general information security activity including system administration, change management, incident management, back-up, physical security, and protection against malicious code control of access to information and systems including Internet usage, remote working and external access by third parties restrictions on electronic office systems processes for dealing with evidence required for investigations. Formal standards / procedures should be documented, kept up-to-date, supported by more detailed guidelines for technical or special topics and approved by information security management. Relevant standards / procedures should be made available to all individuals with authorised access to the information and systems of the enterprise. There should be lists of approved hardware and software products.
11
Section Objective
SM42 Security Architecture

To facilitate the development and use of systems in a secure manner, by enabling system developers and administrators to implement consistent, simple-to-use security functionality across multiple computer systems within the enterprise. An information security architecture should be established and applied across the enterprise. Arrangements should be made enterprise-wide to: minimise the diversity of hardware / software in use integrate security controls at application, computer and network level whilst eliminating redundancy, for example by using common interfaces implement common naming conventions for information and systems, including an integrated directory name service employ consistent security functionality including access controls, cryptographic techniques and role-based access privileges support a consistent set of rules for validating and authenticating users. Arrangements should be formalised into a documented information security architecture. The architecture should: comprise a defined set of security mechanisms and supporting standards that provide a coherent range of security capabilities to users and system developers be applied in developing major new applications and to existing systems be approved by business, IT and information security managers.
SM43 Data Privacy

To ensure compliance with legal and regulatory requirements for data privacy. Standards / procedures for dealing with data privacy issues should be established. An individual should be designated as data protection co-ordinator (or equivalent) to ensure compliance with national and international legal and regulatory requirements, such as the EU directive on data privacy. Steps should be taken to ensure that personal data is: adequate, relevant and not excessive for the purposes for which it was collected accurate (ie recorded correctly and kept up-to-date) and held in a format that permits identification of data subjects for no longer than is necessary processed fairly and legally, kept confidential, and used only for specified, explicit and legitimate purposes. The approval of individuals about whom personal data is held (ie the data subject) should be sought before such data is stored, processed or disclosed to third parties. Data subjects should be informed of how personal data will be used, allowed to check its accuracy and be able to have their records corrected or removed.
12
SM44 Physical Protection

To ensure that only authorised individuals have physical access to the enterprises business information and critical IT facilities. All buildings within the enterprise that house critical IT facilities (including data centres, communications facilities, dealing rooms and key user areas) should be protected by a range of physical controls. Physical controls should be provided to protect:

buildings that house critical IT facilities against unauthorised access, by using locks, employing security guards and providing video surveillance important papers and removable storage media such as CDs and diskettes against theft or copying, by complying with a clear desk policy, providing lock-out on unattended terminals and restricting physical access to important post / fax points easily portable computers and components against theft, by using physical locks and indelibly marking vulnerable equipment staff against coercion from malicious third parties by providing duress alarms in susceptible public areas and establishing a process of responding to emergencies.
SM45 Business Continuity

To equip the enterprise to withstand a prolonged unavailability of critical information and systems, for example due to a major disaster. A formal process for developing effective business continuity plans and maintaining business continuity arrangements across the enterprise should be established. Standards / procedures for the development of business continuity plans should specify that such plans are: documented for all critical parts of the enterprise based on the results of risk analyses developed in conjunction with user representatives distributed to all individuals who would require them in case of an emergency kept up-to-date, backed-up by a copy held at an off-site location, and subject to formal change management. Business continuity plans should include a schedule of key tasks to be carried out, responsibilities for each task and a list of services to be recovered, in priority order. Business continuity arrangements should: cover the prolonged unavailability of critical computer facilities or equipment, communications services, personnel, buildings or access to buildings be tested periodically, using realistic simulations, to demonstrate whether services can be resumed within critical timescales. Checks should be performed to ensure that individuals responsible for critical environments have developed business continuity plans, provided contingency arrangements and have tested them periodically.
13
Area
SM5
SPECIAL TOPICS
The rapid pace of change in business and technology has resulted in the emergence of special topics with particular security concerns that should be dealt with enterprise-wide. Accordingly, this area covers the special security controls that apply to electronic commerce, electronic mail, remote working, use of cryptography and the provision of third party access. It also covers the arrangements required to protect against malicious mobile code. Section Objective Standard of good Practice
SM51 Protection from Malicious Code

To protect the enterprise against disruption caused by the introduction of malicious code, such as viruses or harmful mobile code downloaded from the web. Standards / procedures that specify methods of protecting against malicious code such as viruses or harmful mobile code (downloaded from the web), should be developed and disseminated across the enterprise. The risk of virus infection should be reduced by specifying: the minimum capability of anti-virus software, such as scanning computer memory, files and storage media that anti-virus software should be run at all times the computers are in use the use of automatic update mechanisms for anti-virus software, applied at least on a weekly basis a formal process to help users deal with virus attacks, warning them to stop processing, note symptoms, identify the source and inform a single point of contact for support that investigators should disconnect suspected computers from the network before powering them up and transfer media or files to a dedicated quarantine computer. Strict disciplines should be imposed over the downloading of mobile code from the web, and should include: restricting the use of mobile code from undesirable sources, such as by producing a white list of code only allowed from specified web sites preventing the downloading of specific types of mobile code with known vulnerabilities, such as ActiveX controls using cryptographic techniques, such as code signing, to confirm that downloaded mobile code comes from a recognised source and has not been tampered with screening mobile code in quarantine areas, for example, using a sandbox, prior to use.
14
SM52 Use of Cryptography

To provide a high level of assurance that cryptographic solutions are applied and managed in an effective and disciplined manner. Standards / procedures should be developed to govern the use of cryptography across the enterprise. They should: define the circumstances in which cryptography should be used specify the suitability of cryptographic solutions to be employed (including algorithms and key lengths) address the selection of cryptographic algorithms, and the management of cryptographic keys cover restrictions on the export / use of cryptographic solutions. An up-to-date inventory of cryptographic solutions applied in the enterprise should be maintained. Responsibilities for cryptographic key management and dealing with licensing issues should be clearly defined. Business managers should have access to: technical and legal advice on the use of cryptography a list of approved cryptographic solutions. Where a Public Key Infrastructure (PKI) is in use, standards / procedures should be established, which define the: purpose of the PKI controls required to manage digital certificates / cryptographic keys within the PKI methods required to operate the PKI actions to be taken in the event of a compromise or suspected compromise of the PKI. Steps should be taken to provide very high levels of protection over the Certification Authority(ies) (CA) within the enterprise by: severely restricting access to the CA(s), for example by using access control mechanisms supported by strong authentication, such as tokens removing all known vulnerabilities on the operating system(s) that supports the CA(s) employing other general controls (for example change management) in a particularly disciplined manner. Contingency plans for the application(s) supported by the PKI should include methods of recovering the PKI in the event of a disaster.
15
SM53 Electronic Mail

To ensure that: electronic mail services are available when required; the confidentiality and integrity of messages is protected in transit; and the risk of misuse is minimised. Mail servers should be configured to protect the availability of electronic mail (e-mail) systems, by limiting the size of messages / user mailboxes, restricting the use of large distribution lists and preventing e-mail loops. E-mail messages should be scanned for: known malicious code, including attachments where such code could be hidden prohibited words, such as those that are offensive key known phrases, such as those commonly used in hoax viruses or chain letters. E-mail systems should be protected by: blocking messages that originate from undesirable web sites or e-mail list servers, for example to help prevent spamming hashing messages to help maintain integrity and encrypting those that are confidential ensuring non-repudiation of messages, for example to prove the origin of a message by using mechanisms such as digital signatures. Users of e-mail systems should be warned that the contents of e-mail messages may be legally binding, messages sent or received may be monitored and misuse of e-mail facilities can result in disciplinary action.
16
Section Objective
SM54 Remote Working

To ensure that computers used by staff working in remote locations operate as intended, remain available and do not compromise the security of any facilities to which they can be connected. Computers used by staff working in remote locations (typically desktop or laptop PCs) should be purchased from a list of approved suppliers, tested prior to use, supported by effective maintenance arrangements and protected by physical controls. Computers used in remote locations should be: equipped with standard configurations of system and application software protected by the use of a comprehensive set of system management tools, access control mechanisms and up-to-date virus protection software automatically logged-off after a set period of inactivity. Staff working in remote locations, including from public areas, such as trains or airports or from home, should be: authorised to work in specified locations equipped with the necessary skills to perform required security tasks made aware of the additional risks associated with remote working, including the increased likelihood of theft of equipment or disclosure of confidential information provided with technical support in compliance with legal and regulatory requirements (for example, health and safety laws) provided with alternative working arrangements in cases of emergency. Additional controls should be implemented on workstations with the capability of connecting to the Internet, including the: use of standard web browsers, with key software updates applied, and configured to prevent users from disabling security options warning users about the dangers of downloading mobile code and the implications of accepting or rejecting cookies imposing strict disciplines on the downloading of mobile code.
17
Section Objective
SM55 Third Party Access

To ensure that access to the enterprises information and systems by third parties (ie external organisations, such as customers or suppliers and members of the public) is only provided following rigorous review and formal approval. Third parties (ie external organisations, such as customers or suppliers and members of the public) should only be granted access to information or systems within the enterprise following rigorous review. All connections from third parties should be uniquely identified, approved by the business owner, recorded and agreed by both parties in a formal contract. A risk assessment should be carried out, agreed controls implemented and rigorous testing performed. Standards / procedures for third party access should specify methods of: ensuring that controls over third parties are commensurate with business risks making third parties accountable for their actions limiting liabilities and protecting ownership rights complying with legal or regulatory obligations. Standards / procedures for third party access should cover arrangements for: achieving technical compatibility, logging activity and providing a single point of contact for dealing with problems restricting methods of connection and the type of access granted subjecting third party users to strong authentication terminating connections when no longer required. Individuals responsible for managing third party connections should have access to information about the risks associated with third party access, guidelines on how to secure connections, supporting tools such as checklists and sources of expertise for technical / specialist advice.
18
SM56 Electronic Commerce

To keep the risks associated with the development and deployment of electronic commerce within acceptable limits. A high-level committee should be established to co-ordinate all electronic commerce (e-commerce) initiatives throughout the enterprise. The committee should be chaired by a top-level business manager, for example board level or equivalent, and should include representatives from a wide range of disciplines including business units, security, legal, compliance, audit, operational risk and IT. Risk assessments should be performed at an early stage in the development of ecommerce initiatives, using a specialised risk analysis method specially designed to evaluate risks associated with e-commerce, and focused on key risks such as overload or divulgence of sensitive customer information. Standards / procedures should require that: good practices are not sacrificed in the interests of speed initiatives are driven by business requirements (ie they are not technology-led) dependence on immature technology is minimised the security implications of implementing vendor solutions are assessed. A process should be established to ensure that key decision-makers: understand the security requirements of customers are aware of the full range of risks associated with e-commerce and have not overlooked the main threats formally sign-off residual risks have acquired staff with the security skills required to support e-commerce initiatives. Prior to going live, e-commerce initiatives should be tested rigorously using very large numbers of users, reviewed by an experienced information security practitioner and formally approved by top management.
19
Area
SM6
MANAGEMENT REVIEW
An accurate understanding of the information security condition of the enterprise (including the level of dependence on information and systems, its security status, incidents statistics, likely threats and improvement activity) is required in order to manage information security effectively. Accordingly, this area covers the arrangements needed to provide decision-makers with sound information on the security condition of information and systems across the enterprise. Section Objective
SM61 Security Audit / Review

To provide individuals who are responsible for particular IT environments, and top management, with an independent assessment of the security condition of those environments. The information security status of critical IT environments should be subject to thorough, independent and regular security audit / review. Security audits / reviews should take into account business risks associated with the environment under review and should be performed for critical business applications, information processing environments, communications networks and system development activities. Security audits / reviews should be: agreed with the individual responsible for the environment under review performed by qualified individuals who are equipped with sufficient technical skills and knowledge of information security conducted sufficiently frequently and thoroughly to provide assurance that security controls function as required complimented by reviews conducted by independent third parties. Recommendations for improvement should be agreed with the individuals responsible for the environment under review, implemented and reported to top management.
20
SM62 Security Monitoring

To provide top management with an accurate, comprehensive and coherent assessment of the security condition of the enterprise. The information security condition of the enterprise should be monitored. Monitoring arrangements should be defined in writing, agreed with top management and performed periodically. They should keep top management informed of key risks and encourage owners to remedy unacceptable risks. Information collected for monitoring purposes should include details about: the criticality of information and systems threats from accidents and deliberate acts the full range of controls needed to protect the confidentiality, integrity and availability of information and systems the status of controls applied vulnerabilities caused by control weaknesses and special circumstances that heighten vulnerability, such as major changes to systems the patterns and business impact of incidents. Information about the security condition of the enterprise should be provided to top management, the high-level security committee, individuals in charge of critical business applications, information security management and internal audit. Information about the security condition of the enterprise should: provide decision-makers with an informed view of the adequacy of their information security arrangements reveal areas where improvement is most needed identify information and systems that are subject to unacceptable risks highlight actions required to minimise risks, such as addressing control weaknesses set quantitative targets for improvement.
21
Aspect CB Critical Business Applications

A critical business application requires a more stringent set of security controls than other applications. By understanding the business impact of a loss of confidentiality, integrity or availability, it is possible to establish the level of criticality of an application. This provides a sound basis for identifying business risks and determining the level of protection required to keep risks within acceptable limits.
Pages Area CB1 SECURITY REQUIREMENTS CB11 Confidentiality Requirements CB12 Integrity Requirements CB13 Availability Requirements CB2 RISK ASSESSMENT CB21 Security Classification CB22 Risk Analysis CB3 APPLICATION MANAGEMENT CB31 Roles and Responsibilities CB32 Running the Application CB33 Application Controls CB34 Change Management CB35 Incident Management CB36 Security Audit / Review CB37 Business Continuity CB38 Sensitive Material and Information CB4 USER ENVIRONMENT CB41 Access Control CB42 Workstation Configuration CB43 User Awareness CB5 SYSTEM MANAGEMENT CB51 Service Agreements CB52 Resilience CB53 External Connections CB54 Back-up CB6 SPECIAL TOPICS CB61 Third Party Access CB62 Cryptographic Key Management CB63 Electronic Commerce Applications 23 24 24 25 26 27 28 28 29 29 30 30 31 32 33 33 34 34 35 35 36 37 38
Area
Area
Area
Area
Area
22
Area
CB1
SECURITY REQUIREMENTS
Business applications vary enormously in their importance to the business; hence the level of protection that is required also varies. Accordingly, this area identifies the information security requirements of the application. Section Objective Standard of good Practice
CB11Confidentiality Requirements
To enable the confidentiality requirements of the application to be assessed in a consistent manner. The impact of business information stored in or processed by the application being disclosed to unauthorised individuals should be assessed in terms of: loss of competitive advantage direct loss of business loss of public confidence additional costs being incurred breach of legal, regulatory or contractual obligations damage to staff morale fraud. The confidentiality requirements of the application should be documented, agreed by the business owner and made available to top management.
23
CB12Integrity Requirements
To enable the integrity requirements of the application to be assessed in a consistent manner. The impact of business information stored in or processed by the application being accidentally corrupted or deliberately manipulated should be assessed in terms of: incorrect management decisions being made direct loss of business fraud loss of public confidence additional costs being incurred breach of legal, regulatory or contractual obligations damage to staff morale business disruption. The integrity requirements of the application should be documented, agreed by the business owner and made available to top management.
CB13Availability Requirements
To enable the availability requirements of the application to be assessed in a consistent manner. The impact of business information stored in or processed by the application being unavailable for any length of time should be assessed in terms of: incorrect management decisions being made direct loss of business fraud loss of public confidence additional costs being incurred breach of legal, regulatory or contractual obligations damage to staff morale business disruption. The critical timescale of the application should be determined (ie the timescale beyond which the unavailability of information or systems would be unacceptable to the business). The availability requirements of the application should be documented, agreed by the business owner and made available to top management.
24
Area
CB2
RISK ASSESSMENT
The controls applied to a business application should be proportional to business risk. Accordingly, this area covers the arrangements made to identify the relative importance of the application, the associated business risks and the level of protection required. Section Objective Standard of good Practice
CB21 Security Classification

To classify the application according to its criticality in order to communicate how it should be treated. The application should be classified using a security classification scheme that applies across the enterprise. The classification scheme should take account of the: business impact of a loss of confidentiality, integrity or availability sensitivity of information stored in or processed by the application vulnerability of the application to particular threats. Security classifications should be: used to establish the criticality of the application applied to all information in electronic or paper form, all software and hardware, and to all services provided by external parties approved by the person in charge of the application reviewed by the local security co-ordinator and the individuals in charge of the facilities that support the application revised periodically in the light of changing circumstances recorded in formal agreements with service providers, such as service level agreements. Details of security classifications for the application should be recorded in an inventory and include: the identity of the individual responsible for them unique identifiers, such as descriptive titles an access policy defining the individuals or groups who are authorised to access the information stored in or processed by the application the identity of legal owners. The application should be protected in line with its security classification.
25
CB22 Risk Analysis

To identify key risks associated with the application and determine the controls required in order to keep those risks within acceptable limits. Formal risk analysis techniques should be applied to business applications that are critical to the enterprise. The risk analysis technique used should: involve representatives of key areas, including the business owner, an IT specialist, key user representatives and an expert in risk analysis determine business risk (taking into account the criticality of the application, the business impact of a loss of confidentiality, integrity or availability, key threats and vulnerabilities) take into account the full range of controls needed to keep risks within acceptable limits. The results of the risk analysis should be documented. They should include a clear indication of key risks, an assessment of their potential business impact and recommendations for the actions required to reduce risk to an acceptable level. The results (including any residual risk) should be reviewed and agreed by the business owner (or equivalent) and agreed actions implemented. Business risks should be reviewed periodically and in the light of changing circumstances.
26
Area
CB3
APPLICATION MANAGEMENT
Keeping business risks within acceptable limits requires a coherent set of information security arrangements. Accordingly, this area covers the roles and responsibilities required (including business ownership), key issues associated with running the application, integral application controls and special controls for handling sensitive material and exchanging sensitive information. In addition, this area covers general management controls including change management, incident management, security audit / review and business continuity. Section Objective Standard of good Practice
CB31 Roles and Responsibilities

To ensure ownership of the application is assigned appropriately, and to provide a sound management structure over personnel running or using the application. Responsibility for every critical business application should be assigned to a designated individual (ie a business owner). Ownership should lie with a senior business manager, typically the person in charge of the business process or activity most dependent on the correct functioning of the application. The owner should formally accept the responsibilities associated with this role. Responsibility for key tasks (such as running the application, conducting risk analyses, change management and incident management) should be assigned to designated individuals. Individuals running the application should be: assigned clear responsibilities equipped to run the application correctly sufficient in number to handle peak workloads competent to deal with error, exception and emergency conditions aware of information security principles and associated good practice. The reliance on key individuals and the risk of unauthorised changes to information, theft or fraud should be minimised, for example by appointing deputies, supervising activities or ensuring segregation of duties. An individual should be appointed to co-ordinate information security arrangements associated with the application (ie a local security co-ordinator).
27
CB32Running the Application

To ensure the application is run correctly and that security breaches are prevented or identified. Staff running the application should be supported by formal standards / procedures that are documented, approved by the business owner and kept up-to-date. Standards / procedures should specify methods of: administering users, such as adding new business users and updating access privileges updating key parameters, such as customer master files, currency exchange rates or product details monitoring the status of transactions, validating processes / data and reviewing error / exception reports. Prior to live running or following any significant changes, the following should be reviewed and approved by the business owner: arrangements made to fulfil the security requirements of the application limitations of controls residual business risks. Individuals involved in running the application should be supported by accurate system documentation and access to technical support.
CB33Application Controls
To ensure that controls to protect information stored in or processed by the application have been designed into the application and applied rigorously. The application should be designed so that: the validity of the information it processes can be readily established, for example, using range, consistency and hash total checks the completeness and accuracy of information processed can be confirmed, for example by comparison with control balances or original documentation and rigorous checking of changes to key files and parameters accountability for actions can be determined the opportunity for error or abuse is minimised, for example by automating processes and the maintenance of a complete and reliable audit trail, including error and exception reports. Where the application is used to initiate critical business processes, such as funds transfers or publication of financial results, additional controls should be applied. These should include confirmation from the person initiating the process to ensure it is valid and authorised, dual control over important activities (such as data input or payments) and the ability to revoke critical processes initiated in error.
28
CB34Change Management
To ensure that changes do not affect the availability of the application or compromise the confidentiality / integrity of associated business information. Changes affecting the application should be made in accordance with a formal process. The process should apply to all forms of change such as: upgrades and modifications to application software, including emergency fixes revisions to parameter tables and settings modification of business information, such as data tables, files and databases changes to user or operating procedures changes to the computers / networks that support the application. Before changes are made, their impact should be assessed, they should be rigorously tested and approved by the business owner. Changes to the computers and networks that support the application should be organised to avoid disrupting use of the application. Development and acceptance testing activity should be isolated from the live environment.
CB35Incident Management
To identify and resolve incidents effectively, minimise their business impact and reduce the risk of similar incidents occurring. All types of incident (including malfunctions, loss of power / communications services, overloads, mistakes by users or computer staff, access violations) should be dealt with in accordance with a formal process. The incident management process should: ensure incidents are reported to a single point of contact specify requirements for the recording of incidents include categorising incidents by type and prioritising them according to their impact / urgency define procedures for dealing with incidents (including investigation, planning of remedial action, resolution, communication with users, supervising activities and documenting actions taken). Significant incidents should be reported to the business owner who should assess their business impact. Patterns of incidents (including number and frequency) should be reviewed to diagnose common problems and to minimise their recurrence.
29
CB36Security Audit / Review

To provide the business owner, and top management, with an independent assessment of the security of the application. The information security status of the application should be subject to thorough, independent and regular security audits / reviews. Security audits / reviews should assess the business risks associated with the application by considering the information security requirements of the application and the applications vulnerability to key threats. Security audits / reviews should cover risk assessment, application management, user environments and system management and any topics with special security concerns, such as third party access, cryptographic key management and electronic commerce. Security audits / reviews of the application should be: agreed with the business owner defined in scope and documented performed by qualified individuals and checked by competent personnel supported by the use of automated software tools. Agreed recommendations from security audits / reviews should be implemented and reported to top management.
CB37Business Continuity
To enable the business processes associated with the application to continue in the event of a disaster. Arrangements should be made to enable the business processes associated with critical business applications to continue in the event of a disaster. Alternative facilities capable of running the application should be ready for use within the critical timescale of the application. Contingency arrangements should: cover prolonged unavailability of critical computer facilities or equipment, communications services, information, personnel, buildings or access to buildings be based on a thorough analysis of risk and approved by the business owner be the responsibility of a particular individual or working group be documented in a formal plan and updated following any significant changes (such as to network services and facilities and legal, regulatory or contractual obligations). Business continuity plans should include a schedule of key tasks to be carried out, responsibilities for each task and a list of services to be recovered, in priority order. To ensure that services can continue within the critical timescale of the application (ie the point beyond which unacceptable loss would be suffered) periodic tests or rehearsals should be carried out using realistic simulations, involving both users and IT personnel. Key components of the application should be covered by insurance arrangements that address key risks, (such as loss of data, business interruption, or liabilities to third parties) and provide adequate protection against likely threats (such as fire, theft, fraud or malicious damage).
30
CB38Sensitive Material and Information

To provide additional protection for applications that involve handling sensitive material or exchanging sensitive information with other business applications or with third parties. Sensitive material (such as blank cheques, printouts of personal information, financial projections or business plans) and the exchange of sensitive information (such as electronic funds transfer with other business applications or third parties) should be given additional protection. Sensitive material should be: stored securely, for example in a fireproof safe protected in transit and controlled by recording its issue and use disposed of securely, for example by erasure, incineration or shredding protected from unauthorised disclosure. The exchange of sensitive information should be protected by: validating the origin and destination of nodes and ports appending cryptographic codes to messages, such as digital signatures encrypting information in transit sending portions of the information, such as cryptographic keys and the encrypted version of the information by different routes.
31
Area
CB4
USER ENVIRONMENT
Critical business applications can be used by internal or external business or technical users who may be sited locally or at a remote location, each with differing business and security requirements. It is, therefore, important that access to business information associated with the application is restricted and users are aware of key risks and important security controls. Accordingly, this area covers the disciplines required to control access to the application, configure workstations and make users aware of information security and their associated responsibilities. Section Objective Standard of good Practice
CB41 Access Control

To ensure that only authorised individuals gain access to the application and associated information in line with a defined policy, and that individual accountability is assured. Access to the capabilities of the application and associated information should be restricted to authorised individuals and enforced. Users of the application should be restricted: according to a defined policy, such as on a need to know or need to restrict basis by limiting access privileges only to those required for a users individual role using automated access control mechanisms. Each users access privileges should be authorised by the business owner. User privileges should be promptly removed when they are no longer entitled to use them, for example when they leave the organisation. Prior to being granted access to the application, users should be authenticated. High-risk users, such as those with access to powerful access privileges / utilities or sensitive information should be subject to strong authentication, for example using token-based mechanisms. Processes for issuing new or changed passwords should: ensure they are not sent in clear text (ie unencrypted) directly involve the user to whom the password uniquely applies verify the identity of the target user, for example using a special code or via independent confirmation. Access logs should be set to include all security-related events, be periodically reviewed and retained for a specified period to comply with legal and regulatory requirements.
32
CB42 Workstation Configuration

To ensure workstations operate as intended, remain available and do not compromise the security of the application. Workstations connected to critical business applications should be purchased from a list of approved suppliers, tested prior to use, supported by effective maintenance arrangements and protected by physical controls. Each workstation should be: equipped with standard configurations of system and application software protected by the use of a comprehensive set of system management tools, access control mechanisms and up-to-date virus protection software automatically logged-off after a set period of inactivity. Additional controls should be implemented on workstations with the capability of connecting to the Internet, including: use of standard web browsers, with key software updates applied, and configured to prevent users from disabling security options warning users of the dangers of downloading mobile code and the implications of accepting or rejecting cookies imposing strict disciplines on the downloading of mobile code.
CB43 User Awareness

To maintain a high-level of awareness of information security among users of the application. Users of the application should be aware of a high-level information security policy, and comply with it. Users of the application should be made aware of: the meaning of information security and why it is needed the importance of complying with information security policies and applying associated standards / procedures their personal responsibilities for information security particular security threats to the application. Users of the application should be made aware that they are prohibited from: using any part of the application (such as modems) without authorisation or for purposes that are not work-related making obscene, racist or otherwise defamatory statements, such as through the application, via e-mail or over the Internet illicit copying of information or software disclosing confidential information (such as network designs or IP addresses) or compromising passwords (such as writing them down or disclosing them to others). Users should be advised that they should lock away sensitive media and documentation when not in use and log off the application if leaving a terminal unattended. They should be warned of the dangers of being overheard when discussing business information over the telephone, and in public places such as train carriages, airport lounges or bars.
33
Area
CB5
SYSTEM MANAGEMENT
To enable applications to function, they have to run on one or more computers and typically make use of one or more networks. Accordingly, this area covers service agreements, external connections and the information security arrangements which apply to the computers / networks that support the application. Section Objective Standard of good Practice
CB51 Service Agreements

To define the business requirements, including information security requirements, to be met by the providers of any computer and network services that support the application. The computer and network services required to support an application should be formally agreed with service providers (internal or external). Formal agreements for computer and network services, such as contracts or service level agreements, should specify: the people in charge of the application and people responsible for the delivering the required services capacity requirements, dates / times when services are required and maximum permissible down-time arrangements for ensuring continuity of service segregation requirements of users, computers and networks authentication methods and access restrictions change management procedures incident management procedures. Service agreements should be approved by the business owner and the individuals in charge of the computer or network services being supplied. Services provided should be reviewed periodically against agreed targets.
CB52 Resilience
To ensure that the application is supported by a robust and reliable set of hardware and software. Components that are critical to the continuity of the application should be identified and recorded in an inventory. Single points of failure should be minimised by: duplicating processors, such as by using fault tolerant systems processing information simultaneously at multiple locations (ie hot back-up) automatically identifying and recovering transactions following a system failure duplicating data storage, for example using disk mirroring or RAID protecting power supplies by uninterruptible power supplies (UPS). An alternative source of power, such as a backup electricity generator, should be provided to enable the application to continue running in the event of an extended power failure. To prevent the application from being disrupted by other systems: the application should be run on dedicated computers information should not be not transferred from any connected system that does not have equivalent security controls. The application should be supported by up-to-date makes and models of software and hardware (ie rather than by obsolete products).
34
CB53 External Connections

To ensure that only authorised individuals gain access to the application via external network connections. External connections to the application, (including those used by staff working in remote locations or by authorised third parties) should be individually identified, formally approved and recorded, for example in an inventory. Prior to granting external access to the application, steps should be taken to ensure that: risks have been assessed agreed security controls have been implemented rigorous testing has been performed formal contracts are in place. Once permission to connect has been granted, external access to the application should be restricted by: subjecting external users to strong authentication, such as challenge / response devices featuring one-time passwords, smartcards or other tokens routing traffic through secure gateways such as firewalls limiting methods of connection granting access only to specified parts of the application. External connections should be removed promptly when no longer required and key components disabled or removed, such as redundant modems.
CB54 Back-up
To prevent loss of essential information and software. Back-up versions of essential information and software used by the application should be taken, according to a defined cycle. Back-ups should be: taken frequently enough to meet the time-criticality of business processes performed using an automated back-up management package verified to ensure that the back-up versions are readable and can be restored within the critical timescale of the application (ie the point beyond which unacceptable loss would be suffered) restricted to authorised personnel protected from loss or damage by storage on-site in a fireproof safe and supported by copies stored off-site.
35
Area
CB6
SPECIAL TOPICS
The rapid pace of change in business and technology has resulted in the emergence of special topics with particular security concerns. Where these topics apply to a critical business application, special security arrangements are required. Accordingly, this area covers the additional security controls applicable to applications that provide third party access, employ cryptographic key management (for example, a Public Key Infrastructure) or support electronic commerce. Section Objective
CB61Third Party Access

To ensure that access to the application by a third party is only provided once a risk assessment has been performed and a formal agreement, such as a contract, has been established. Third parties (ie external organisations, such as customers or suppliers and members of the public) that require access to the application should be subject to additional controls. They should only be granted access on completion of a satisfactory risk assessment and if supported by a formal agreement. Risk assessments of third party access arrangements should take account of the: criticality and sensitivity of information and systems to be accessed relationship with prospective third parties (including the strength of their security practices) and the nature of the associated business process technical aspects of connection (including the effectiveness of IT infrastructure, access control mechanisms, methods of connection and any vulnerabilities in third party networks) obligations implicit in any agreements such as providing a third party with a reliable service or timely and accurate information. Agreements should be documented in a formal contract and approved by the business owner. The contract should: oblige third parties to comply with good business practices and provide information about any security incidents clearly state the services to be provided such as the business practices to be adopted, timeframes for completion of transactions and an agreed process for resolving disputes specify agreed security arrangements, such as those for managing changes / incidents, restricting access and preserving the confidentiality of important business information include arrangements for ensuring that transactions cannot be repudiated protect intellectual property rights include the right to audit third party security arrangements. Third party access arrangements should be reviewed periodically to ensure that risks remain within an acceptable limit.
36
CB62Cryptographic Key Management

To provide assurance that solutions based on cryptographic key management, for example a Public Key Infrastructure (PKI), can be relied upon. Cryptographic keys can be used to protect the confidentiality of information, preserve its integrity and provide strong authentication. Where used they should be managed in an effective and disciplined manner, in accordance with formal standards / procedures. Formal standards / procedures should cover: selection of cryptographic keys of an appropriate length secure distribution, storage and periodic updating of cryptographic keys revocation of cryptographic keys, for example when a recipient changes job recovery of cryptographic keys that are lost, corrupted or have expired management of cryptographic keys that may have been compromised, such as by disclosure to a third party maintaining cryptographic key history allocation of defined activation / de-activation dates. Cryptographic keys should be protected against unauthorised access or destruction and responsibilities for their management clearly assigned. Where a Public Key Infrastructure (PKI) is in use, standards / procedures should be established which define the: purpose of the PKI controls required to manage digital certificates / cryptographic keys within the PKI methods required to operate the PKI actions to be taken in the event of a compromise or suspected compromise of the PKI. Steps should be taken to provide very high levels of protection over the Certification Authority (CA) by: severely restricting access to it, for example by using access control mechanisms supported by strong authentication, such as tokens removing all known vulnerabilities on the operating system that supports the CA employing other general controls (eg change management) in a particularly disciplined manner. Contingency plans for the application should include methods of recovering the PKI in the event of a disaster.
37
CB63Electronic Commerce Applications

To ensure that the risks associated with applications that support electronic commerce are minimised. The business practices and privacy policies applicable to the web site(s) supporting the application should be independently accredited (for example, by WebTrust or TRUSTe). Web servers that support the application should be prevented from running with highlevel privileges on a day-to-day basis, initiating network connections to the Internet or uploading unknown files. Interfaces between web servers and back-office systems should be restricted to those services that are required by the application, channelled through documented application programming interfaces (APIs) and supported by mutual authentication. Web application sessions should be protected against being hijacked by ensuring that sessionIDs cannot be easily predicted and by configuring the security parameters in cookies. Sensitive data in transit should be protected against disclosure by encryption, such as SSL, and by using http PUT rather than GET operations. Key system configuration information (that could be useful to hackers) for example in the server field in http headers, or in source code (including executables, scripts, HTML or JavaScript) should not be inadvertently made available to third parties. Web content should be reviewed to ensure that: vulnerabilities have not been introduced by scripts or hidden form fields it is accurate and up-to-date hyperlinks are valid and functional.
38
Aspect IP Information Processing

Computer installations typically support critical business applications and safeguarding them is, therefore, a key priority. Since the same information security principles apply to any information processing activity - irrespective of where, or on what scale or types of computer it takes place - a common standard of good practice for information security should be applied.
Pages Area IP1 INSTALLATION MANAGEMENT IP11 Organisation IP12 Standards / Procedures IP13 Service Agreements IP14 System Documentation IP15 System Monitoring IP16 Outsourcing IP2 LIVE ENVIRONMENT IP21 Installation Design IP22 Host Configuration IP23 Workstation Configuration IP24 Resilience IP25 Hazard Protection IP26 Power Supplies IP27 Physical Access IP3 SYSTEM OPERATION IP31 Day-to-day Operations IP32 Handling Computer Media IP33 Back-up IP34 Incident Management IP35 Virus Protection IP4 ACCESS CONTROL IP41 Access Control Policies IP42 Access Control Arrangements IP43 User Authorisation IP44 Access Privileges IP45 Sign-on Process IP46 User Authentication IP47 Access Logging IP5 CHANGE MANAGEMENT IP51 Change Management Standards / Procedures IP52 Change Management Process IP53 Acceptance Criteria IP54 Emergency Fixes 41 42 42 43 43 44 45 46 46 47 47 48 48 49 50 51 51 52 53 54 55 56 57 58 59 60 61 62 62
Area
Area
Area
Area
39
Pages Area IP6 LOCAL SECURITY MANAGEMENT IP61 Security Organisation IP62 Security Awareness IP63 Security Classification IP64 Risk Analysis IP65 Security Audit / Review IP7 SERVICE CONTINUITY IP71 Contingency Plans IP72 Contingency Arrangements IP73 Validation and Maintenance 63 64 65 66 66 67 68 68
Area
40
Area
IP1 INSTALLATION MANAGEMENT

Computers used for processing information need to be well managed. Accordingly, this area covers the organisation of the people involved in running computer installations, the disciplines they are expected to follow, agreements made with business users, documentation and monitoring of the system(s) within the installation.
IP11 Organisation
To provide a sound management structure for personnel running the computer installation. Overall responsibility for information processing activity should be assigned to an individual. Responsibilities for key tasks should be assigned to individuals equipped with the know-how, skills and time to fulfil their roles. Responsibilities should be clearly assigned for: controlling the technical aspects of the installation, such as installation design, host or workstation configuration, access control and virus protection general management of the installation, such as day-to-day operations, incident management, change management, system monitoring and service continuity establishing service agreements with users of applications supported by the installation co-ordinating information security activity. The risk of staff disrupting the running of the installation either in error or by malicious intent should be reduced by: segregating the duties of personnel running the installation from those developing new systems ensuring all installation staff sign non-disclosure agreements reducing dependence on key individuals by automating tasks, ensuring complete and accurate documentation and arranging alternative cover of key positions closely controlling activities of installation staff, by supervision and recording of activity screening applicants for positions that involve running the installation, by taking up references, checking career history / qualifications and confirming identity, for example using a passport.
41
IP12 Standards / Procedures

To provide personnel running the computer installation with a clear statement of the disciplines they are required to follow. Personnel running the installation should be provided with formal, comprehensive and upto-date standards / procedures with which they should comply. Standards / procedures should specify: methods of controlling the technical aspects of the installation, such as installation design, host or workstation configuration, access control and virus protection general management of the installation, such as day-to-day operations, incident management, change management, system monitoring and service continuity the establishment of service agreements with users of applications supported by the installation information security responsibilities. Standards / procedures should be consistent with policies that apply across the enterprise, for example the high level information security policy. They should be documented, kept up-to-date, made available to all installation staff and reviewed periodically.
IP13 Service Agreements

To define the business requirements for services provided by the computer installation. Users service requirements should be classified in a way that identifies their criticality to the business and documented in formal agreements, such as contracts or service level agreements. Service agreements should specify: who is in charge of the business application(s) supported by the installation, and who is responsible for delivering the required service the level of criticality of the service capacity requirements, maximum processing response times, dates / times when services are required and critical timescales. Formal agreements should specify requirements for security controls, including: cryptography and segregation access controls to be applied change and incident management procedures protection against malicious code, including viruses and malicious mobile code downloaded from the web back-up, retention and archiving arrangements for ensuring continuity of service. Service agreements should be signed-off by all parties and their terms should be enforced and reviewed periodically.
42
IP14 System Documentation

To ensure the computer installation is supported by accurate, up-to-date system documentation. Standards / procedures should be established, which apply to system documentation. Accurate system documentation should be maintained for: the design of the installation, including configuration of all hosts / servers and attached devices software employed parameter settings communications links / services. System documentation should include copies of formal agreements with users. Details of installation components (including business information, software, computers and related documentation, equipment, facilities and services) should be recorded in inventories, or equivalent, and should contain the: identity of the component, such as a description or a unique identifier security classification identity of the owner (ie the individual responsible for the installation component) location of the component software and hardware version in use license conditions, such as the number of permissible users. Access to system documentation should be restricted to authorised personnel. Inventories of system documentation should be protected against unauthorised change, kept up-todate, periodically checked against physical assets and independently reviewed.
IP15 System Monitoring

To assess the performance of the computer installation, reduce the likelihood of system overload and detect potential or actual malicious intrusions. Systems associated with the computer installation should be continuously monitored. Monitoring activities should include: monitoring service levels against agreed targets reviewing service levels with user representatives and reporting them to the installation owner and to the owners of business applications supported by the installation recording current and projected volumes of work, utilisation of systems facilities and any potential bottlenecks or overloads scanning hosts for known vulnerabilities, using specialised products, such as COPS, Pingware or SATAN checking whether powerful utilities / commands have been disabled on attached hosts. System availability (ie response and up-time) should also be measured from the perspective of business users, for example by monitoring workstation performance.
43
IP16 Outsourcing
To ensure that security requirements are satisfied when the running of the computer installation is entrusted to an outsource contractor. Prior to outsourcing responsibility for the installation, an organisation should: subject the selection of outsource contractors and the transfer of responsibilities to a formal process identify risks and assess security practices employed by outsource contractors agree security controls, approve transfer and establish formal agreements. Formal agreements should oblige contractors to: comply with good business practice, report incidents and provide regular reports on system performance maintain the confidentiality / integrity of information gained in the course of work limiting access to authorised users maintain continuity of services in the event of a disaster apply agreed information security controls, ensuring legal and regulatory requirements, including those for data privacy, are met permit their activities to be audited provide compensation if service targets are not met. Arrangements should be made to: deal with a single point of contact within the outsource contractor provide sufficient technical resources to manage the relationship with the outsource contractor on an informed basis cover the possibility of services being interrupted for a prolonged period. Responsibility for managing the relationship with the outsource contractor should be assigned to a designated individual, equipped with sufficient technical skills and knowledge.
44
Area
IP2 LIVE ENVIRONMENT

Service targets are more likely to be achieved if computer installations are well designed. Accordingly, this area covers the design of the installation and the configuration of any related hosts and workstations. It also covers the resilience of the installation and its protection from physical loss or damage.
IP21 Installation Design

To ensure that the computer installation as a whole is designed using sound principles and processes. The installation should be designed to be consistent with other installations within the enterprise, and to be able to cope with current and future information processing requirements. The installation should be designed to: support consistent naming conventions, such as computer addresses, terminal locations and user identifiers be run from a single point enable users to be able to gain access to multiple systems within the installation via a single sign-on and be administered from a single point minimise the need for manual intervention. Live environments should be isolated from development and acceptance testing activity, by using different staff and systems. Key components of the installation should be protected by: segregating critical business applications from all other business applications, as agreed with their business owners storing source code in a secure location away from the live environment and restricting access to source code to authorised personnel segregating different types of software and data, for example by storing them in separate directories permitting only execute access to executable software keeping all systems clocks accurate.
45
IP22 Host Configuration

To ensure host systems operate as intended and do not compromise the security of the computer installation. Hosts should be configured in conformance with sound disciplines and in accordance with formal standards / procedures. Hosts should be configured to: disable or otherwise restrict particular functions or services, such as inessential or redundant services, communications that are inherently susceptible or prone to abuse, and powerful utilities or commands restrict access to powerful system utilities / host parameter settings to particular users or defined circumstances, logging their use. Hosts should be protected against unauthorised access by: changing default parameters set by suppliers prior to use disabling unnecessary or insecure user accounts, such as guest for UNIX or Windows NT consolidating all access and activity logs to enable focused review invoking time-out facilities that automatically log-off workstations after a set period of inactivity, clear screens and require users to sign-on again before restoring screens. A formal process should be established to identify new technical vulnerabilities in operating systems and ensure proven countermeasures are implemented quickly. Key software updates, such as patches or security fixes should be applied in a timely manner and subjected to change management disciplines.
IP23 Workstation Configuration

To ensure workstations operate as intended and do not compromise the security of the systems to which they are connected. Workstations connected to the installation should be purchased from a list of approved suppliers, tested prior to use, supported by effective maintenance arrangements and protected by physical controls. Each workstation should be: equipped with standard configurations of system and application software protected by the use of a comprehensive set of system management tools, access control mechanisms and up-to-date virus protection software automatically logged-off after a set period of inactivity. Additional controls should be implemented on workstations with the capability of connecting to the Internet, including: use of standard web browsers, with key software updates applied, and configured to prevent users from disabling security options warning users of the dangers of downloading mobile code and the implications of accepting or rejecting cookies strict disciplines over the downloading of mobile code.
46
IP24 Resilience
To ensure that the computer installation is supported by a robust and reliable set of hardware and software. Components that are critical to the functioning of the computer installation should be identified. Single points of failure should be minimised by the provision of duplicate or alternate: processors, for example using fault-tolerant systems on-line storage and file / database servers points from which the installation can be run. The resilience of critical communications equipment, software, links and services should be improved by: giving high priority to reliability, compatibility and capacity in the acquisition process using only proven products, keeping them up-to-date and in good running order ensuring that key equipment can be replaced quickly, by holding a stock of spares onsite and ensuring timely repairs.
IP25 Hazard Protection

To prevent services being disrupted by damage to computer equipment or facilities as a result of natural hazards. Computer equipment and facilities should be protected against fire, flood, environmental and natural hazards. Computer equipment and facilities should be: sited in locations that have a low risk of fire, flood, explosion, civil unrest and damage from neighbouring activities or natural disasters located in rooms that are free from intrinsic fire hazards (such as paper or chemicals), protected against the spread of fire and fitted with fire detection and suppression systems. The impact of hazards should be minimised by: training staff in the use of fire extinguishers (which should be located nearby) and other emergency / safety equipment establishing and testing emergency evacuation procedures. Fire alarms should be monitored, tested periodically and serviced in accordance with manufacturer specifications. The temperature / humidity of computer rooms should be monitored.
47
IP26 Power Supplies

To prevent services being disrupted by loss of power. Critical computer equipment and facilities should be protected against power outages. Power cables within the computer installation should be protected by concealed installation, locked inspection / termination points, alternative feeds or routing and avoidance of routes through public areas. Critical computer equipment should be protected by uninterruptible power supply (UPS) devices. Backup generators (supplied with adequate fuel) and emergency lighting should be provided in case of mains supply power failure. Emergency equipment such as UPS equipment and back-up generators should be serviced in accordance with manufacturers recommendations and tested periodically.
IP27 Physical Access

To ensure that only authorised individuals have physical access to the installation and to prevent services being disrupted by loss of or damage to equipment or facilities. Physical access to the information processing environment should be restricted to authorised personnel, by: fitting intruder alarms and locks activated by swipe cards or key pads requiring personnel to wear visible means of identification and encouraging them to challenge strangers recording the arrival / departure of visitors and supervising them at all times employing security guards and providing video surveillance issuing authorisations for physical access in accordance with formal standards / procedures, reviewing them periodically and revoking them when no longer needed, for example when staff leave the organisation. Physical controls should be provided to protect: important papers and removable storage media (such as CDs and diskettes) by locking them away when not in use, for example in compliance with a clear desk policy post / fax points and equipment used for sensitive printed material easily portable computers and components by using physical locks and indelibly marking vulnerable equipment.
48
Area
IP3 SYSTEM OPERATION

Achieving service targets requires installations to be run in accordance with sound disciplines. Accordingly this area covers day-to-day operations, basic disciplines (ie handling computer media, back-up) and arrangements for identifying and resolving incidents (ie incident management, virus protection).
IP31 Day-to-day Operations

To ensure individuals are equipped to run the computer installation under all conditions. Individuals who run the computer installation should be: equipped with the necessary know-how, skills and time to run the network under normal and peak conditions competent to deal with error, exception and emergency conditions required to report faults and other disruptive events. Individuals who run the installation should be supported by operating procedures that cover: start-up / close-down and restart / recovery processes scheduling routines and exception conditions handling of electronic business information and physical computer media restrictions on the use of system utilities back-up, recovery and retention change management incident management management / safety of the installation. Operating procedures should be: comprehensive documented readily accessible to authorised staff approved by the person in charge of the installation reviewed periodically protected against unauthorised access kept up-to-date and backed-up by copies stored off-site. Activities of individuals running the installation should be logged in sufficient detail and reviewed to enable swift diagnosis and resolution of incidents.
49
IP32 Handling Computer Media

To protect computer media in line with its information security requirements. Computer media (including magnetic tapes, disks, printed results, and stationery) should be handled in accordance with sound disciplines. The information held on data storage media should be protected by: keeping identifying labels free from descriptive information which might give unauthorised individuals a clue as to their contents providing strong storage arrangements in compliance with manufacturers storage recommendations including written authority for removal and recording of movements erasing the content of reusable storage media when no longer needed. Heightened protection should be provided for sensitive material by: labelling it with the correct security classification minimising distribution and confirming receipt of media recording authorised recipients, marking media with the recipients identity, and periodically reviewing records of authorised recipients ensuring all information is input / processed and that there is proper accounting for all computer media using fire-proof safes for storage disposing of it securely by erasure, incineration or shredding and recording its disposal.
50
IP33 Back-up
To prevent loss of essential information or software. Back-up versions of essential information and software used by the computer installation should be taken, according to a defined cycle. Back-up processes should be approved by business owners and comply with: enterprise-wide policies and standards / procedures business continuity plans legal, regulatory and contractual obligations long-term archiving requirements manufacturers recommendations for reliable storage, such as maximum shelf-life. Back-ups should be taken of master files / databases, transaction files, system programs / utilities, application software, parameter settings and system documentation. Back-ups should be: performed in accordance with a defined back-up / retention cycle that reflects security classifications, importance and time-criticality performed so that individual files can be recovered timestamped, reconciled to live versions and retained for at least three generations checked periodically to ensure recovery is possible clearly and accurately labelled, and protected from accidental overwriting stored in readily accessible locations on-site and supported by copies stored off-site protected in transit, for example by packing them in locked, robust containers and using only reputable couriers.
IP34 Incident Management

To identify and resolve incidents effectively, minimise their business impact and reduce the risk of similar incidents occurring. All types of incident (including malfunctions, loss of power, overloads, mistakes by users or computer staff, access violations) should be dealt with in accordance with a formal process. The incident management process should: ensure incidents are reported to a single point of contact specify requirements for the recording of incidents include categorising incidents by type and prioritising them according to their impact / urgency define procedures for dealing with incidents (including investigation, planning of remedial action, resolution, communication with users, supervising activity and documenting actions taken). Significant incidents should be reported to the installation owner who should assess their business impact. Patterns of incidents (including number and frequency) should be reviewed to diagnose common problems and to minimise their recurrence.
51
IP35 Virus Protection

To prevent disruption to the computer installation by computer viruses. Software and procedures should be implemented to prevent virus infection for computer installations that contain systems susceptible to viruses. Individuals running such systems should be made aware of the dangers posed by computer viruses, arrangements for dealing with suspected virus attacks and procedures for dealing with hoax viruses. The risk of virus infection should be reduced by: the use of anti-virus software, that runs at all times computers are in use, to scan computer memory, files and storage media the application of automatic update mechanisms for anti-virus software, at least on a weekly basis a formal process to help users deal with virus attacks, warning them to stop processing, note symptoms, identify the source and inform a single point of contact for support issuing directives that investigators should disconnect suspected computers from the network before powering them up and transfer suspect media, such as diskettes, to a dedicated quarantine computer.
52
Area
IP4 ACCESS CONTROL

Maintaining sound disciplines, enforced by effective access control mechanisms, can reduce the risk of unauthorised access to information and systems. Accordingly, this area covers the access control disciplines applied to users and the steps taken to control access to information and systems within the computer installation.
IP41 Access Control Policies

To restrict access to information and systems within the computer installation in accordance with defined policies. Access to the capabilities of the computer installation should be restricted according to formal, clearly defined access control policies. Formal access control policies should take account of: policies that apply enterprise-wide, for example a high-level information security policy the principle that access should be provided in line with business risk formal agreements with business owners and requirements set by the installation owner legal, regulatory and contractual obligations the need to achieve individual accountability, promote segregation of duties and apply additional controls over users with special access privileges. Access control policies should be:
applied rigorously supported by formal standards / procedures and clearly-defined responsibilities for business owners, users and specialist IT staff reviewed periodically and upgraded in response to new threats, capabilities, business requirements or access violations.
53
IP42 Access Control Arrangements

To provide mechanisms that restrict access by all types of user to specified components of the installation. Arrangements should be made to control access to information and systems within the computer installation. Access control arrangements should: cover access by business users, individuals running the installation and specialist IT staff, such as technical support staff cover information, application / system software, access control data, back-up files and system documentation restrict access in line with access control policies set by business owners. Access control arrangements should provide technical mechanisms to: restrict the system capabilities that can be accessed, for example by providing restricted menus prevent users from gaining access to system prompts, for example by making systems menu-driven prevent misuse of passwords, for example by using encryption, one-time passwords or stronger authentication, such as token-based authentication minimise the need for special access privileges. High-level administration activities should be limited to the system console only.
54
IP43 User Authorisation

To ensure that all users of the computer installation are authorised according to a sound process. All users of the computer installation should go through an authorisation process before they are granted access privileges. The process for authorising users should: be formally defined, controlled by one or more designated individuals and applied to all users associate access privileges with defined users, for example with UserIDs rather than passwords issue default access privileges of none (ie rather than read) ensure redundant UserIDs are not re-issued for use. A file or database containing details of all authorised users should be established and reviewed regularly. Details of authorised users should be: maintained by designated owners such as particular system administrators protected against unauthorised change or disclosure segregated from other information in the live environment held in a way that facilitates user identification and authentication recorded so that specific information and systems to which users have access can be identified recorded so that users of specific information and systems can be identified reviewed to ensure that access privileges are set at the right level and that access is still required.
55
IP44 Access Privileges

To provide authorised users with access privileges which are sufficient to enable them to perform their duties but do not permit them to exceed their authority. All users of the installation should be assigned a set of access privileges to allow them to read or change particular information or systems. Access privileges for business users should be assigned by business owners and specialised technical privileges assigned by the person in charge of the installation. Before access privileges come into effect: authorisations should be checked to confirm access privileges are appropriate details of UserIDs should be recorded users should be advised of their access privileges and associated conditions and required to confirm their understanding of those conditions. Access privileges should not be assigned collectively (ie to a group of users). In these cases where they need to be assigned collectively, they should be documented, approved by the business owner and subject to additional controls, such as restricted access privileges and contractual conditions. Additional controls should be applied to special access privileges, including high-level privileges (such as Root in UNIX or Administrator in Windows NT), powerful utilities and privileges that provide access to sensitive application capabilities. These controls should include: specifying the purpose of special access privileges restricting the use of special access privileges to narrowly defined circumstances and requiring individual approval for their use requiring users with special access privileges to sign-on using identification codes or tokens that differ from those used in normal circumstances. A process for terminating the access privileges of users should be established to ensure that: authentication details and access privileges are revoked promptly and on all systems to which the user had access access profiles / accounts are deleted components dedicated to providing access, such as tokens or modems, are disabled or removed.
56
IP45 Sign-on Process

To ensure that users follow a rigorous sign-on process before they can gain access to information or systems within the computer installation. Rigorous sign-on processes should be established for all systems within the computer installation. Sign-on mechanisms should be configured so that they: display no identifying details until after sign-on is successfully completed warn that only authorised users are permitted access validate sign-on information only when it has all been entered limit the number of unsuccessful sign-on attempts (for example a re-try limit of three) and disconnect users after the limit is reached record all unsuccessful sign-on attempts limit the duration of any one sign-on session and automatically re-invoke sign-on after an interruption of the process, for example when a connection is broken advise users - on successful sign-on - of their most recent previous sign-on and any other attempted sign-ons do not store authentication details in clear text, such as in scripts, macros or cache memory. The approval of the installation owner should be obtained before any important features of the sign-on process are bypassed, disabled or changed.
57
IP46 User Authentication

To ensure that all users are identified and authenticated before they can gain access to any information or systems within the computer installation. All users should be authenticated, either by using UserIDs and passwords or by stronger authentication such as smartcards or biometric devices such as fingerprint recognition. Users should be advised of good practice for selecting, using and protecting passwords. They should be warned to keep passwords confidential (ie to avoid disclosing them to anyone or writing them down) and to change passwords that may have been compromised. User authentication should be enforced by automated means that: ensure UserIDs, passwords and their combination are unique issue temporary passwords to users that must be changed on first use ensure users set their own passwords ensure passwords are a minimum number of characters in length, differ from their associated UserIDs, contain no more than two identical characters in a row and are not made up of all numeric or alpha characters ensure passwords are changed at least every 30 days and more frequently for users with special access privileges restrict the re-use of passwords within a set period or set number of changes. Processes for issuing new or changed passwords should ensure that: passwords are not sent in the form of clear text e-mail messages the person to whom the password uniquely applies is directly involved the identity of the target user is verified, such as via a special code or through independent confirmation. Strong authentication, such as token-based authentication, should be applied to users with access to critical business applications, sensitive information, special access privileges or with external access capabilities.
58
IP47 Access Logging

To ensure individual accountability and to enable incidents, such as access violations, to be investigated and resolved. Access to information or systems within the computer installation should be logged. The person in charge of the installation should determine which access events are to be logged (including sign-on and files accessed) and the review process to be followed (including frequency and responsibility). Access logs should be turned on at all times and protected from accidental or deliberate overwriting. Mechanisms should be established so that systems are not halted when logs become full and that logging continues with little or no disruption. Logs should include details of access by all types of user, servicing activities, failed signon attempts and error / exception conditions. Sufficient information should be recorded to identify: individual UserIDs, particular capabilities accessed (such as software, commands or files) and the dates / times of access access paths (including computers / ports from which access was gained) patterns of access to enable tracking of transactions or particular user activity changes to access logging parameters. Logs should be reviewed periodically, based on the business impact of potential or actual access violations and be conducted using automated tools.
59
Area
IP5 CHANGE MANAGEMENT

Changes to computer installations (ie enhancements, software fixes, data adjustments, hardware / software upgrades) often have unforeseen effects, and may accidentally or deliberately impact service levels or compromise security controls. Sound management can reduce the risk of such incidents occurring. Accordingly, this area covers the disciplines applied throughout the change process.
IP51 Change Management Standards / Procedures

To ensure changes to the computer installation are made in conformance with sound disciplines. Changes to the computer installation should be made in accordance with formal standards / procedures. Formal change management standards / procedures should cover changes of all types, including software or equipment upgrades, software fixes, changes to business information, updating of parameter settings and correction of erroneous information. Formal change management standards / procedures should cover changes to: tailor-made software, integrated application packages and desk-top products systems software including operating systems and utilities file / database formats and structures computers and related equipment communications networks, including new methods of connection.
60
IP52 Change Management Process

To ensure that changes do not affect the availability of the computer installation or compromise the confidentiality / integrity of associated business information. Changes affecting the computer installation should be made in accordance with a formal process. Prior to promotion to the live environment, arrangements should be made to ensure that: change requests are documented, for example using a change request form, only accepted from authorised individuals, and approved by a business owner before work commences the impact of changes is assessed, and reviews performed to ensure that changes do not compromise security controls changes are rigorously tested, and synchronised across all key components of the installation changes are checked and authorised by all relevant individuals software is checked to ensure it does not contain malicious code including a Trojan Horse or a virus the installation can recover from failed changes. Changes should be performed by individuals equipped with adequate skills, know-how and tools, under the supervision of an IT specialist. Changes should be made to a copy of the software prior to use in the live environment. Arrangements should be made to ensure that once changes have been applied: version control is maintained, documentation is updated and details of changes are communicated to all relevant users a record is maintained showing what was changed, when and by whom checks are performed to confirm that only intended code has been changed before and after contents of key records, (for example within customer master files) have been scrutinised.
61
IP53 Acceptance Criteria

To ensure rigorous acceptance criteria are met before new systems and significant changes are made to the computer installation. Formal criteria should be established to cover the implementation of new or significantly changed systems. Prior to accepting new systems and significant changes in the live environment, checks should be made to ensure that: security assessments have been carried out and limitations of security controls documented performance and capacity requirements can be fulfilled all development problems have been successfully resolved there will be no adverse effect on existing live systems the system can be supported on a continuing basis, such as via a help desk arrangements for fall-back have been established in the event of the changes made failing to function as intended sign-off has been obtained from the business owner error recovery and restart procedures have been established and computer contingency plans have been developed / updated operating procedures have been tested users have been educated in the use of the system and computer staff are trained to run the system correctly. Software should only be installed in the computer installation in the form of executable code. Old software, procedures and documentation should be discontinued. Acceptance checks should ensure that only tested and approved versions of software are accepted into the live environment and new / upgraded software is successfully distributed without unauthorised change. Responsibility should be transferred to individuals running the systems once the installation is complete.
IP54 Emergency Fixes

To enable unforeseen problems to be addressed in a timely yet disciplined manner. Formal standards / procedures should be established that cover emergency fixes to computer equipment, business application software, systems software, parameter settings, business information and system details. Formal standards / procedures should cover emergency access by business owners or users, system administrators, systems development staff and suppliers of equipment, software or services. Emergency fixes should be made in accordance with formal standards / procedures, logged, and approved by the most senior manager present. Once fixes have been made, authorisation for emergency access should be revoked immediately. Emergency fixes should then be documented, subjected to normal change management disciplines, and reviewed by the installation owner. Steps should be taken to ensure that emergency fixes are not left permanently in place.
62
Area
IP6 LOCAL SECURITY MANAGEMENT

A computer installation typically supports one or more critical business applications, holds information that needs to be protected, and is an important asset in its own right. Each of these perspectives needs to be considered in order to provide appropriate protection. Accordingly, this area covers the arrangements made to ensure that information security is managed and co-ordinated for the installation as a whole.
IP61 Security Organisation

To provide a top-down management structure and a practical mechanism for co-ordinating the information security arrangements of the computer installation. The person in charge of the computer installation should be personally accountable for the information security of the installation. One or more individuals (ie local security coordinators) should be made responsible for co-ordinating the information security arrangements of the installation and act as a single point of contact on information security issues. Local security co-ordinator(s) should: have a sound understanding of their information security roles be equipped with the know-how, skills, time, tools, contacts and authority needed to carry out their assigned role be supported by procedures for day-to-day security administration and up-to-date information on issues related to information security maintain a channel of communication with their counterparts in other parts of the enterprise and with the organisational unit responsible for promoting good practice in information security across the enterprise. Local security co-ordinator(s) should meet periodically with the person responsible for the installation and user representatives, to review the status of information security and agree security activities to be performed.
63
IP62 Security Awareness

To maintain awareness of information security among individuals who run or use the computer installation. Individuals involved in information processing activity should be aware of the high-level information security policy that applies across the enterprise, and comply with it. These individuals should include business owners, users and personnel who run the installation. Individuals involved in information processing activity should be made aware of: the meaning of information security and why it is needed the importance of complying with information security policies and applying associated standards / procedures their personal responsibilities for information security particular security threats to the installation. Individuals involved in information processing activity should be made aware that they are prohibited from: using any part of the installation without authorisation or for purposes that are not work-related making obscene, racist or otherwise defamatory statements, for example through the installation via e-mail or over the Internet illicit copying of information or software disclosing confidential information (such as customer records, product designs or pricing policies).
64
IP63 Security Classification

To classify the computer installation according to its criticality in order to communicate how it should be treated. The computer installation should be classified using a security classification scheme that applies across the enterprise. The classification scheme should take account of the: business impact of a loss of confidentiality, integrity or availability sensitivity of information to be stored in or processed by the installation vulnerability of the installation to particular threats. Security classifications should be: used to establish the criticality of business applications supported by the installation applied to all information in electronic or paper form, all software and hardware, and to services provided by external parties approved by the person in charge of the installation reviewed by the local security co-ordinator and the individuals in charge of the business applications supported by the installation revised periodically in the light of changing circumstances recorded in formal agreements with users, such as service level agreements. Details of security classifications should be recorded in an inventory and should include: the identity of the individual responsible for them unique identifiers such as descriptive titles the security classification an access policy defining who is authorised to access the information or installation component the identity of the legal entity that owns each object. The computer installation should be protected in line with its security classification.
65
IP64 Risk Analysis

To identify key risks associated with the computer installation and determine the controls required in order to keep those risks within acceptable limits. A formal risk analysis should be carried out periodically for computer installations that support critical business applications. The risk analysis technique used should: include identification of critical business applications supported by the installation and a review of associated service level agreements involve representatives of key areas, such as business owners of critical business applications supported by the installation, the person in charge of the installation, an IT specialist and an expert in risk analysis determine business risk (taking into account the criticality of the installation, the business impact of a loss of confidentiality, integrity or availability, key threats and vulnerabilities) consider the full range of controls needed to keep risks within acceptable limits. The results of the risk analysis should include a clear indication of key risks, an assessment of their potential business impact and recommendations for the actions required to reduce risk to an acceptable level. The results (including any residual risk) should be reviewed and agreed by the person in charge of the installation, and communicated to the owners of business applications supported by the installation. Agreed actions should be implemented and a process established to ensure that this is done effectively.
IP65 Security Audit / Review

To provide the person in charge of the computer installation, and top management, with an independent assessment of the security of the installation. The information security status of the computer installation should be subject to thorough, independent and regular security audit / reviews. Security audits / reviews should cover installation management, the live environment, system operation, access control, change management, local security management and service continuity. Security audits / reviews should assess the business risks associated with the installation by: reviewing the information security requirements of the business applications supported by the installation evaluating the installations vulnerability to key threats. Security audits / reviews of the installation should be: agreed with the person in charge of the installation defined in scope and documented performed by qualified individuals and checked by competent personnel supported by the use of automated software tools. Agreed recommendations from security audits / reviews should be implemented and reported to top management.
66
Area
IP7 SERVICE CONTINUITY

If there is a serious interruption to information processing, for example if a disaster occurs, the computer installation may be unavailable for a prolonged period. Considerable forethought is required to enable information processing to continue in these circumstances and to keep the business impact to a minimum. Accordingly, this area covers the development and content of contingency plans, and the coverage and validation of contingency arrangements.
IP71 Contingency Plans

To provide individuals with a documented set of actions to perform in the event of a disaster, enabling information processing to be resumed within critical timescales. Contingency plans should be formulated to ensure that staff are aware of the steps they would be required to take in the event of a disaster affecting the computer installation. The format and content of contingency plans should comply with enterprise-wide standards / procedures, form part of a wider business continuity plan and be distributed to all individuals who would require them in case of an emergency. Such individuals should be informed of their responsibilities and equipped to fulfil them. Contingency plans should be developed in conjunction with user representatives, and based on: a set of scenarios for possible disasters assessments of the business impact of such scenarios identification of the key business processes to be protected by the plan. Plans should include: conditions for their invocation the critical timescales associated with the business applications supported by the installation a schedule of key tasks to be carried out, responsibilities for each task and a list of services to be recovered, in priority order information security controls applied during the recovery process arrangements for processing from last successful back-up to time of disaster and then to resumption of normal service provisions for the clearance of any processing back-logs that may have built up during the system outage resuming processing using alternative facilities procedures specified in sufficient detail to be followed by individuals who do not normally carry them out. Custody of the contingency plan should be the responsibility of a specific individual or group and copies of the plan should be stored securely off-site.
67
IP72 Contingency Arrangements

To enable processing to continue in the event of a disaster. Alternative information processing arrangements should be established to enable services to continue in the event of a disaster affecting the computer installation. The arrangements should cover prolonged unavailability of: key individuals, buildings or access to buildings business information or system / application software essential services such as electricity, water, telephone lines and data communications system documentation. Contingency arrangements should cover all locations and users supported by the installation. Key components of the installation should be covered by insurance arrangements that address key risks (such as loss of data, business interruption, or liabilities to third parties) and provide adequate protection against likely threats (such as fire, theft, fraud or malicious damage).
IP73 Validation and Maintenance

To ensure that information processing can resume within critical timescales, using alternative facilities. Regular tests should be conducted of the contingency arrangements for the computer installation. Tests of contingency arrangements should: be carried out in accordance with a defined schedule be performed after significant changes are made to contingency arrangements be carried out periodically, and at least annually include realistic simulations involving both users and IT staff demonstrate that information processing can resume using alternative facilities within critical timescales. Contingency arrangements should be: the responsibility of a designated individual or working group updated following significant changes to business processes revised in response to problems encountered during tests / rehearsals. The need for changes should be considered at least monthly and contingency arrangements as a whole should be reviewed at least annually.
68
Aspect CN Communications Networks

Communications networks convey information and provide a channel of access to information systems. By their nature, they are highly vulnerable to disruption and abuse. Safeguarding business communications requires robust network design, well-defined network services, and sound disciplines to be observed in running networks and managing security. These factors apply equally to local and wide area networks, and to data or voice communications.
Pages Area CN1 COMMUNICATIONS MANAGEMENT CN11 Organisation CN12 Standards / Procedures CN13 Network Design CN14 Network Resilience CN15 Network Documentation CN16 Service Providers CN17 Outsourcing CN2 TRAFFIC MANAGEMENT CN21 Configuring Network Devices CN22 Traffic Filtering CN23 External Access CN3 NETWORK OPERATIONS CN31 Day-to-day Operations CN32 Network Monitoring CN33 Incident Management CN34 Change Management CN35 Physical Security CN36 Back-up CN37 Service Continuity CN38 Remote Maintenance CN4 LOCAL SECURITY MANAGEMENT CN41 Security Organisation CN42 Security Awareness CN43 Security Classification CN44 Risk Analysis CN45 Security Audit / Review CN5 VOICE COMMUNICATIONS CN51 Policies and Documentation CN52 Resilience CN53 Special Controls 70 71 71 72 72 73 74 75 76 77 78 79 79 80 80 81 81 81
Area
Area
Area
82 82 83 84 84 85 85 86
Area
69
Area
CN1
COMMUNICATIONS MANAGEMENT
Computer networks are complex. They have to link different systems together, are subject to constant change and often rely on services provided by external parties. Orchestrating the technical and organisational issues involved requires sound management. Accordingly, this area covers: the standards / procedures and organisational arrangements applied to the network; its design, configuration and documentation; and the management of relationships with service providers and outsource contractors. Section Objective Standard of good Practice
CN11 Organisation
To provide a sound management structure for personnel running the network. Overall responsibility for network activity should be clearly assigned to an individual. Responsibilities for network activity should be assigned to individuals who are equipped with the know-how, skills and time to fulfil their roles. Responsibility should be clearly assigned for: controlling the technical aspects of the network such as network design, configuration management, traffic management and network monitoring the general management of the network environment, such as day-to-day operations, incident management and change management establishing service agreements, such as those with users or external service providers methods of co-ordinating information security activity. The risk of staff disrupting the running of the network either in error or by malicious intent should be reduced by: segregating the duties of staff running the network from those developing / designing the network ensuring all network staff sign non-disclosure agreements reducing dependence on key individuals by automating key tasks, ensuring complete and accurate documentation and arranging alternative cover for key positions closely controlling activities of network staff, by supervision and recording of activity screening applicants for positions that involve running the network, by taking up references, checking career history / qualifications and confirming identity, for example using a passport.
70
CN12 Standards / Procedures

To provide personnel running the network with a clear statement of the disciplines they are required to follow. Network staff should be provided with formal standards / procedures with which they should comply. Standards / procedures should specify: methods of controlling the technical aspects of the network including network design, resilience, configuration management, traffic management and network monitoring general management of the network environment, including day-to-day operations, incident management and change management the establishment of service level agreements, such as those with users or external service providers information security responsibilities. Network standards / procedures should be documented, kept up-to-date, communicated to all network staff and reviewed periodically.
CN13 Network Design

To produce an operational network, based on sound design principles, that has security functionality built-in and enables additional controls to be incorporated easily. Networks should be designed in conformance with sound disciplines. The network should be designed to: be compatible with other networks used by the enterprise cope with foreseeable developments in the enterprises use of IT (such as by performing growth projections and adopting open / proprietary standards). The design of the network should: incorporate coherent technical standards, support consistent naming conventions and comply with statutory and industry regulations incorporate distinct sub-networks, protected by rule-based traffic filtering, for example using firewalls minimise single points of failure and the number of entry points into the network allow the network to be remotely configured enable network management reports and audit trails to be maintained. Network design should be supported by formal documentation of users service requirements.
71
CN14 Network Resilience

To ensure that the network is supported by a robust and reliable set of hardware and software. Communications facilities that are critical to the continuity of network services should be identified. Single points of failure should be minimised by: automatic re-routing of communications should critical nodes or links fail routing critical links to more than one external exchange or switching centre the provision of duplicate or alternate secure gateways, such as firewalls, main switching nodes and critical power supplies arranging fall-back to alternative service providers. The risk of malfunction of critical communications equipment, software, links and services should be reduced by: giving high priority to reliability, compatibility and capacity in the acquisition process using only proven products, keeping them up-to-date and in good running order ensuring that key network components can be replaced quickly using modern protocols that can be updated quickly and withstand high capacity.
CN15 Network Documentation

To ensure that the network is supported by accurate, up-to-date, documentation. Standards / procedures should be established, which apply to network documentation. Accurate documentation (in paper or electronic form) should be maintained for: the configuration of the network, including all nodes and connections communications equipment, software, links and services, including up-to-date inventories and labelling of equipment in-house cabling including identification of cable runs and labelling of cables. Network documentation (ie diagrams, inventories and schedules) should be: generated automatically, using software tools, and kept-up-to-date readily accessible to authorised personnel, and subject to supervisory review checked periodically to ensure that no unauthorised changes have been made.
72
CN16 Service Providers

To define the business requirements, including those for security, to be met by service providers. Communication services obtained from service providers (internal or external) should be defined in formal agreements, such as service level agreements or contracts, and obtained from reputable sources. Formal agreements with service providers should specify: responsibilities, capacity requirements, dates / times when network services are required and critical timescales of the network points to be connected and methods of connection including types of network services or protocols restrictions on methods of connection and access to particular services. Formal agreements should specify requirements for security controls, including: arrangements for ensuring continuity of service and segregation of network components, such as dedicated lines for sensitive traffic change management processes arrangements for incident management methods of detecting / recovering from service interruptions protecting confidential data in transit, for example using encryption. The terms of formal agreements should be enforced and reviewed periodically. Arrangements should be made to: deal with service providers via a single point of contact restrict the use of services to those provided by reputable parties ensure an acceptable level of security obtain independent confirmation of security controls applied by service providers.
73
CN17 Outsourcing
To ensure that security requirements are satisfied when the running of the network is entrusted to an outsource contractor. Prior to outsourcing responsibility for all or part of a network, an organisation should: subject the selection of outsource contractors and the transfer of responsibilities to a formal process identify risks and assess security practices employed by outsource contractors agree security controls, approve transfer and establish formal agreements. Formal agreements should oblige contractors to: comply with good business practice, report incidents and provide regular reports on network performance maintain the confidentiality / integrity of information gained in the course of work, limiting access to authorised users maintain continuity of services in the event of a disaster apply agreed information security controls, ensuring legal and regulatory requirements (including those for data privacy) are met permit their activities to be audited and to provide compensation if service targets are not met. Arrangements should be made to: deal with a single point of contact within the outsource contractor provide sufficient resources to manage the relationship with the outsource contractor on an informed basis cover the possibility of network services being interrupted for a prolonged period. Responsibility for managing the relationship with the outsource contractor should be assigned to a designated individual, equipped with sufficient technical skills and knowledge.
74
Area
CN2
TRAFFIC MANAGEMENT
Communications networks can handle many types of network traffic from a wide variety of sources. To manage network traffic effectively, network devices have to be configured correctly and particular types of network traffic denied access. Accordingly, this area covers the disciplines required to ensure undesirable network traffic or unauthorised external users are prevented from gaining access to specified parts of the network. Section Objective Standard of good Practice
CN21 Configuring Network Devices

To ensure important network devices function as required and do not compromise the security of the network. Network devices (including network servers, routers, front-end processors, bridges, concentrators, switches or firewalls) should be configured to: highlight overload or exception conditions log events in a form suitable for review, and write them to a separate system copy control information (including logs and tables) to removable media and integrate with access control mechanisms restrict use to authorised personnel, for example using access control software that supports individual accountability disallow inessential services that are not required for the standard operation of the network. Network devices that perform traffic routing should be configured to prevent unauthorised or incorrect updates by configuring them to: verify the source and destination of routing updates, for example by checking IP addresses protect the exchange of routing information, for example using passwords or encryption. Network devices should be reviewed regularly to verify configuration, by checking parameters and scrutinising activity logs.
75
CN22 Traffic Filtering

To ensure unauthorised or undesirable network traffic is not allowed to gain access to specified parts of the network. Network traffic should be routed through an effective filtering device, such as a firewall, prior to being allowed access to the network. Network filtering devices should be configured to: filter specified types of traffic including IP addresses, TCP ports or information about the state of communications and users block or otherwise restrict particular types or sources of traffic, such as those that can be used to execute denial of service attacks limit the use of communications that are prone to abuse. Filtering of traffic should be based on pre-defined rules or tables that: have been developed by trusted personnel, and are subjected to supervisory review are based on the principle of least access are documented and kept up-to-date take account of a high-level security policy, and user requirements are verified to confirm strength and correctness and subject to strict change management disciplines prior to any changes being applied. Steps should be taken to ensure that network filtering devices: cannot be bypassed can only be accessed from designated workstations or specified IP addresses are supported by a process for dealing with suspected vulnerabilities and failure. Divulgence of information about the network should be limited, for example by using network address translation and proxy servers.
76
CN23 External Access

To ensure that only users who are authorised and authenticated are granted external access to the network. All external connections to the network should be individually identified, approved by the network owner, recorded (for example in an inventory) and assigned an owner. The network should be configured to: verify the source of external connections, for example using Calling Line Identification (CLI) restrict connections to defined entry points, such as via specific gateways route access through a network filtering device, such as a firewall restrict access to only specified parts of the network conceal network names and topologies from external parties, such as via the use of dual or split network directories / name servers. Unauthorised connections should be identified by: performing manual audits of network equipment and documentation to identify discrepancies with records of known external connections employing network management and diagnostic tools, such as port probes and network discovery tools checking accounting records of bills paid to telecommunications suppliers and reconciling them against known connections war-dialling the organisations PABX to detect unauthorised modems. External access should be provided using a dedicated remote access server, running an authentication system such as Radius or TACACS+. The dedicated remote access server should log all connections and sessions and help identify possible security breaches, for example by logging all events in a database and collating them centrally. External connections should be removed promptly when no longer required and any dedicated components disabled or removed.
77
Area
CN3
NETWORK OPERATIONS
Maintaining the continuity of service to users requires networks to be run in accordance with sound disciplines. Accordingly this area covers the arrangements made to run the network, monitor performance and to manage changes and incidents. In addition, the area covers the arrangements required to provide physical security, take back-ups and ensure service continuity. Section Objective Standard of good Practice
CN31 Day-to-day Operations

To ensure network staff are equipped to run the network under all conditions. Staff who run the network should be: aware of the existence and importance of information security controls equipped with the necessary know-how, skills and time to run the network under normal and peak conditions competent to deal with error, exception and emergency conditions required to report faults and other disruptive events. Staff who run the network should be supported by comprehensive, documented procedures that: help them run the network, administer network addresses / users and back-up key files such as control tables and settings are readily accessible and approved by the person in charge of the network are kept up-to-date and supported by copies stored off-site.
78
CN32 Network Monitoring

To assess the performance of the network, reduce the likelihood of network overload and detect potential or actual malicious intrusions. The network should be continuously monitored. Monitoring activities should include: monitoring service against targets reviewing service levels with user representatives and reporting them to the network owner the formal investigation of current and projected volumes of network traffic, utilisation of network facilities and any potential bottlenecks or overloads scanning the network for known vulnerabilities, such as by using specialised products, such as COPS, Pingware or SATAN checking whether powerful utilities / commands have been disabled on attached hosts, for example using a sniffer logging key network activities and reviewing them regularly, investigating any unusual entries. Intrusion detection mechanisms should be employed that include: detection of known attack characteristics, for example those associated with Ping of Death or SYN flooding a process for regular update to incorporate new or updated attack characteristics provision of alerts when suspicious activity is detected, and formal procedures for responding to suspected intrusions. The use of powerful analysis / monitoring tools, such as protocol analysers should be restricted to authorised users.
CN33 Incident Management

To identify and resolve incidents effectively, minimise their business impact and reduce the risk of similar incidents occurring. All types of incident (including malfunctions, loss of power / communications services, overloads, mistakes by users or computer staff, access violations) should be dealt with in accordance with a formal process. The incident management process should: ensure incidents are reported to a single point of contact specify requirements for the recording of incidents include categorising incidents by type and prioritising them according to their impact / urgency define procedures for dealing with incidents (including investigation, planning of remedial action, resolution, communication with users, supervising activity and documenting actions taken). Significant incidents should be reported to the network owner who should assess their business impact. Patterns of incidents (including number and frequency) should be reviewed by the network owner to diagnose common problems and to minimise their recurrence.
79
CN34 Change Management

To ensure that changes to the network do not affect its availability or compromise the confidentiality / integrity of network traffic and target systems. Changes affecting the network should be made in accordance with a formal process. The process should apply to all forms of change, such as: the roll-out of new services to users or the introduction of new services from service providers the addition or deletion of network nodes upgrades of communications equipment or software revisions to parameter settings in communications controllers temporary or emergency fixes to any part of the network. Prior to being implemented, changes should be rigorously tested and their impact assessed. Network changes should be supervised, documented and formally accepted by the network owner. Once made, changes should be reviewed to ensure that they have been made according to specification. Versions of equipment / software should be kept consistent across the network.
Section Objective
CN35 Physical Security

To ensure that only authorised individuals have physical access to network facilities, and to prevent services being disrupted by loss of or damage to communications equipment, power or facilities. Physical access to communications equipment and facilities should be restricted to authorised personnel. Suppliers or service engineers should be supervised when they have access to communications equipment. Critical areas, such as network operation centres or equipment rooms, including those at remote sites, should be protected from: natural hazards such as fire and flood power failure, such as by the use of uninterruptible power supplies unauthorised access, such as by locks on doors and shutters on windows. Communications cables should be protected by concealed installation, armoured conduit, locked inspection / termination points, alternative feeds or routing and avoidance of routes through public areas. Fibre optic cables should be used to reduce the risk of data in transit being intercepted.
80
CN36 Back-up
To prevent loss of essential network information or software. Back-up versions of essential network information and software (including communications software and utilities, network control tables / settings, configuration diagrams and inventories) should be taken, according to a defined cycle. Steps should be taken to verify that the back-up versions are readable and can be restored within the critical timescale of the network (ie the point beyond which unacceptable loss would be suffered). Back-ups should be protected from loss, damage and unauthorised access. They should be stored in a fireproof safe on-site and copies kept off-site.
CN37 Service Continuity

To enable network services to continue in the event of a disaster. Arrangements should be made to enable services to continue in the event of a disaster affecting the network. The arrangements should: be the responsibility of a particular individual or working group be based on a thorough analysis of risk, reviewed by user representatives, approved by the person in charge of the network and subject to a formal change management process cover prolonged unavailability of network operation centres, critical communications equipment, links, services, facilities, personnel, buildings or access to buildings be documented in a formal plan and updated following significant changes (such as to network services / facilities and legal, regulatory or contractual obligations). To ensure that services can continue within the critical timescale of the network (ie the point beyond which unacceptable loss would be suffered), periodic tests or rehearsals should be carried out using realistic simulations, involving network personnel. Key components of the network should be covered by insurance arrangements. These arrangements should address key risks, such as loss of data, business interruption, or liabilities to third parties and provide adequate protection against likely threats, for example fire, theft, fraud or malicious damage.
CN38 Remote Maintenance

To prevent unauthorised access to the network through the misuse of remote maintenance facilities. Remote maintenance should be tightly managed by: defining and agreeing the objectives of the planned remote maintenance restricting access rights and logging all activity revoking access rights and changing passwords immediately after agreed maintenance is complete authorising sessions individually and providing independent supervision of all activity. Diagnostic ports on network equipment should be protected by access controls, such as passwords and physical locks.
81
Area
CN4
LOCAL SECURITY MANAGEMENT
Communications networks play an essential role in the functioning of many critical business applications. They convey information that needs to be protected, and are valuable assets in their own right. Each of these perspectives needs to be considered in order to achieve network security. Accordingly, this area covers the arrangements made to ensure that information security is managed and co-ordinated for the network as a whole. Section Objective Standard of good Practice
CN41 Security Organisation

To provide a top-down management structure and a practical mechanism for co-ordinating the information security arrangements of the network. The person in charge of a network should be personally accountable for the information security of the network. One or more individuals (ie local security co-ordinators) should be made responsible for co-ordinating the information security arrangements of the network and acting as a single point of contact on information security issues. The local security co-ordinators should: have a sound understanding of their information security roles be equipped with the know-how, skills, time, tools, contacts and authority needed to carry out their assigned role be supported by procedures for day-to-day security administration and up-to-date information on issues related to information security have a channel of communication with their counterparts in other parts of the enterprise and a reporting line to the organisational unit responsible for promoting good practice in information security across the enterprise. The local security co-ordinators should meet periodically with the person responsible for the network to review the status of information security and agree security activities to be performed.
CN42 Security Awareness

To maintain awareness of information security among personnel who run the network. Network staff should be aware of the high-level information security policy that applies across the enterprise, and comply with it. Network staff should be made aware of: the meaning of information security and why it is needed the importance of complying with information security policies and applying associated standards / procedures their personal responsibilities for information security particular security threats to the network. Network staff should be made aware that they are prohibited from: using any part of the network without authorisation or for purposes that are not workrelated making obscene, racist or otherwise defamatory statements (using e-mail or other network services) illicit copying of information or software disclosing confidential information (such as network designs or IP addresses) or compromising passwords (such as writing them down or disclosing them to others).
82
CN43 Security Classification

To classify the network according to its criticality in order to communicate how it should be treated. The network should be classified using a security classification scheme that applies across the enterprise. The classification scheme should take account of the: business impact of a loss of confidentiality, integrity or availability sensitivity of information transmitted across the network vulnerability of the network to particular threats. Security classifications should be: used to establish the criticality of the network and systems accessible through the network applied to all information in electronic or paper form, all software and hardware, and to services provided by external parties approved by the person in charge of the network reviewed by the local security co-ordinator and the individuals in charge of the business applications supported by the network revised periodically in the light of changing circumstances recorded in formal agreements with users, such as service level agreements. Details recorded for objects which have been classified (including information, hardware, software and services) should be recorded in an inventory and include: the identity of the individual responsible for each object unique identifiers such as descriptive titles their security classification an access policy (ie definition of who is entitled access) the identity of the legal entity that owns each object. Networks should be protected in line with their security classification.
83
CN44 Risk Analysis

To identify key risks associated with the network and determine the controls required in order to keep those risks within acceptable limits. A formal risk analysis should be carried out periodically for networks that support critical business applications. The risk analysis technique used should: include identification of critical business applications supported by the network and a review of associated service level agreements involve representatives of key areas, such as business owners of critical business applications supported by the network, the person in charge of the network, an IT specialist and, for critical business applications, an expert in risk analysis determine business risk (taking into account the criticality of the network, the business impact of a loss of confidentiality, integrity or availability, key threats and vulnerabilities) take into account the full range of controls needed to keep risks within acceptable limits. The results of the risk analysis should include a clear indication of key risks, an assessment of their potential business impact and recommendations for the actions required to reduce risk to an acceptable level. The results (including any residual risk) should be reviewed and agreed by the person in charge of the network, and communicated to the owners of critical business applications supported by the network. Agreed actions should be implemented and a process established to ensure that this is done effectively.
CN45 Security Audit / Review

To provide the person in charge of the network, and top management, with an independent assessment of the security of the network. The information security status of the network should be subject to thorough, independent and regular security audit / review. Security audits / reviews should cover network management, traffic management, network operations and security management. Security audits / reviews should assess the business risks associated with the network by: reviewing the information security requirements of the business applications supported by the network evaluating the networks vulnerability to key threats. Security audits / reviews of the network should be: agreed with the person in charge of the network defined in scope and documented performed by qualified individuals and checked by competent personnel supported by the use of automated software tools. Agreed recommendations from Security audits / reviews should be implemented and reported to top management.
84
Area
CN5
VOICE COMMUNICATIONS
Business processes can be disrupted if telephone systems go down or are overloaded. Harm can also be caused if telephone systems are subject to unauthorised use by outsiders, or sensitive conversations are compromised. Accordingly, this area covers the security arrangements applied to voice communications. Section Objective Standard of good Practice
CN51 Policies and Documentation

To provide employees with a clear statement of the disciplines they are expected to follow in relation to voice communications and to maintain a record of voice facilities in use. There should be formal policies for voice communications, including use of the enterprises telephones, administration of telephone users, registration and authentication of users with access to voice-mail and guidelines for handling threatening or abusive calls. Key components of in-house telephone exchanges should be documented, such as configurations and settings, and an inventory maintained of telephones and associated wiring / cables.
CN52 Resilience
To provide continuity of service to users of voice communication facilities. In-house telephone exchanges should: have sufficient capacity to cope with peak workloads and expansion / upgrade capabilities to cope with projected demand be supported by alternative power supplies, such as batteries, to cope with brief power outages have a control and monitoring facility capable of providing reports on usage, traffic and response statistics be housed in secure physical environments be supported by contingency plans and arrangements. Steps should be taken to ensure that in-house telephone exchanges have: duplicate or alternative processors, alternative groups of exchange lines and routes to more than one main external exchange emergency bypass, so that they can fall-back to direct calls a source of power capable of coping with prolonged power failures labels for telephone wires / cables and armoured ducting for critical cables. Maintenance contracts should be in force to ensure timely repair.
85
CN53 Special Controls

To prevent and detect the misuse of in-house telephone facilities by unauthorised personnel. Access to corporate telephone exchanges should be controlled by passwords. Passwords set by the equipment manufacturer should be changed on installation. Passwords should be applied to the access ports used for remote diagnosis. Changes to the configuration of settings for in-house telephone exchanges (including extension numbers) should be performed by authorised personnel. The performance of in-house telephone exchanges should be monitored to ensure capacity and staffing levels are sufficient to meet target levels of service. Invoices for telecommunications services should be reviewed to identify errors, misuse or fraud.
86
Aspect SD Systems Development

Building security into systems during their development is more cost-effective and secure than grafting it on afterwards. It requires a coherent approach to systems development as a whole, and sound disciplines to be observed throughout the development cycle. Ensuring that information security is addressed at each stage of the cycle is of key importance.
Pages Area SD1 APPROACH SD11 Roles and Responsibilities SD12 Development Methodologies SD13 Quality Assurance SD14 Development Environment SD15 Outsourcing SD2 BUSINESS REQUIREMENTS SD21 Security Classification SD22 Risk Analysis SD23 Specification of Requirements SD24 Security Controls SD3 DESIGN AND BUILD SD31 Design SD32 Acquisition SD33 System Build SD34 Electronic Commerce Development SD4 TESTING SD41 Testing Standards / Procedures SD42 Testing Process SD43 Acceptance Testing SD5 IMPLEMENTATION SD51 Acceptance Criteria SD52 Installation Process SD53 User Procedures and Training SD54 Post-implementation Review SD6 CHANGE MANAGEMENT SD61 Change Management Standards / Procedures SD62 Change Management Process SD63 Emergency Fixes 88 89 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 104 104 105 106 106
Area
Area
Area
Area
Area
87
Area
SD1 APPROACH
Producing robust systems, on which the enterprise can depend, requires a sound approach to systems development. Accordingly, this area covers the roles and responsibilities of systems development staff, the methodologies used in developing systems, arrangements made for assuring quality, the security of the development environment and the arrangements needed to ensure that outsource contractors satisfy security requirements.
SD11 Roles and Responsibilities

To provide a sound management structure over the personnel involved in systems development activity. Every systems development project should have a designated individual responsible for development activity (for example a project manager) and a business owner. Each system development unit should have a designated individual with overall responsibility for system development. Responsibility for key tasks (such as compliance with development standards, quality assurance, definition of requirements, risk analysis, design / build, testing, implementation and change management) should be assigned to designated individuals. Individuals involved in development projects should be: assigned clear responsibilities equipped with sufficient technical know-how to develop systems correctly and securely sufficient in number to handle planned workloads competent to deal with error, exception and emergency conditions aware of information security principles, good practice and potential information security solutions. Reliance on key individuals should be minimised, such as by appointing deputies, using standard techniques / technologies, maintaining complete and accurate documentation and ensuring segregation of duties. An individual should be appointed to co-ordinate information security arrangements associated with the system development unit or project.
88
SD12 Development Methodologies

To ensure development activity is carried out in conformance with sound disciplines. Development activity should be carried out in accordance with formal system development methodologies. Development methodologies should: be suitable for the types of project carried out cover definition of requirements, design and build activity, testing, implementation activity and change management require information security requirements to be formally documented and defined in terms of the need to maintain confidentiality, integrity and availability of information be kept up-to-date. Development methodologies should be applied by all individuals involved in systems development. Compliance with methodologies should be monitored.
SD13 Quality Assurance

To provide assurance that systems developed will meet business requirements (including information security requirements) and will be completed on time and to budget. Quality assurance activities should be applied to all systems under development. Quality assurance activities should include an assessment of development risks. Such risks should be assessed at an early stage of the development process, documented, and reviewed at key stages during the development lifecycle. Assessments of risk should cover project management, business requirements, benefits, resilience, technological compatibility, technical performance, costing and timescales. Action should be taken to minimise development risks by considering alternative approaches, revising staffing arrangements, plans or timescales and cancelling developments with unacceptable risks. Development activity should be subject to supervisory review, for example of new staff or critical activities, and spot checks performed to ensure compliance with system development methodologies. Quality assurance activities should: follow a structured approach cover all stages of development activity comply with a recognised standard for quality management, such as ISO 9000 produce specific recommendations for improvement. Results of quality assurance activities should be reviewed by the person in charge of development activity, (for example the project manager), the business owner and a representative of the internal audit department.
89
SD14 Development Environment

To provide a secure environment for development activity. Systems development activities, such as program coding and package customisation, should be isolated from live systems. A system development environment should be established in which systems can be developed securely. The development environment should be protected from viruses by employing anti-virus software and from malicious mobile code, for example by using filtering / blocking techniques. Access control software should be employed to protect development software / information and prevent development staff from making unauthorised changes to the live environment. Program source code should be protected by: avoiding storage on live systems restricting access to designated development staff segregating source code under development from programs that are operational recording all access in an audit log archiving old versions periodically. Documentation of system development activity should be maintained (including development logs, approvals and project plans). System documentation should be kept upto-date, held in accessible form and protected against loss or damage.
90
SD15 Outsourcing
To ensure that security requirements are satisfied when systems development is entrusted to an outsource contractor. Prior to outsourcing responsibility for some or all systems development activity, an organisation should: identify particularly sensitive or critical systems, the development of which might be better retained in-house subject the selection of outsource contractors and the transfer of responsibilities to a formal process identify risks and assess security practices employed by outsource contractors agree security controls, approve transfer and establish formal agreements. Formal agreements should oblige contractors to: comply with good business practice, report incidents and provide regular reports on systems development activity maintain the confidentiality / integrity of information gained in the course of work, limiting access to authorised users maintain continuity of services in the event of a disaster apply agreed information security controls, ensuring legal and regulatory requirements, including data privacy, are met assure the quality and accuracy of development activity undertaken permit their activities to be audited provide compensation if service targets are not met. Formal agreements should specify details of licensing arrangements, ownership of code and intellectual property rights. Arrangements should be made to deal with a single point of contact within the outsource contractor. Sufficient resources should be provided to manage the relationship with the outsource contractor on an informed basis. Responsibility for managing the relationship with the outsource contractor should be assigned to a designated individual, equipped with sufficient technical skills and knowledge.
91
Area
SD2
BUSINESS REQUIREMENTS
A thorough understanding of business requirements (including information security requirements) is essential if systems are to fulfil their intended purpose. Accordingly, this area covers the arrangements made for identifying the level of criticality of systems under development, conducting risk analyses, specifying business requirements and assessing the security controls needed to fulfil them. Section Objective Standard of good Practice
SD21 Security Classification

To classify the system under development according to its criticality in order to communicate how it should be treated. The system under development should be classified using a security classification scheme that applies across the enterprise. The classification scheme should take account of important issues that may affect a system once it has gone live, such as the: business impact of a loss of confidentiality, integrity or availability sensitivity of information to be stored in or processed by the system under development and the period of time for which it remains sensitive vulnerability of the system to particular threats. Security classifications should be: used to establish the criticality of the system under development applied to all information to be processed in electronic or paper form, all software being developed, all hardware being acquired, and to all services to be provided by external parties approved by the person in charge of the system under development reviewed by the local security co-ordinator and the individuals in charge of the business processes supported by the system under development revised periodically in the light of changing circumstances recorded in formal agreements with users, such as service level agreements. Details of security classifications for a system under development should be recorded in an inventory and should include: the identity of the individual responsible for them unique identifiers such as descriptive titles their security classification an access policy defining who is authorised to access the system the identity of the legal owner. Systems under development should be protected in line with their security classification.
92
SD22 Risk Analysis

To identify key risks associated with systems under development and determine the controls required in order to keep those risks within acceptable limits. A formal risk analysis should be carried out for important or critical systems under development. The risk analysis should: be carried out at an early stage of the system development process, in compliance with formal standards / procedures for risk analysis and using formal risk analysis methodologies, such as the Forums SARA methodology be reviewed at key stages of the system development process involve representatives of key areas, such as the owners of the system under development, the project manager, an IT specialist, key user representatives and, for critical systems, an expert in risk analysis determine business risk (taking into account the criticality of the installation, the business impact of a loss of confidentiality, integrity or availability, key threats and vulnerabilities) take into account the full range of controls needed to keep risks within acceptable limits. The results of the risk analysis should include a clear indication of key risks, an assessment of their potential business impact and recommendations for the actions required to reduce risk to an acceptable level. The results (including any residual risk) should be reviewed and agreed by the person in charge of the system under development, and communicated to the owners of business processes supported by the system under development. Agreed actions should be implemented and a process established to ensure that this is done effectively.
93
Section Objective
SD23 Specification of Requirements

To document and agree business requirements before detailed design / specification commences. To ensure that information security requirements are treated as an integral part of business requirements - and are fully considered. Business requirements should be defined using a formal process. Business requirements for the system under development should be clearly defined in terms of scope, resources (including timing and costs) and roles / responsibilities. They should be documented and supported by an agreed process for handling changes to requirements. The specification should include requirements for: system capacity, availability, continuity, flexibility, connectivity and compatibility information processing, storage and transmission (including requirements for protecting integrity and confidentiality) arrangements needed to support the system in the live environment compliance with contractual, legal and regulatory obligations access control arrangements, such as access by particular types of user or from particular locations segregation of duties. Business requirements should be signed-off by the business owner, a specialist in information security and the person in charge of development activity. Business requirements for critical systems should also be approved by the information security steering committee (or equivalent) and signed-off by a senior business manager (boardlevel or equivalent).
94
SD24 Security Controls

To ensure that an appropriate set of security controls is identified when formulating business requirements. The full range of controls should be assessed when formulating business requirements. The assessment should include a review of the controls that may be needed to ensure that: the validity of information processed can be readily established, using range, consistency and hash total checks the completeness and accuracy of information processed can be confirmed, by comparison with control balances or original documentation and the rigorous checking of changes to key files and parameters accountability for actions can be determined the opportunity for error or abuse is minimised, such as by automating processes and the maintenance of a complete and reliable audit trail, including error and exception reports. The assessment should include a review of the general controls that may be needed to ensure that: responsibilities are assigned and duties segregated systems resilience is maintained, by minimising single-points-of-failure, provision of adequate capacity and back-up / contingency arrangements the integrity / confidentiality of critical information is protected, by employing access control functionality, non-repudiation techniques (for example using digital signatures) and encryption of files stored or in transit compliance with contractual, regulatory or legal obligations. Proposed controls should be reviewed to ensure that they are proportional to business risk.
95
Area
SD3
DESIGN AND BUILD
Building systems that function as intended requires careful consideration of information security and the maintenance of sound disciplines throughout the design and build stage of development. Accordingly, this area covers the arrangements made to address information security during design, acquisition and system build, including additional controls required for electronic commerce developments. Section Objective Standard of good Practice
SD31 Design
To produce an operational system based on sound design principles which has security functionality built in and / or enables controls to be incorporated easily. Information security requirements for the system under development should be considered when evaluating alternative designs. The design phase should include: specification of a system architecture that can support technical system requirements identification of where security controls are to be applied documentation of control limitations and a review of designs to ensure controls are in place consideration of how individual controls work together to produce an integrated system of controls. The evaluation of alternative designs for the system under development should take into account the: integration with existing information security architecture use of wider security solutions, for example a Public Key Infrastructure or enterprisewide security administration cost of implementing controls skills needed to develop required solutions capability of the organisation to develop and support the chosen technology. Before coding or acquisition work begins, system designs should be documented, verified to ensure that they meet business requirements and approved by the information security steering committee or equivalent. System designs should be signed-off by the project manager and a specialist in information security. Designs for critical systems should also be signed-off by the person in charge of development activity.
96
Section Objective
SD32 Acquisition
To ensure that the use of software, hardware and services acquired from third parties provide the required functionality and do not compromise the security of systems under development. The acquisition of system components should be in accordance with formal standards / procedures. All types of system component should be covered, including application packages, systems software, specialised security products (such as anti-virus software, encryption mechanisms and firewalls), computer / communications equipment and external services. Controls over acquisition should include: selecting products and services from approved lists (with a high priority placed on reliability), assessing them against security requirements and supporting them by contractual terms agreed with suppliers addressing potential security weaknesses in products and services by considering external security ratings, identifying security deficiencies and implementing remedial measures meeting software licensing requirements by obtaining adequate licenses for planned use, maintaining software documentation as proof of ownership and recording details, for example in an inventory. The acquisition of products should be reviewed by staff who are equipped to evaluate them, and approved by the person in charge of development activity.
97
SD33 System Build

To ensure that systems are built correctly and that no security weaknesses are introduced during the build process. System build activities (such as coding programs, creating web pages, customising packages or defining data structures) should be carried out in accordance with formal standards / procedures. The build of the system under development should be documented, and inspected to identify unauthorised changes. When building systems, steps should be taken to ensure that: system build activities are performed by individuals equipped with adequate skills, know-how and tools staff comply with common industry standards system performance is optimised, for example by building-in redundancy the use of insecure design techniques is prohibited automated tools are used to ensure adherence to programming standards system build activities are inspected to identify unauthorised modifications or changes that may compromise security controls staff are prohibited from making changes to the base code of software packages. Where modifications have to be made to the base code of software packages, a formal process should be applied, which: takes account of special risks, such as suppliers refusing to support or maintain modified software and incompatibility with future updates specifies that changes can only be made following approval by a systems development manager, with permission from the supplier and only to a copy of the original code. System build activities should be reviewed by a responsible team leader to ensure that individual components of the system function as intended (for example, by program testing) and to confirm that security weaknesses have not been introduced (for example as a result of package customisation). Restricted source code should be maintained in escrow (ie a trusted third party holds upto-date source code until fulfilment of the contract), and checked periodically.
98
SD34 Electronic Commerce Development

To ensure that the risks associated with the development of electronic commerce applications are minimised. Additional controls should be employed when developing applications that will support electronic commerce. The business practices and privacy policies applicable to the web site(s) that will support the application under development should be independently accredited (for example, by using WebTrust or TRUSTe). Interfaces between web servers and back-office systems should be restricted to those services that are required by the application, based on documented application programming interfaces (APIs), and supported by mutual authentication. Web application sessions should be protected against being hijacked or cloned by ensuring sessionIDs cannot be easily predicted, for example by including a random element. The disclosure of system configuration information (that could be useful to hackers) should be prevented by: suppressing the server field in http headers that identify the web servers brand and version ensuring that directories of files on web servers are not indexable ensuring that the source code of server-side executables and scripts, such as Common Gateway Interface (CGI) scripts cannot be viewed by a browser ensuring that the source of HTML, JavaScript and other client-side scripting languages do not contain unnecessary information, such as details of web CGI functions. Server-side executables and scripts, such as CGI scripts, should be checked for potential vulnerabilities using automated tools, and configured to record actions performed.
99
Area
SD4
TESTING
Testing is a fundamental element of good practice in systems development. Well-planned, and correctly performed, it provides assurance that systems, including security controls, function as intended - before they are used for business purposes - and reduces the likelihood of system malfunctions occurring. Accordingly, this area covers the arrangements needed to carry out testing thoroughly, without disrupting other activities. Section Objective Standard of good Practice
SD41 Testing Standards / Procedures

To ensure testing is carried out in conformance with sound disciplines. New or changed systems should be tested thoroughly in accordance with formal standards / procedures. Formal testing standards / procedures should require testing to cover: the full functionality of business requirements use under normal and exceptional conditions the impact of bad data interfaces with other systems, such as program calls or hyperlinks the effectiveness of controls system performance when handling planned volumes of work (ie load testing with realistic numbers of users / volumes of transactions) identification of maximum system capacity fall-back arrangement to previous versions. Formal testing standards / procedures should require: new systems and significant changes to be tested prior to use for business purposes, and in accordance with a documented test plan that the use of personal information for testing purposes complies with national and international legislation, for example data protection laws.
100
SD42 Testing Process

To ensure systems are tested thoroughly. All elements of a system (ie application software packages, system software, hardware and services) should be tested before promotion to the live environment. New and significantly changed systems should be tested thoroughly in accordance with pre-defined, documented test plans. Test plans should be cross-referenced to the system design / specification to ensure complete coverage. Representatives of user groups should be involved in planning tests, and producing test data. Tests should cover: the full functionality of business requirements use under normal and exception conditions the impact of bad data interfaces with other systems, such as program calls or hyperlinks the effectiveness of controls system performance when handling planned volumes of working (ie load testing with realistic numbers of users / volumes of transactions) identification of maximum system capacity fall-back arrangement to previous versions. Automated tools should be used to improve the testing process, for example to check the validity of system interfaces or simulate loading from multiple clients. Final test results should be documented, reviewed (for example against expected results) approved by users and signed-off by the business owner concerned.
101
SD43 Acceptance Testing

To ensure that only rigorously tested systems, which satisfy user requirements, are promoted to the live environment. Acceptance tests should be carried out in an environment that is isolated from the live environment and separated from other development activities (such as program coding or package customisation). Acceptance tests should: involve business users simulate the live environment involve running the full suite of system components, such as all application functionality, database management utilities and the underlying operating system feature testing to ensure that there will be no adverse effects on existing systems involve independent security assessments of critical code to detect vulnerabilities including Trojan Horses and insecure use of programming features include attempts to breach the security of the system, for example by performing penetration tests. Information copied from the live environment for the purposes of conducting acceptance tests should be protected by: requiring separate authorisation each time information is copied from the live into the testing environment applying access controls in the testing environment erasing copies of business information once testing is complete logging the use of business information for testing purposes.
102
Area
SD5
IMPLEMENTATION
Sound disciplines are required when new systems are transferred from the development into the live environment. Accordingly, this area covers the promotion of new systems from the development environment, their installation in the live environment, user procedures and training and post-implementation reviews. Section Objective Standard of good Practice
SD51 Acceptance Criteria

To ensure rigorous acceptance criteria are met before new systems and significant changes are promoted into the live environment. Formal acceptance criteria should be met before new systems and significant changes are promoted into the live environment. Prior to accepting new systems and significant changes in the live environment, checks should be made to ensure that: security assessments have been carried out and limitations of security controls documented performance and capacity requirements can be fulfilled all development problems have been successfully resolved and there will be no adverse affect on existing live systems the system can be supported on a continuing basis, such as via a help desk arrangements for fall-back have been established in the event of the changes made failing to function as intended sign-off has been obtained from the business owner error recovery and restart procedures are established and computer contingency plans are developed / updated operating procedures have been tested users have been educated in use of the system and computer staff are trained in how to run the system correctly. Steps should be taken to ensure that only tested and approved versions of software are accepted into the live environment and new / upgraded software is successfully distributed without unauthorised change.
103
SD52 Installation Process

To ensure that new or significantly changed systems are installed in the live environment without disruption. New or significantly changed systems should be installed in the live environment in accordance with a formal installation process. The installation process should include: validating the load or conversion of data files restricting the installation of new or significantly changed software to executable code implementing new / revised procedures and documentation and discontinuing old versions arranging for fall-back in the event of failure informing the individuals involved of their roles and responsibilities handing over responsibility to staff running the live environment recording installation activity. The installation of systems into the live environment should be scheduled in advance to avoid disrupting information processing activities and to enable installation to occur in a timely manner.
SD53 User Procedures and Training

To ensure users are equipped to use systems correctly. Users responsibilities should be clearly defined. Users should be fully equipped to carry out their roles and supported by documented procedures, help facilities and training. Users of new or significantly changed systems should be: involved in - and contribute to - the development process equipped with the know-how and skills to use systems correctly formally trained. User training should be carried out prior to systems going live and include information security tasks and responsibilities. User training programmes should be signed-off by the project manager, the business owner and a specialist in information security.
SD54 Post-implementation Review

To check that systems - and information security controls - function as intended. Post-implementation reviews should be conducted for new or significantly changed systems. Post-implementation reviews should cover: fulfilment of business (including information security) requirements efficiency, effectiveness and cost of controls scope for improvements of controls review of security incidents. Results of reviews should be signed-off by the project manager, the business owner and a specialist in information security.
104
Area
SD6
CHANGE MANAGEMENT
Once systems have been promoted to the live environment, it is important for any changes to be well managed. Changes to live systems (ie enhancements, software fixes, data adjustments, hardware / software upgrades) often have unforeseen effects, and may accidentally or deliberately impact service levels or compromise security controls. Sound management can reduce the risk of such incidents occurring. Accordingly, this area covers the disciplines applied throughout the change process. Section Objective Standard of good Practice
SD61 Change Management Standards / Procedures

To ensure that changes to live systems are made in conformance with sound disciplines. Changes should be made in accordance with formal standards / procedures. Formal change management standards / procedures should cover changes of all types, including software or equipment upgrades, software fixes, changes to business information, updating of parameter settings and correction of erroneous information. Formal change management standards / procedures should cover changes to: tailor-made software, integrated application packages and desk-top products systems software including operating systems and utilities file / database formats and structures computers and related equipment communications services, such as new methods of connection.
105
SD62 Change Management Process

To ensure that changes to the live system do not affect its availability or compromise the confidentiality / integrity of associated business information. Changes affecting the live environment should be made in accordance with a formal process. Prior to promotion to the live environment, arrangements should be made to ensure that: change requests are documented, only accepted from authorised individuals, and approved by the business owner before work commences the impact of changes are assessed, and reviews performed to ensure that changes do not compromise security controls changes are rigorously tested and synchronised across all key components of the live environment changes are checked and authorised by all relevant individuals software is checked to ensure it does not contain malicious code, such as a Trojan Horse or a virus the system within the live environment can recover from failed changes. Changes should be performed by individuals equipped with adequate skills, know-how and tools under the supervision of an IT specialist. Changes should be made to a copy of the software or data prior to use in the live environment. Arrangements should be made to ensure that once changes have been applied: version control is maintained, documentation is updated and details of changes are communicated to all relevant users a record is maintained showing what was changed, when and by whom checks are performed to confirm that only intended code has been changed before and after contents of key records (for example within customer master files) have been scrutinised.
SD63 Emergency Fixes

To enable unforeseen problems to be addressed in a timely yet disciplined manner. Formal standards / procedures should be established that cover emergency fixes to computer equipment, business application software, systems software, parameter settings, business information and system details (such as back-up files). Emergency fixes should be made in accordance with formal standards / procedures, logged, and approved by the most senior manager present. Once fixes have been made, authorisation for emergency access should be revoked immediately. Emergency fixes should then be formalised and reviewed by the person in charged of development activity. Steps should be taken to ensure that emergency fixes are not left permanently in place.
106
The Information Security Forum is an independent, not-for-profit association of leading organisations dedicated to clarifying and resolving key issues in information security and developing security solutions that meet the business needs of its Members. Members of the Forum profit from sharing information security solutions drawn from the considerable experience within their organisations and developed through an extensive work programme. Members recognise that information security is a key business issue and the Forum provides a mechanism which can ensure that the practices they adopt are on the leading edge of information security developments, while avoiding the significant expenditure that individual development of solutions would incur.
For further information contact:
The Information Security Forum 1 London Bridge London SE1 9QL United Kingdom Telephone: +44 (0)20 7213 1745 Facsimile: +44 (0)20 7213 4813 E-mail: info@securityforum.org Web: www.securityforum.org
Reference: 2000/11/05
Copyright 2000
The information Security Forum. All rights reserved.

FSOGP 2000 MSWord

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

FSOGP 2000 MSWord

Hochgeladen von

Copyright:

Verfügbare Formate

The Forums Standard of Good Practice

The Standard for Information Security

The Forum's Standard of Good Practice Microsoft Word Format

Aspect SM Security Management

SM11 Management Commitment

SM12 Security Policy

Standard of good Practice

Section Objective Standard of good Practice

SM13 Personnel Policies

SM21 High-level Control

Section Objective Standard of good Practice

SM22 Driving Force

Section Objective Standard of good Practice

SM23 Local Co-ordination

SM24 Security Awareness

Standard of good Practice

SM25 Security Education

Standard of good Practice

SM31 Security Classification

Standard of good Practice

Section Objective Standard of good Practice

SM33 Risk Analysis

Standard of good Practice

SM4 SECURE ENVIRONMENT

Section Objective Standard of good Practice

SM41 Standards / Procedures

SM42 Security Architecture

Standard of good Practice

Section Objective Standard of good Practice

SM43 Data Privacy

Section Objective Standard of good Practice

SM44 Physical Protection

SM45 Business Continuity

SM51 Protection from Malicious Code

Section Objective Standard of good Practice

SM52 Use of Cryptography

Section Objective Standard of good Practice

SM53 Electronic Mail

SM54 Remote Working

Standard of good Practice

SM55 Third Party Access

Standard of good Practice

Section Objective Standard of good Practice

SM56 Electronic Commerce

SM61 Security Audit / Review

Standard of good Practice

Section Objective Standard of good Practice

SM62 Security Monitoring

Aspect CB Critical Business Applications

Section Objective Standard of good Practice

Section Objective Standard of good Practice

CB21 Security Classification

Section Objective Standard of good Practice

CB22 Risk Analysis

CB31 Roles and Responsibilities

Section Objective Standard of good Practice

CB32Running the Application

Section Objective Standard of good Practice

Section Objective Standard of good Practice

Section Objective Standard of good Practice

Section Objective Standard of good Practice

CB36Security Audit / Review