4. Risk Management Framework

4.1 Risk Approach

PDF The Organisation’s approach to risk, which has been specifically approved and authorised by management, is contained in the risk management framework, which it applies to its overall strategic planning process. The risk management framework is designed to identify and assess risks (including information security risk) in the business plan, to identify and evaluate options for the treatment of those risks, and to select control objectives and controls that will reduce those risks to acceptable levels within the context of the business plan, operational requirements, constraints and objectives and national and international legislation and regulation. [ISO17799 4.1 and 4.2]

4.2 Risk Framework

    4.2.1 Choice of risk assessment tool/methodology

    CIO has decided not to use an automated tool to perform risk assessments. Instead it has sought advice from external security consultants VigiTrust to set out the initial to procedures and documentation and in conjunction and co-operation with the Digi-CAST3™ Team, has been trained on the use of this manual and the implementation of the procedures necessary to produce a number of methodologies to perform risk assessment on a regular basis

    4.2.2 Requirements

    Risk assessments projects need to be carried out regularly and need to help CIO identify the threat landscape, vulnerabilities and threat levels associated to each vulnerability against each of its tangible and intangible assets.

    4.2.3 Selection Criteria

    CIO opted to work with Digi-Sign because of its knowledge of Certificate Authority [CA] and Public Key Infrastructures [PKI] and with VigiTrust because of their in the filed of risk assessment for particularly sensitive information and projects related to the security of sensitive assets.

    4.2.4 Tools/Methodologies Considered

    CIO considered tools such as RA2 or equivalent on the market. However these tools require a deep understanding of the current security threat landscape and are only extremely effective for security professionals.

    It was therefore decided to work with security consultants who had their own methodologies backed by a proven track record of helping blue chip organizations to meet security best practice guidelines.

    4.2.5 How the Tool/ Methodology was Selected
    Some initial research was conducted by CIO as to whether an automated tool would be appropriate to perform the risk assessment tasks related to this project. It was very quickly identified that consultants would be required in order to engage with CIO and conduct risks assessments. After a full tendering process in accordance with the laws of the Kingdom of Bahrain and a lengthy and careful consideration process, Batelco and Digi-Sign were selected to provide this service to the CIO in co-operation with Digi-Sign’s ISO consultancy partner VigiTrust.

    4.2.6 How the Methodology Works

    The chosen methodology is based on benchmarking vulnerabilities and threats to each assets against a risk matrix. The matrix consists in evaluation of the asset in terms of importance to CIO, assigning a probability of likelihood for each threat and determining an absolute impact for the threat. The risk is calculated as follows:

    Risk (aka “Absolute risk”) = Probability of Threat * Absolute Impact of Threat

    The information below details all of the elements of this risk calculation model:

    Evaluation of Assets

    The operation owner defines the value of each asset detected depending on his perception of impact on operations) or on users in general in case of loss, theft, inaccessibility, deterioration / corruption or any other security violations. Perceived value is ranked as follows:

    Unimportant (0) Damage on the asset never affects the data system

    Not very important (1) Damage on the asset has very little impact on the data system. The data system keeps operating. Damage on it does not tarnish the company name.

    Medium (2) Damage on the asset affects the data system. The data system keeps operating but the asset in question must be replaced. Damage thereon can affect the company name negatively to a somewhat noticeable extent.

    Important (3) Damage on the asset has major impact on the data system. The data system is only half operational in that it may not be fully accessible or its integrity might have been somewhat compromised. The asset in question must be replaced. Damage thereon affects the company name adversely.

    Very important (4) The asset plays a major part for the operation of the data system. Damage on the asset has a huge impact on the operability of the data system. Only parts of the data system remain useable. Damage thereon has substantial adverse impact on the company name.

    Extremely important (5) The asset is essential for the operation of the data system. Damage on the asset directly influences the data system. The data system is out of operation. Damage thereof has very adverse impact on the company name.

    At this stage Potential vulnerabilities are listed for each asset. Vulnerabilities are the weaknesses identified for assets. Potential threats are listed for each asset. Threats are potential tools by which vulnerabilities can be misused or exploited.

    Important Note: The value as determined by the above procedure is entered in the “Critical” column Risk Treatment Plan file that accompanies this document and is referenced “Digi-CAST Asset List & Risk Treatment Issue 001-071107.xls”.
    Threat Probability Values

    Negligible (0) Not likely to happen.

    Very low (1) Twice or three times in a period of 5 years.

    Low (2) May happen once a year or a shorter period of time.

    Medium (3) May happen every six months or within a period of time between one to 6 months.

    High (4) May happen once a month or within a period of time between 2 days to one month.

    Very high (5) May happen once a day.

    Extremely High (6) May happen multiple times a day.

    Threat Impact Values

    Unimportant (0) The threat has no impact on the asset.

    Small (1) The threat has little impact on the asset. There is no need to repair or re-configure the asset.

    Important (2) Although the impact by the threat is minor and is only reported by a few persons or organizations, the threat can still have concrete damage. Corrective action involving time, effort and financial input may have to be implemented to make up for the damage and eradicate the issues.

    Detrimental (3) The Threat can damage the reputation of asset and system operators. Significant spending may be necessary to repair the damage and eradicate the issues.

    Serious (4) The Threat inflicts substantial damage on the asset and/or many staff members and the organization itself may be significantly impacted by the damage. Large scale restructuring may be necessary in the damaged system. Corrective action needs to be taken to eradicate the issues.

    Very serious (5) Threats causes the asset to be out of operation indefinitely. It requires the system to be re-designed and re-structured totally. Corrective action needs to be taken to eradicate the issues.
    The information pertaining to absolute risks requires the use of the values detailed above according to the formula, Absolute Risk = Threat Probability Value * Threat Impact Value.

    So by determining the “Threat Probability Value” (i.e. 1 – 6) using the horizontal part of the following Risk Calculation Table and then searching down the vertical column for the “Threat Impact Value”, the “Absolute Risk Value” can be calculated.

    Important Note: All three values are entered in the Risk Treatment Plan file that accompanies this document and is referenced “Digi-CAST Asset List & Risk Treatment Issue 001-071107.xls”.

    Every time an asset is added or removed from the Trust Centre, this Digi-CAST™ Manual and the “Digi-CAST Asset List & Risk Treatment” must be updated and must be signed by the Information Security Manual.

    In addition, the new Issue must be circulated to all members of the Trust Centre Team and Trust Centre Management. And this is the responsibility of the Information Security Manager.

    Risk Calculation Table

    Probability of the Threat to
    Minor (1) Important (2) Detrimental (3) Serious (4) Very serious
    Negligible (0) None (0) None (0) None (0) None (0) None (0) None (0)
    Very low (1) None (0) Low (1) Low (2) Low (3) Medium (4) Medium (5)
    Low (2) None (0) Low (2) Medium (4) Medium (6) High (8) High (10)
    Medium (3) None (0) Low (3) Medium (6) High (9) High (9) Critical (15)
    High (4) None (0) Medium (4) High (8) High (12) Critical (16) Very High (20)
    Very High (5) None (0) Medium (5) High (10) Critical (15) Very High (20) Very High (25)
    Extremely High (6) None (0) Medium (6) High (12) Critical (18) Very High (24) Very High (30)

    Absolute Risk Table


    Absolute Risk



    Corresponding to
    the Risk Score

    None 0 0
    Low 1 1,2,3
    Medium 2 4,5,6
    High 3 8,9,10,12
    Critical 4 15,16,18
    Very high 5 20,24,25,30

    Actual Risk Value is calculated by using the following final formula:

    1. Absolute Risk = Probability of the Threat * Absolute Impact of the Threat

    2. Absolute Risk Score  Simplified Absolute Risk Score (Table 4)

    3. Actual Risk Value = New Absolute Risk Score * Asset Value Identification of Targets, Controls and Counter Measures and Management of Risks
    3–Step Absolute Risk Calculation

    Step 1

    Take into consideration the impact an event using the “Threat Impact Values” scale above (0 - 5).

    Step 2

    Then consider the likelihood it could happen using the “Threat Possibility Values” scale above (0 - 6).

    Step 3

    Then use the table, which gives you the risk for the RTP (it is a basic multiplier). The value you get will appear on the “Absolute Risk Table” and this enables you to label the Risk appropriately.


    Rack server:

    The Rack could be physically damaged or it could collapse resulting in machines having to be powered off before being moved - results in disruption to services.

    Probability of that happening is low (2) however impact of the issue, if it did happen, is high (4) as it would seriously disrupt services. Therefore the Absolute Risk Value is 4 x 2 = 8. The Absolute Risk (8) is then entered in the Absolute Risk column of the Digi-CAST Asset List & Risk Treatment.

    In Summary

    Low Absolute Risk Value is typically low to high impact with little probability of occurrence (or vice versa).

    High Absolute Risk Value is typically high impact and high probability (unusual and rare, but may occur).

    Medium Absolute Risk Value is more complicated and requires careful attention as it suggests that the impact would be medium to high and so is the probability. This is where indicating actual controls in place will ensure that a proper risk assessment has been conducted.

    Consider the asset and carefully consider the likelihood of the potential threat happening. Should it happen, what impact would have it have on the CIO Trust Centre if it did happen and then using the above system assign figures and calculate the Absolute Risk Value.

    4.2.7 Training requirements
    The CIO Trust Centre staff must understand the scoring mechanism and regular training should be provided by the Information Security Manager to all the members of the Trust Centre Team. In addition ongoing security awareness through training, reference manual, demonstration and incident reporting, resolution and documentation is provided in order for Trust Centre Team to keep abreast of the latest threats in order to be able to continually assess risks and take pre-emptive action.

4.3 Information Security Risk Management

    4.3.1 The Organisation has established and maintains its ISMS, and identifies and assesses information related risks, and evaluates options for their treatment, within the context of the risk management framework described in DOC 4.3 and performs risk assessments in line with DOC 4.4, using the tool selected following the procedure documented in DOC 4.2.

    4.3.2 Control objectives and controls are selected from Annex A of [ISO27001/ISO17799:2005] on the basis of the conclusions to step 4.3.1. Additional control objectives and controls are, not required from other sources other than ISO27001. All control objectives and controls are documented in the Statement of Applicability, which is set out in Sections 5 to 15 of this manual.

    4.3.3 A consolidated; corporate level risk treatment plan (DOC 4.1) is formulated in order to implement the selected controls.

    4.3.4 The implementation is reviewed for effectiveness and, where possible, improvements are identified and these, within the context of the overall ISMS, are implemented, using a PDCA process.

    4.3.5 This process is followed irrespective of whether a single risk is being considered, or multiple risks.

4.4 Risk Assessment Tool & Methodology
The Organisation’s method for risk assessment is to use risk assessment tool in this Digi-CAST™ Manual and uses the procedure as set out below. This tool and methodology is suitable for the scope of the Organisation’s ISMS (Section 1), the business objectives (3.1b1 above), the security, contractual, legal and regulatory requirements (3.1b2) above and risk management framework that were identified earlier. The selection criteria are set out in DOC 4.2. [ISO27001 4.2.1c] and the risk assessment procedure itself is carried out as described in DOC 4.4.

    4.4.1 Scope

    This method of risk assessment is applied throughout the Organization in respect of information risks.

    4.4.2 Responsibilities

    The Information Security Manager is responsible for carrying out risk assessments wherever they are required by the ISMS.


    4.4.3 Identity of Risks The assets that are within the scope of the ISMS are identified and listed in line with the requirements of DOC 7.1 (asset inventory), The business, legal and contractual requirements and asset values are established at the same time and in line with DOC 7.1. When new information assets (in the broad sense of DOC 7.1) are acquired, or existing assets in any way changed, those assets are added to the inventory and are treated in line with the requirements below. The threats to each of those assets are identified in process 4.1. For each asset within the ISMS, all applicable threats are selected from the list of example threats. The Information Security Manager is responsible for ensuring that the list of threats is adequate for the ISMS. The vulnerabilities that might be exploited by each of these threats are identified once each threat has been identified and listed. Where new vulnerabilities or weaknesses are identified (for e.g., through the information security event reporting procedure in DOC 13.1), the risk database is updated and, if appropriate, the risk assessment procedure set out here is repeated and any changed controls implemented. Risk of exposure is assessed using process 4.2. For each threat/vulnerability combination, the threat likelihood and vulnerability level are calculated and a brief explanation may added for further clarity. Finally, at this stage, the security properties that are affected by this exposure risk are identified.

    4.4.4 Assess the Risks Information Security Manager will carry out the ISMS risk assessment on an ongoing basis. Once all the preceding steps have been completed and approved, the risks for each of the assets will be calculated within the ISMS. this process, a risk name is allocated to each threat/vulnerability combination and is placed within the appropriate risk category available.

    4.4.5 Identify & Evaluate Options for the Treatment of Risks appropriate risk treatment decision is made for each identified risk for each asset within the ISMS. The risk treatment decision is made in line with the requirements of DOC 4.3. each of the risk treatment decisions, document the reasons for the decision in the appropriate tab, together with specific actions to be taken (usually, apply appropriate controls from Annex A of ISO 27001)

    4.4.6 Select Control Objectives & Controls for Treatment of Risks control objectives and controls are selected from Annex A of BS7799-2:2005/ISO17799. These control objectives and controls are then manually summarized into the Statement of Applicability. Provide justifications for all selected controls and for non-selected controls. Once this is complete for all controls. complete Statement of Applicability is printed out, a signed copy retained by the Information Security Manager and decision for each control objective and control is manually transferred to the ISMS Manual, which describes how each control is actually implemented.

    4.4.7 Implementation

    Controls are implemented according to relevant associated processes and OWIs pertaining to each threat.

    The Information Security Manager is the owner of this document and is responsible for ensuring that this procedure is reviewed in line with the review requirements of the ISMS.

    A current version of this document is available to the Trust Centre team members on request.

    This procedure was approved by the Director General of IT and the President of the CIO on 08 November 2007 and is issued on a version-controlled basis under their signatures.

4.5 Systematic approach to risk assessment
The Organisation has a documented approach (framework in DOC 4.3, tool in DOC 4.2 and procedure/methodology in DOC 4.4) to risk assessment.

4.6 Prepare a Statement of Applicability

    4.6.1 The control objectives and controls selected in line with clause 4.5, and as a result of carrying out the procedure identified in DOC 4.4, are documented in a Statement of Applicability, which forms Sections 5 to 15 of this Manual.

    4.6.2 Any controls or control objectives in Annex A of [ISO27001/ISO17799:2005] that are excluded are documented, together with the justification for their exclusion; any additional controls or control objectives that may be required are also documented in the Statement of Applicability.

    4.6.3 The remaining residual risks are highlighted in the risk treatment plan (DOC 4.1) as required by DOC 4.3, and board authorisation is obtained for implementation of the ISMS.

    4.6.4 Any changes to the risk treatment plan (DOC 4.1), which lead to a change in the ISMS, are subject to authorisation by the board.

    Shaikh Salman Mohammed Al-Khalifa Mohammed Al-Amer
    Director General of IT President of CIO

    ____________________________ _______________________________


    08 November, 2007 08 November, 2007
    ____________________________ _______________________________
    Adlin Hisyamuddin
    Information Security Manager



    08 November, 2007

    Change history

    Issue 1 08 November, 2007 Initial issue