${ORGANIZATION_LOGO} ${ORGANIZATION_NAME}
${ORGANIZATION_LOGO}
This is a sample document and our logo will not be appearing in the original documents instead your company logo will be appearing
INFORMATION SECURITY POLICY
Version Number Date of version Author Author Job title Approved by Approver Job Title Classification Intended recipient Effective from
[Version Number] [Date of version] [Author] [Author Job title] [Approved by] [Approver Job title] [Classification] [Intended recipient] [Document is valid to the organization from?]
Comment [PS1]: Enter documen version here Comment [PS2]: Comment [PS3]: Author of this document Comment [PS4]: Job title of the author
Comment [PS5]: Approver of this document. Usually it will be the information security officer or a member of senior management.
Comment [PS6]: Title of the pers approving this document
Comment [PS7]: Classification of this document. Refer to informatio security policy for guidance on how classify documents (eg: Public, internal, confidential).
Comment [PS8]: People who nee to read and adhere to this documen
Comment [PS9]: The effective da of this document for the organizati Based on this date the next review cycle should be calculated for insta review document every year.
${ORGANIZATION_LOGO}
Table of Contents 1.
2.
Introduction ............................................................................................................................................... 3 1.1
Objective ........................................................................................................................................... 3
1.2
Scope ................................................................................................................................................. 3
1.3
Aim of the Policy ............................................................................................................................... 3
Responsibilities for Information Security ............................................................................................... 3 2.1
Information Owner ............................................................................................................................ 3
2.2
Responsibility of other employees ...................................................................................................... 3
3.
Legislation................................................................................................................................................ 4
4.
Policy Framework ................................................................................................................................... 4 4.1
Management of Security .................................................................................................................... 4
4.4
Security Control of Assets .................................................................................................................. 4
4.5
Physical Access Controls ................................................................................................................... 4
4.6
User Access Controls ......................................................................................................................... 4
4.7
IT system Access Control................................................................................................................... 5
4.8
Equipment Security............................................................................................................................ 5
4.9
IT System Procedures ........................................................................................................................ 5
4.10
Information Risk Assessment ............................................................................................................. 5
4.11
Incident management ......................................................................................................................... 5
4.12
Classification of Sensitive Information. .............................................................................................. 5
4.13
Protection from Malicious Software ................................................................................................... 6
4.14
User media......................................................................................................................................... 6
4.15
Monitoring System Access and Use ................................................................................................... 6
4.16
Accreditation of Information Systems ................................................................................................ 6
4.17
System Change Control...................................................................................................................... 6
4.18
Intellectual Property Rights ................................................................................................................ 6
4.19
Business Continuity and Disaster Recovery Plans .............................................................................. 6
4.20
Reporting ........................................................................................................................................... 6
4.21
Further Information ............................................................................................................................ 7
${ORGANIZATION_LOGO}
Version control Version Number [Version number]
Author [author]
Date [Date of version]
Change description [Change description]
Comment [PS10]: Initial version number of the document. Comment [PS11]: Name of the person who wrote the initial draft.
Comment [PS12]: Date of creatio of the initial draft.
Comment [PS13]: Provide a brief description of the version. For instance ‘initial draft’. For next versions please provide details of th change made to the initial draft.
${ORGANIZATION_LOGO}
1. Introduction This top-level information security policy is a key component of ${ORGANIZATION_NAME} overall information security management framework and should be considered alongside more detailed information security documentation including, system level security policies, security guidance and protocols or procedures.
1.1
Objective The objectives of ${ORGANIZATION_NAME} Information Security Policy are to preserve:
1.2
Confidentiality - Access to Data shall be confined to those with appropriate authority. Integrity – Information shall be complete and accurate. All systems, assets and networks shall operate correctly, according to specification. Availability - Information shall be available and delivered to the right person, at the time when it is needed.
Scope This policy applies to all assets which processes information which includes systems, networks, applications, locations and users of ${ORGANIZATION_NAME} or suppliers under contract to it.
1.3
Aim of the Policy The aim of this policy is to establish and maintain the confidentiality, integrity and availability of information owned or held by ${ORGANIZATION_NAME} by:
Ensuring that all members of staff are aware of and fully comply with the relevant legislation as described in this and other policies. Describing the principals of security and explaining how they shall be implemented in the organization . Introducing a consistent approach to security, ensuring that all members of staff fully understand their own responsibilities. Creating and maintaining within the organization a level of awareness of the need for Information Security as an integral part of the day to day business. Protecting information assets under the control of the organization .
2. Responsibilities for Information Security 2.1
Information Owner Information security is responsibility of all employees in the organization but the accountability to ensure the information rests with the owner of the information. On a day-to-day basis the information owner shall be responsible for managing and implementing the policy and related procedures. The ultimate responsibility on an organization level to protect the security of the information rests with the Chief Executive Officer.
2.2
Responsibility of other employees Line Managers are responsible for ensuring that their permanent and temporary staff and contractors are aware of:o The information security policies applicable in their work areas o Their personal responsibilities for information security o How to access advice on information security matters All staff shall comply with information security procedures including the maintenance of data confidentiality, data integrity and data availability . Failure to do so may result in disciplinary action.
${ORGANIZATION_LOGO}
The Information Security Policy shall be maintained, reviewed and updated by the [Author]. This review shall take place at least annually. Line managers shall be individually responsible for the security of their physical environments where information is processed or stored.
Comment [PS14]: Provide the na of the person who is responsible to maintain the policy. Usually it’s t author of the policy who is responsible to manage the docume
Each member of staff shall be responsible for the operational security of the information systems they use. Each system user shall comply with the security requirements that are currently in force, and shall also ensure that the confidentiality, integrity and availability of the information they use is maintained to the highest standard. Contracts with external contractors that allow access to the ${ORGANIZATION_NAME} information shall be in operation before access is allowed. These contracts shall ensure that the staff or sub-contractors of the external organization shall comply with all appropriate security policies.
3. Legislation The ${ORGANIZATION_NAME} is obliged to abide by all relevant legislations including both local and international legislations. The requirement to comply with this legislation shall be communicated to employees of the ${ORGANIZATION_NAME} , who may be held personally accountable for any breaches of these legislative requirements.
4. Policy Framework 4.1
Management of Security The${ORGANIZATION_NAME} [Department or role responsible for information security] shall be responsible for implementing, monitoring, documenting and communicating security requirements for the ${ORGANIZATION_NAME}.
4.2
Information Security Awareness Training
4.3
Information security awareness training shall be included in the staff induction process. An ongoing awareness program shall be established and maintained in order to ensure that staff awareness is refreshed and updated as necessary.
Contracts of Employment Staff security requirements shall be addressed at the recruitment stage and all contracts of employment shall contain a confidentiality clause. Information security expectations of staff shall be included within appropriate job definitions..
4.4
Security Control of Assets Each information asset both IT and no-IT asset shall have a named custodian who shall be responsible for the information security of that asset.
4.5
Physical Access Controls Only authorised personnel who have a justified and approved business need shall be given access to restricted areas containing information systems or stored data.
4.6
User Access Controls Access to information shall be restricted to authorised users who have a legitimate business need to access the information.
Comment [PS15]: Provide here t name of the department or role in organization who is responsible for information security.
${ORGANIZATION_LOGO}
4.7
IT system Access Control Access to IT systems shall be restricted to authorised users who have business need to use the system . Access to data, system utilities and program source libraries shall be controlled and restricted to those authorised users who have a legitimate business need e.g. systems or database administrators. Authorisation to use an application shall depend on the availability of a licence from the supplier.
4.8
Equipment Security In order to minimise loss of, or damage to, all assets, equipment shall be physically protected from threats and environmental hazards.
4.9
IT System Procedures Management of IT systems and networks shall be controlled through standard documented procedures published and approved by the [Department or role responsible for information security].
4.10
Information Risk Assessment Information Risk assessment should be conducted based on the defined and approved Risk Assessment method. Once identified, information security risks shall be managed on a formal basis. They shall be recorded within a baseline risk register and action plans shall be put in place to effectively manage those risks. The risk register and all associated actions shall be reviewed at regular intervals at least a year. Any implemented information security arrangements shall also be a regularly reviewed feature of an ${ORGANIZATION_NAME}’s risk management program. These reviews shall help identify areas of continuing best practice and possible weakness, as well as potential risks that may have arisen since the last review was completed.
4.11
Incident management All information security incidents should be handled based on the defined and approved incident management process. All identified weaknesses should be reported to the [department, role or department who manages information security incidents]. All information security incidents shall be investigated to establish their root cause and impacts with a view to avoiding similar events in the future.
4.12
Comment [PS16]: Provide here t name of the department or role in organization who is responsible for information security.
Classification of Sensitive Information. The classification Confidential – shall be used for customer sensitive data (customer financial information, Customer personal information, etc) , employee sensitive data (eg: Salary, medical information, etc). Documents so marked shall be held securely at all times in a locked room to which only authorised persons have access. They shall not be left unattended at any time in any place where unauthorised persons might gain access to them. They should be transported securely in sealed packaging or locked containers. Documents marked Confidential not in a safe store or in transport should be kept out of sight of visitors or others not authorised to view them. The classification Restricted - shall be used to mark all other sensitive information such as financial and contractual records. It shall cover information that the disclosure of which is likely to: adversely affect the reputation of ${ORGANIZATION_NAME} or its officers or cause substantial distress to individuals; make it more difficult to maintain the operational effectiveness of ${ORGANIZATION_NAME}; cause financial loss or loss of earning potential, or facilitate improper gain or disadvantage for individuals or organization s; prejudice the investigation, or facilitate the commission of crime or other illegal activity;
Comment [PS17]: The departmen role or department who manages information security incidents in yo organisation
${ORGANIZATION_LOGO}
breach proper undertakings to maintain the confidence of information provided by third parties or impede the effective development or operation of policies; breach statutory restrictions on disclosure of information; disadvantage the organization in commercial or policy negotiations with others or undermine the proper management of the organization and its operations. Restricted documents should also be stored in lockable cabinets
4.13
Protection from Malicious Software The information system owners shall use software countermeasures and management procedures to protect itself against the threat of malicious software. All staff shall be expected to co-operate fully with this policy. Users shall not install software on the organization ’s property without permission from the [Department or role responsible for information security]. Users breaching this requirement may be subject to disciplinary action.
4.14
User media Removable media of all types that contain software or data from external sources, or that have been used on external equipment, require the approval of [Department or role responsible for information security] before they may be used on ${ORGANIZATION_NAME} systems. Such media must also be fully virus checked before being used on the organization ’s equipment. Users breaching this requirement may be subject to disciplinary action.
4.15
Comment [PS18]: Provide here t name of the department or role in organization who is responsible for information security.
Comment [PS19]: Provide here t name of the department or role in organization who is responsible for information security.
Monitoring System Access and Use An audit trail of system access and data use by staff shall be maintained and reviewed on a regular basis. A process should be in place to regularly audit the audit trail to ensure no unauthorized or unlawful actions are done using ${ORGANIZATION_NAME} system. The monitoring should be implemented based on the local legislation to avoid any breach of regulation.
4.16
Accreditation of Information Systems All product owners shall ensure that all new information systems, applications and networks include a security plan and are approved by the [Department or role responsible for information security] before they commence operation.
4.17
System Change Control Changes to information systems, applications or networks shall be reviewed and approved by the [Department or role responsible for information security].
4.18
Intellectual Property Rights The product owners shall ensure that all information products are properly licensed and approved by the [Department or role responsible for information security]. Users shall not install software on the organization ’s property without permission from the [Department or role responsible for information security]. Users breaching this requirement may be subject to disciplinary action.
4.19
Business Continuity and Disaster Recovery Plans The information owner shall ensure that a business impact assessment is conducted for all information asset and a business continuity and disaster recovery plan is produced for information assets based on the result of the business impact assessment.
4.20
Comment [PS20]: Provide here t name of the department or role in organization who is responsible for information security.
Comment [PS21]: Provide here t name of the department or role in organization who is responsible for information security.
Comment [PS22]: Provide here t name of the department or role in organization who is responsible for information security.
Comment [PS23]: Provide here t name of the department or role in organization who is responsible for information security.
Reporting The [Department or role responsible for information security] shall keep the senior management informed of the information security status of ${ORGANIZATION_NAME} by means of regular reports and presentations.
Comment [PS24]: Provide here t name of the department or role in organization who is responsible for information security.
${ORGANIZATION_LOGO}
4.21
Further Information Further information and advice on this policy can be obtained from [Department or role responsible for information security].
Comment [PS25]: Provide here t name of the department or role in organization who is responsible for information security.
${ORGANIZATION_LOGO} ${ORGANIZATION_LOGO}
${ORGANIZATION_LOGO} ${ORGANIZATION_NAME}
${ORGANIZATION_LOGO}
RISK MANAGEMENT METHODOLOGY
Version Number Date of version Author Author Job title Approved by Approver Job Title Classification Intended recipient Effective from
[Version Number] [Date of version] [Author] [Author Job title] [Approved by] [Approver Job title] [Classification] [Intended recipient] [Document is valid to the organization from?]
Comment [PS26]: Enter docume version here Comment [PS27]: Comment [PS28]: Author of this document
Comment [PS29]: Job title of the author
Comment [PS30]: Approver of th document. Usually it will be the information security officer or a member of senior management. Comment [PS31]: Title of the person approving this document
Comment [PS32]: Classification o this document. Refer to informatio security policy for guidance on how classify documents (eg: Public, internal, confidential). Comment [PS33]: People who needs to read and adhere to this document.
Comment [PS34]: The effective date of this document for the organization. Based on this date the next review cycle should be calcula for instance review document ever year.
${ORGANIZATION_LOGO}
Table of Contents 1.
Introduction ........................................................................................................................................... 12 1.1
2.
Scope ............................................................................................................................................... 12
Risk Assessment Methodology .............................................................................................................. 12 2.1
Establishing the context ................................................................................................................... 12
2.2
Risk Identification............................................................................................................................ 13
2.3
Risk Analysis ................................................................................................................................... 14
2.4
Impact Assessment .......................................................................................................................... 14
2.5
Likelihood Assessment .................................................................................................................... 14
2.6
Risk Rating ...................................................................................................................................... 14
2.7
Controls Identification and Assessment ............................................................................................ 15
2.8
Risk Evaluation................................................................................................................................ 16
2.9
Risk Treatment ................................................................................................................................ 16
2.10
Monitoring and Review.................................................................................................................... 17
2.11
Communication and consultation ..................................................................................................... 17
3. Record management requirements for the records created based on this document . Error! Bookmark not defined.
${ORGANIZATION_LOGO}
Version control Version Number [Version number]
Author [author]
Date [Date of version]
Change description [Change description]
Comment [PS35]: Initial version number of the document. Comment [PS36]: Name of the person who wrote the initial draft.
Comment [PS37]: Date of creatio of the initial draft.
Comment [PS38]: Provide a brief description of the version. For instance ‘initial draft’. For next versions please provide details of th change made to the initial draft.
${ORGANIZATION_LOGO}
1. Introduction This document defined and document Risk management methodology followed in ${ORGANIZATION_NAME}. The methodology will enable business units to systematically identify, analyse and evaluate the information security risks associated with an information system or service together with the controls required to manage them.
1.1
Scope This methodology is applicable to all information security risk assessment conduced in the scope of ISMS. This include all business processes and assets in scope of ISMS.
2. Risk Assessment Methodology 2.1
Establishing the context
2.1.1
Establish the business and technical context of the information system being assessed and ensures that the businesses objectives are captured and that the internal and external factors that influence the risks are considered. It also sets the scope for the rest of the process. Business context Identify the business owner of the information system being reviewed. The business owner of the system is the person who owns the information stored or processed transmitted or managed by the system. Meet with the business owner of the information system to establish the business context. During the meeting the business owner is responsible for identifying and defining the:
Information Classification – The information stored, processed and/or transmitted by the information system must be assigned an official classification based on the classification guidance provided in the information security policy. Business Processes Supported – the business processes and objectives supported by the information system. This should include any secondary, dependent or supporting processes. Users of the System – the different types of users of the information system. This should include the level of privileges they require to perform their duties or to use the system. Users may include business users, operations support staff and external users of services such as 3rd party service providers. Security and Compliance Requirements – the confidentiality, integrity, availability (CIA) and privacy requirements of the system together with any relevant laws and/or regulations that need to be met by it. 2.1.2 Technical context Establish the technical context to provide a basic understanding of the security posture of the information system. The following provides guidance on who should be involved in establishing the technical context : Service Owner – the service owner (or their nominated delegate) is responsible for identifying the components and defining the boundaries of an information system that is in scope of the risk assessment. Enterprise or Solution Architect – the Architect is responsible for identifying the components and defining the boundaries of an information system that is within the scope of the risk assessment. Subject Matter Experts – ICT operations staff responsible for the ongoing support and maintenance of the information system that is within the scope of the risk assessment. The technical context discussions should focus on identifying the following attributes of the information system to provide an understanding of the overall security profile of the system:
Logical Architecture – a system and component level view of the logical architecture of the information system. This should include the security domains where system components are
${ORGANIZATION_LOGO}
2.2
located, the system interfaces and information flows (i.e., where and how data is stored, transmitted and processed). System Components – the hardware and software components that the information system is comprised of. This should include all direct and indirect components including servers, switches, firewalls, operating systems, applications and databases
Risk Identification In order to manage risk, the potential threats to the information systems need to be identified. During the risk identification phase, a comprehensive list of events that may prevent, degrade or delay the achievement of the businesses objectives. Comprehensive identification is critical because a risk that is not identified at this stage will not be included in the risk analysis phase. A multidisciplinary workshop discussion should be conducted to identify the potential risks to the information system. The workshop should include the business and service owners (or their nominated delegates) and subject matter experts from both the business and ICT. The workshops should focus on defining risk scenarios. Risk scenarios are methods of determining if any risks exist that could adversely affect the confidentiality, integrity or availability of the information system and therefore affect the business objectives. They generally consist of a threat exploiting a vulnerability resulting in an undesirable outcome. Appendix A – Threat Catalogue presents a sample list of threats that can be used to help discuss the potential risks to an information system. This approach can ensure that all the possible threats to the information system are considered, whilst ensuring that only those that are applicable are actually assessed. When identifying risk, it is important to clearly describe it so that it can be assessed and evaluated. For example, assessing the likelihood and impact of a risk stated as: “Fraud may occur” is difficult if not impossible. However, assessing the same a risk stated as: “An employee commits fraud resulting in financial loss and reputation damage as fraud detection processes are not robust” is more straightforward. Therefore the description of risks identified should use the following structure (or a variation of it, providing that the three elements are included): <Unlawful event > occurs, leading to <impact on objective> , as a result of <definite cause>. For example: A hacker gains unauthorised access to information stored in the system by performing a brute force password guessing attack. They use the information to commit identity fraud that leads to an investigation by the law enforcement, and reputational damage to the organization. The attack is successful because the system does not enforce strong passwords or account lockout policies and does not log failed logon attempts. The loss of a laptop leads to official information being disclosed to an unauthorized party, and reputational damage to the organization as disk encryption has not been enabled on all laptop devices. Once the risk description has been defined and documented consideration should be given to the risk drivers. Capturing the risk drivers is useful when identifying and selecting controls to manage the risk. The business and technical context normally inform the risk drivers, for example, a risk may only exist because the information system is Internet facing. It is important to also note that there may be multiple risk drivers related to a risk. The following provides some example risk drivers: The information system is deployed as an Internet facing service. The information system is an attractive target to criminals/hacktivists. Patches may not be applied in a timely manner. Default accounts/passwords are not changed or removed. User accounts are not disabled or removed in a timely manner when a staff member leaves the organization.
${ORGANIZATION_LOGO}
Although the risk statement captures the consequences (i.e., the impact on objectives) of the risk getting materialized it is useful to document them separately as well. The consequences should be stated in business context not in technical terms. For example: • Reputational damage to the organization; • Confidential information is disclosed to an unauthorized party; • Breach of the Privacy Act; • Service delivery is impacted due to a loss of productivity; • Loss of confidence in the service by key stakeholders. As the business owner (or their nominated delegate) is the owner of the risk, they are responsible for rating the identified risks. However, the subject matter experts should provide information to help them with the assessment.
2.3
Risk Analysis Once the relevant risks have been identified the likelihood and impact of the identified risk eventuating must be assessed and rated. This risk management methodology uses a qualitative scale to rate the likelihood and impact of a risk. Appendix B – Example Risk Scales and Matrix presents a qualitative scale that can be used to assign a likelihood rating. As the business owner (or their nominated delegate) is the owner of the risk, they are responsible for rating the identified risks. However, the subject matter experts should provide information to help them with the assessment.
2.4
Impact Assessment Assess the impact of risk eventuating with no controls in place. This will define the gross risk (inherent risk) rating and enable the effectiveness of any current controls that reduce the impact of a risk event that occurs to be assessed. Although there may be multiple impact statements documented for a risk, only one impact rating can be assigned to the risk. As a result, the highest rated impact statement should be used to determine the impact rating of a risk.
2.5
Likelihood Assessment Assess the likelihood of the risk eventuating with no controls in place. This will result in the gross risk (inherent risk) rating and enable the effectiveness of any current controls that reduce the likelihood of a risk event occurring to be assessed. Where historic information is available about the frequency of an incident’s occurrence it should be used to help determine the likelihood of the risk eventuating. However, it must be noted that the absence of such information does not necessarily mean that the likelihood of the risk eventuating is low. It may merely indicate that there are no controls in place to detect that it has occurred.
2.6
Risk Rating The risk rating is evaluated using a risk matrix. The Appendix B – Example Risk Scales and Matrix also presents a risk matrix that can be used to map the likelihood with the impact rating, the overall risk rating being the point where the two ratings intersect. For example: o A risk with likelihood of Almost Never, and impact rating of Medium would result in an overall risk rating of 3; o A risk with a likelihood rating of Possible, and an impact rating of critical would result in an overall risk rating of 17; and o A risk with a likelihood rating of Almost Certain, and an impact rating of Low would result in an overall risk rating of 11.
${ORGANIZATION_LOGO}
The risk rating without any controls in place have been assessed is called the gross risk or inherent risk. Typically risks that are assessed as being 1 to 3 on the rating scale without any controls in place are considered acceptable to the organization and may not require the implementation of any controls to manage them. However, because risk is rarely static they should be added to the organizationâ&#x20AC;&#x2122;s risk register so that they can be monitored and re-assessed on a regular basis to ensure that the likelihood and/or impact do not change.
2.7
Controls Identification and Assessment Regardless of whether the risk assessment is being performed for an information system that is in production or as part of the development lifecycle process for a new information system there will already be controls in place to reduce the likelihood and/or impact of some of the risks that have been identified. A control can reduce the risk by reducing the likelihood of an event, the impact or both. Assessing the effect that the control has on the overall risk leads to determining the residual risk rating. Figure below can be used to identify the affect each type of control has on the likelihood or impact of a risk. Typically deterrent and preventive controls reduce the likelihood of a risk eventuating whereas detective and corrective controls reduce the impact should it eventuate.
The following provides a brief description control types used in the above figure: Deterrent controls: The goal of a Deterrent Control is to reduce the likelihood of a threat exploiting a vulnerability without actually reducing the exposure. For example, establishing an information security policy, a warning message on the logon screen, a lock or security cameras. Preventive controls: As the name indicate these controls prevent a threat exploiting a vulnerability which reduce the likelihood of an incident occur. For example, a user account management process, restricting server room access to authorised personnel, configuring appropriate rules on a firewall or implementing an access control list on a file share. Detective Controls â&#x20AC;&#x201C; are intended to identify when an incident has occurred. For example, security monitoring of systems, review of server or firewall security logs or Intrusion Detection System (IDS) alerts. Corrective Controls â&#x20AC;&#x201C; are intended to fix information system components after an incident has occurred. For example, data backups, business continuity and disaster recovery plans. Conduct a workshop to identify and assess the controls that are currently in place to reduce the likelihood and/or impact of the risks eventuating. The business owner and subject matter experts
${ORGANIZATION_LOGO}
who can identify and describe the current controls that are in place to manage the identified risks must be involved in assessing their efficacy. During the risk assessment a control may be identified as being ineffective, not sufficient or simply not relevant to the risk it is supposed to be mitigating. If this is the case, an analysis should be performed to determine whether it should be replaced by another more suitable control or whether it should remain in place and be supplemented with additional controls. The residual risk rating is derived by assessing the effect that the current controls have on the inherent risk and using the risk matrix presented in Appendix B – Example Risk Scales and Matrix to map the likelihood and impact ratings, with the residual risk rating being the new point where the two ratings intersect. For example:
2.8
A risk scenario with likelihood rating of Possible but Unlikely, and impact rating of Critical would result in an overall risk rating of 14. A control currently in place is highly effective at reducing the impact of the risk. The impact rating is revised to medium with the control in place, therefore the residual risk rating is 5; A risk scenario with a likelihood rating of Possible, and an impact rating of critical would result in an overall risk rating of 17. A control currently in place is effective at reducing the impact of the risk. The impact rating is revised to High with the control in place, therefore the residual risk rating is 13; and A risk scenario with a likelihood rating of Almost Certain, and an impact rating of Low would result in an overall risk rating of 11. A control currently in place is very effective at reducing the likelihood of the risk. The likelihood rating is revised to Possible with the control in place; therefore the residual risk rating is 4.
Risk Evaluation Once the risk analysis has been completed the residual risks can be evaluated against the Business unit’s risk tolerance levels. Risk evaluation seeks to assist the business owner in making decisions on which risks requirements treatment, and the priority for implementing a risk response. Residual risks that are assessed as being between 1 and 4 on the ratings scale are generally considered to present an acceptable level of risk to the business and do not require any further evaluation. However, because risk is rarely static they should be added to the organization’s risk register so that they can be monitored and assessed on a regular basis to ensure that the likelihood and/or impact do not change. All residual risks that are evaluated as being between 5 and 20 on the rating scale need to be evaluated and prioritized. The higher the risk rating is, the higher its priority. However, there may be two or more risks with the same risk rating. If it is not clear which risks have a higher priority the information protection priorities defined by the business owner when establishing the business context for the system should be used to determine the priority for the implementation of additional controls.
2.9
Risk Treatment
The business owner can choose to avoid, treat, transfer or accept the risk. The following provides an overview of each: Avoid – stop the activity that would give rise to the risk, thus eliminating the risk. Risk avoidance is not commonly selected as it typically results in not being able to exploit the associated opportunity; Treat – implement controls to reduce the likelihood and/or impact of the risk eventuating. Risk treatment is the most commonly selected risk treatment; Transfer – transfer or share all or part of the impact of the risk eventuating with a third party. The most common risk transfer techniques are insurance and outsourcing;
${ORGANIZATION_LOGO}
2.10
Accept – the business owner may choose to accept a risk. Risks are usually accepted when they are assessed as being within the business’s defined risk tolerance level. However, they may also be accepted when it is not practical to avoid, treat or transfer the risk. As highlighted in the Controls Identification and Assessment section there are different types of controls that can be implemented to reduce the identified risks to an acceptable level. It is important to ensure that any recommended control will reduce the residual risk. For example, if a risk has a residual risk rating of 10 (i.e., a likelihood of Almost Never and an impact of critical) recommending a control that reduces the likelihood of the risk eventuating will not reduce the residual risk. However, recommending a control (or a combination of controls) to reduce the impact of the risk eventuating will. Business units are required define the controls to reduce the risk into an acceptable level. Business units can use the ISO/IEC 27002 standard as a reference for selecting controls to reduce the identified risk.
Monitoring and Review All identified and managed risks should be periodically reviewed to ensure that they remains within the risk appetite of the business owner. The factors that affect the likelihood and impact of a risk eventuating may change, as could the factors that affect the suitability or cost of the treatment options. So it’s essential to have ongoing review of identified risks to ensure the selected treatment remains effective. The results of monitoring and review activities should be fed back into the risk management process.
2.11
Communication and consultation Communication and consultation are an important consideration at each step of the risk assessment process. There must be a two-way dialogue between the stakeholders with the focus on consultation rather than a one-way information flow. Effective communication between stakeholders is essential to ensure that risks are understood and decisions about risk response selection are appropriate. Information about a risk may be distributed to a large number of different stakeholders within the agency. To be effective, all information relating to the management of risks should be: Clear and Concise Ensure that the information can be understood by all recipients and does not overwhelm them with extraneous detail; Useful any communication related to risk must be relevant. Technical information that is too detailed or sent non-technical recipients will likely impede, rather than enable, a clear view of risk; Timely timely communications enable decisions and actions to be taken at the appropriate time in the risk management process; Targeted information must be communicated at the right level of aggregation and adapted for the audience to enable informed decisions to be made. However, the aggregation of the information must not hide the root cause of a risk; Controlled information related to risks should be made available on a need-to-know basis. Only parties with a genuine need should have access to risk reports, risk management plans and the risk register.
${ORGANIZATION_LOGO}
3. Appendix 3.1
Appendix A- Threat Catalogue
3.1.1
Threat Sources The below table presents the typical threat agents that can adversely affect the information security of an business units information assets. They are categorised into threat groups to enable business units to consider whether they need to define a risk statement for each individual threat agent, a group of threat agents or a combination of the two. For example, it may be sufficient for a business unit to consider the threats from employees and external attackers rather than each type of individual or external organizations threat agents but they may need to consider each type of technical, accidental and natural event. Threat Group
Individuals
External Organizations
Technical events
Accidental Events
Natural Events 3.1.2
Threat Agent Employees/Contractors Customers/Clients Service Provider Employees/Contractors Employees/Contractors Hackers Hacktivists/Activists Criminals Terrorists Service Providers Hacktivist or Activist Groups Foreign Governments State Sponsored Action Groups Organised Crime Syndicates Terrorist Groups Malicious Code (e.g., viruses, worms etc.) Defective Code Equipment Failure Failure of air-conditioning Loss of power supply Fire Water Damage Major Accident Destruction of equipment or media Weather (e.g., electrical storm) Earthquake Volcanic Eruption Flood
Threat Agent motivation The below table presents some of the potential reasons for an individual or external organization threat agents to try to exploit a vulnerability in an information system or service. It may also be important to also consider the intent of the threat agent, as their actions may be accidental, deliberate or malicious. For example, an employee may accidentally, deliberately or maliciously violate a process or procedure (e.g., they forget to perform a step, they choose not perform a step as they believe that it is unnecessary or they choose not to perform a step knowing that it will have adverse impact on the organization). Threat Domain Individual
Motivation Minimise their effort to complete a process or procedure Financial Gain
${ORGANIZATION_LOGO}
External Organizations
Revenge Gain knowledge or information Exerting power Gaining peer recognition and respect Satisfying curiosity Furthering political or social aims Terrorizing certain target groups or individuals Enhancing personal status with other individuals or a group Gaining a competitive advantage Gaining an economic advantage Gaining a political advantage Financial Gain Terrorizing certain target groups
The tables presented in this document should not be considered a complete list of all possible threats. Business unit must consider if they need to define additional threat business units based on their specific business context.
3.2
Appendix B Risk Assessment process The risk assessment process start with the identification of all assets in the scope of your information security management system. All identified assets should have the following elements identified and documented: 1. Owner of the Asset 2. Confidentiality , integrity and availability rating of the asset in line with the data classification policy Once the assets are identified then threats and vulnerabilities relevant to each of the assets are identified and assessed. Risk is the probability of a threat exploiting a vulnerability. Once the threats and vulnerabilities relevant for an asset is identified then the likelihood of a threat exploiting a vulnerability and the impact of the threat exploiting the vulnerability should be assessed and rated. The below section explains the risk rating scale and matrix
3.2.1
Impact Assessment This section explains a qualitative assessment technique to assess the impact of a risk. All impacts need to be seen in a business context, and be informed by the business. If a risk has multiple potential consequences then the impact with the largest effect must be used to rate the risk. However, where multiple consequences for a single risk are assessed at the same level the impact may be evaluated as being higher than the individual impact statements (e.g., a risk that has two medium impacts might be judged to have a High impact when they are combined). Below is the impact scale table : Rating 1
Description Low
Meaning
2
Medium
3
High
Risks which do not impose a great threat, but yet a sizable damage can be classified as Medium. Risks with significantly large consequences which can lead to a great amount of loss are classified as High
4
Critical
If a risk will result in some damage, but the extent of damage is not too significant and is not likely to make much of a difference to the overall operation of a business unit.
These are the risks which can have catastrophic impact on the operation of the organization which could compromise the strategic objectives of the organization. For example chance of
${ORGANIZATION_LOGO}
serious breach of laws or litigation against the business unit or multiple business units. 3.2.2
Likelihood (Probability) Assessment This section presents a qualitative scale that can be used to assess the likelihood of a risk eventuating. As shown in the below table it is important to define what each rating level means. This ensures that risks can be assessed in a consistent manner by providing risk assessment workshop participants with a standardised framework for assigning a likelihood rating. Where information is available about the frequency of an incident in the past it should be used to determine the likelihood of the risk eventuating. However, where such information does not exist it does not necessarily mean that the likelihood of the risk eventuating is low. It may merely indicate that there are no controls in place to detect it or that the agency has not previously been exposed to the particular risk. Likelihood scale
Rating 1 2
3.2.3
Description Almost Never Possible but Unlikely
3
Possible
4
Highly Likely
5
Almost Certain
Meaning It is difficult for the threat to exploit the vulnerability or it is not expected to occur within 5 years.
It is feasible but would require significant skills or resources for the threat to exploit the vulnerability or it is expected to occur within 3 – 5 years. It is feasible for the threat to exploit the vulnerability with moderate skills or resources or it is expected to occur within 12–36 months. It is feasible for the threat to exploit the vulnerability with minimal skills or resources or it is expected to occur within 6 12 months. It is easy for the threat to exploit the vulnerability without any specialist skills or resources or it is expected to occur within 1 – 6 months.
Risk Matrix The below picture is a 5 X 4 matrix for assigning a risk rating to a risk. It is used by mapping the likelihood and impact ratings. The rating is the point where the likelihood and impact ratings intersect.
3.2.4
Critical
10
14
17
19
20
High
6
9
13
16
18
Medium
3
5
8
12
15
Low
${ORGANIZATION_LOGO}
0
2
4
7
11
Almost Never
Possible but Unlikely
Possible
Highly likely
Almost certain
Risk Escalation All identified risks should be reported and escalated based on the below table.
Risk Escalation and Reporting levels for each level of risk
3.3
Zone 4
Chief Executive Officer
Zone 3
Senior Leadership team
Zone 2
Business owner
Zone 1
Service manager
Appendix - B References NIST Special Publication 800-39 BS ISO/IEC 27005:2008 Risk assessment process of Department of Internal Affairs: New Zealand
Critical High Medium Low
${ORGANIZATION_LOGO}
Business Continuity Plan and Disaster Recovery Process
Version Number Date of version Author Author Job title Approved by Approver Job Title Classification Intended recipient Effective from
[Version Number] [Date of version] [Author] [Author Job title] [Approved by] [Approver Job title] [Classification] [Intended recipient] [Document is valid to the organization from?]
Comment [PS39]: Enter docume version here Comment [PS40]: Comment [PS41]: Author of this document
Comment [PS42]: Job title of the author
Comment [PS43]: Approver of th document. Usually it will be the information security officer or a member of senior management. Comment [PS44]: Title of the person approving this document
Comment [PS45]: Classification o this document. Refer to informatio security policy for guidance on how classify documents (eg: Public, internal, confidential). Comment [PS46]: People who needs to read and adhere to this document.
Comment [PS47]: The effective date of this document for the organization. Based on this date the next review cycle should be calcula for instance review document ever year.
${ORGANIZATION_LOGO}
Table of Contents 1.
Introduction ........................................................................................................................................... 25
2.
Objective ................................................................................................................................................ 25
3.
What should be measured? ........................................................................ Error! Bookmark not defined.
4.
What control need to be measured?........................................................... Error! Bookmark not defined.
5.
Managing the results of measurement .................................................................................................. 25
6.
Measurement Cycle .................................................................................... Error! Bookmark not defined.
${ORGANIZATION_LOGO}
Version control Version Number [Version number]
Author [author]
Date [Date of version]
Change description [Change description]
Comment [PS48]: Initial version number of the document. Comment [PS49]: Name of the person who wrote the initial draft.
Comment [PS50]: Date of creatio of the initial draft.
Comment [PS51]: Provide a brief description of the version. For instance â&#x20AC;&#x2DC;initial draftâ&#x20AC;&#x2122;. For next versions please provide details of th change made to the initial draft.
${ORGANIZATION_LOGO}
4. Introduction A Disaster is defined as loss or damage of part or all of the Authority’s ICT Infrastructure, which would have a high, or very high, business impact on the ${ORGANIZATION_NAME} Disaster, as outlined in the above definition, includes :
Total loss of one site, (eg: due to fire damage) Loss or technical failure of one or more network servers Loss or technical failure of network infrastructure i.e. hub/switch/router/communication link Loss or technical failure or Voice Infrastructure, (telephone system) Extended loss of electrical power Failure of a key software system
5. Objective This plan document the roles, responsibilities, procedures, and checklists that should be used to manage and control the situation following an emergency or crisis. The plan is developed to accomplish the following objectives:
Prepare employees to respond effectively in a crisis situation; Manage the crisis in an organized and effective manner; Limit the magnitude or impact of any crisis situation to the various business units.
6. How the plan is activated In the event that a disaster is identified by the <Name of the department> , the Head of IT will be responsible for activating the plan and monitoring the progress of disaster recovery procedures, reporting to <Name of the department> and undertaking any further action as necessary.
7. Overview of IT infrastructure The <name of the organization> currently has <# of sites> sites that are connected to its corporate computer and voice network. These sites are: Name of the site
Address of the site
|# of servers
# of network components
Other equipment’s
Overview of security measures on the site.
Comment [PS52]: Name of the department or role who is responsi to activate this disaster recovery pl
Comment [PS53]: Name of the department or role who is responsi to activate this disaster recovery pl
Comment [PS54]: Number of site where the organization conduct its operations and support activities Comment [PS55]: Desktops, laptops, telephones, etc.
Comment [PS56]: Eg: Server rooms at Site-1 is located on the first floor, away from entrances to the buildings from outside to minimise the risk of th and flood. Site has permanent installations which provide air conditioning to maintain air temperatures suitab for the equipment located in them Redundant portable air conditioning units are kept available in the event of failure o one of the permanent installation
${ORGANIZATION_LOGO}
8. Business Impact Assessment
Critical
10
High
6
Medium
Risk Assessment and Business Impact Review
3
5
8
12
15
Low
8.1
0
2
4
7
11
Almost Never
Possible but Unlikely
Possible
Highly likely
Almost certain
14
17
19
20
9
13
16
18
Critical High Medium Low
For further guidance on risk assessment matrix please refer to â&#x20AC;&#x2DC;Risk management methodologyâ&#x20AC;&#x2122;.
${ORGANIZATION_LOGO} Comment [PS57]: Location name of the site.
5.2
Risk assessment of Assets in each site. Location
Asset
Type of Loss/Damage
Risk Rating
Business Impact
Precautions in place
9. Disaster Recovery Plan The disaster recovery plan address two elements of a disaster. Disaster could consist of failure of a particular element of the IT infrastructure, for example, a server or voice switch. Additionally a major disaster such as Fire or Flood could knock out an entire site, large part of a site which contains key systems. The first table below details steps to be taken in the event of loss of any individual key system. The second table then outlines procedures to be followed in the event of loss of an entire site or a large part of a site which contains key systems.
9.1
Table showing procedures for recovery of individual network elements Location
Asset
Type of Loss/Damage
Recovery Procedures
Recovery Time Objective( RTO)
Comment [PS58]: Name of the asset in the site eg: Email- Backup server Comment [PS59]: Eg; Fire Theft Water Damage Vandalism Wind Accidental Hardware failure Power failure Other failure Comment [PS60]: Risk rating calculated based on the risk matrix mentioned in section 5.1 Possible values are : Critical, high, Medium or Low. Itâ&#x20AC;&#x2122;s a good practice to color the column according to the color code of the risk rating. Comment [PS61]: Description of business impact if the threat get materialized. Eg: Loss of a single ESX server, would result in only a few minutes downtime to the virtual servers hosted on that ESX Server. ... Comment [PS62]: Controls in place to prevent and / or detect threat : Eg: VMware High Availability (HA) configured on all ESX hosts. This ... Comment [PS63]: Eg: Purchase replacement server from the supplier.... Comment [PS64]: Define the maximum time within which a system must be recovered.
${ORGANIZATION_LOGO}
9.2
Table showing procedures for recovery in case of loss of entire site or large part of a site which contains key systems. Location
9.3
Asset
Type and extent of a loss/damage
Recovery Procedures
Comment [PS65]: Eg: Flood/Fire (Entire site)
Roles responsibility of resource Location
Assset
Name of the person/Department
Role
Contact Details Email: Ph: Address:
9.4
Person Responsible
Authorization responsibilities Role <Job title/Department name>
Activity Authorized to declare a disaster and invocation of this plan Authorized for urgent purchases of services or systems to recover from a disaster Authorized to communicate with clients and public Authorized to communicate with government and regulatory bodies
Activities
Comment [PS67]: Role of the person or department in the BCP/DR plan Comment [PS68]: Cotact details of the person or department who is part of the plan Comment [PS69]: Activities to be performed by the person for this specific asset in the location. Comment [PS66]: Name of a person or department who should be part of the BCP/DR plan and conduct an activity Comment [PS70]: Provide the job title or department name who is responsible to authorize the activity on the right column Comment [PS71]: If you would like to restrict the purchase cost to a specific amount then add that into the activity list. Comment [PS72]: Add more authorization activities and allocate to a role
${ORGANIZATION_LOGO}
10.
Testing the Plan
It is essential that each of the various elements of this plan are tested to ensure that in the event of an actual disaster, systems can be recovered in line with this plan with a minimal interruption to users and business operations. From a testing perspective, it’s not necessary to repeat the test for all the systems which are similar in nature. A sample testing will be sufficient in those cases. For instance It will not be necessary to fully test the plan for all of the virtual servers which make-up a network , because the recovery procedure is the same for each. However, it is considered important that each system which has a different procedure for recovery is tested. Each tests will have to be planned in advance in order of priority (consider the risk rating to set the priority). Some of these tests will require significant amounts of staff time, and in some cases expenditure with external contractors which will need to be scheduled in work programs and budget requested through the usual budget bid process. Wherever possible these tests should be carried out during normal office hours, and not involve any downtime of live servers during core working hours. In addition to these tests, the following should be carried out regularly : Test restores from disk and tape to ensure that backups are reliable Tests of UPS systems to ensure they are functioning correctly It is imperative that backups are checked daily to ensure they are operating correctly. Automated emails will be generated daily detailing success or failure of individual backup jobs.
11.
Review – Maintenance of the plan
This plan is to be reviewed annually or shortly after the installation of any new key IT infrastructure by the <name of the person responsible for the review>. When installing any new infrastructure sufficient attention must be given beforehand to any impact that the installation will have on this plan. Copies of this plan are to be stored in fire-proof safes at multiple site locations along with the backup tapes.
Comment [PS73]: Eg: Head of IT Operations
${ORGANIZATION_NAME}
12.
Appendix
12.1
Site location maps <Include a map (eg: google map) which helps a user to reach an alternative site>
Comment [PS74]: Remove this guidance after including the map an necessary description
${ORGANIZATION_NAME}
12.2
Site floor plan including cable layouts. <Include a floor plan of each alternate site with cable layout â&#x20AC;&#x2DC;s >
Comment [PS75]: Remove this guidance after including the map an necessary description
${ORGANIZATION_NAME}
12.3
Result of last test carried out
<Embed here the last test result as an object>
Comment [PS76]: Remove this u guidance after embedding the resu
${ORGANIZATION_NAME}